The customer generated 1,842 reports. What should the invoice say?
July 9, 2026
A customer pays SAR 499 a month. Their plan includes 1,000 AI reports, then charges SAR 0.35 for every additional report.
At month-end, they have generated 1,842. What belongs on the invoice—and what must your product record for that number to be defensible?
First, price something the customer recognizes
“AI usage” is not a billable unit. Neither is “compute.” The customer cannot predict either one or connect it to the value they received.
Here, the useful unit is a completed report. The customer knows when one was created, can see it in the product, and understands why creating more costs more.
| Test | Question | Reports example |
|---|---|---|
| Understandable | Can the customer explain what they bought? | One completed report |
| Measurable | Can your system count it consistently? | Count only successful reports |
| Connected to value | Does more mean more customer value? | More reports, more work completed |
If the only unit you can measure is a technical cost the customer never sees, you may have found an internal cost metric—not a pricing metric.
Follow one report through the system
When a report finishes successfully, your product sends one usage event. It identifies the customer, operation, quantity, time, and a unique ID.
The billing system adds it to the customer’s meter. At month-end, the pricing rule separates the 1,000 included reports from the 842 above the allowance.
1,842 reports become an explainable charge
The calculation is easy to explain:
- base plan: SAR 499.00;
- included reports: 1,000;
- billable reports: 842;
- usage charge: 842 × SAR 0.35 = SAR 294.70;
- total before tax: SAR 793.70.
The customer is not paying for an invisible counter. They are paying for 842 completed reports beyond their plan allowance.
Decide what counts before the first event
The dangerous question is not “how do we count reports?” It is what counts as a report?
Does a failed report count? What about a retry after your service timed out? What if the customer deletes it ten seconds later? Product, engineering, finance, and support need one answer before launch.
For this example, the rule is:
Count a report only after generation succeeds. A retry with the same event ID does not count twice.
That sentence is the commercial contract behind the meter. Without it, two engineers can build two reasonable counters and produce two different invoices.
The allowance makes the bill predictable
Pure pay-as-you-go makes monthly spend harder to forecast. A flat subscription hides usage and can make your heaviest customers unprofitable.
The hybrid model combines both:
- SAR 499 creates predictable recurring revenue;
- 1,000 included reports give the customer room to use the product;
- SAR 0.35 overage keeps revenue aligned when usage grows.
You still need a limit policy: warn the customer, block more reports, or continue and bill the excess. Make that decision visible before they cross the line—not after the invoice arrives.
The invoice should preserve the story
Do not collapse the charge into “usage: SAR 294.70.” Show the unit, included amount, billable quantity, and rate. The customer should be able to reproduce the line without opening a support ticket.
In Tirdad, your product sends the successful report event once. Tirdad keeps the meter, applies the plan allowance and overage price, and creates the invoice line from the same record. If you change the price later, earlier usage remains tied to the price that applied at the time.
Metered billing works when the customer understands the unit, your product records it consistently, and the invoice shows the calculation.
Next, define who receives the feature and how much each plan includes: The feature exists. Who gets to use it?
Eight connected decisions—from the first usage event to recurring revenue.
Set the rule once. Tirdad applies it every time.
Keep the policy, effective date, customer agreement, and invoice calculation in one billing system instead of rebuilding the decision in every product surface.