From Product Usage to an Invoice with Tirdad
Define a billable action, configure its meter, make retries safe, apply an allowance and overage price, and trace every invoice quantity back to the product.
Updated 2026-08-14
Noura’s Growth plan includes 100 AI reports. She generates report 87 today and report 101 next week. The first is included; the second creates a SAR 2 charge.
That sounds like arithmetic. The difficult part is deciding exactly when a report counts—and making the answer survive failures, retries, plan limits, and invoice questions.
Define one unit before building the meter
Write the rule in customer language:
One unit is recorded when a financial report completes and is available to the customer. A click, failed report, or internal retry does not count.
Write the rule before you configure the meter.
When does one unit exist?
The customer clicks Generate
An internal retry starts
The report fails
This sentence is the contract between product, engineering, finance, and support. It answers the first question when a customer disputes a quantity.
Resolve the edge cases now:
| Situation | Count it? | Reason |
|---|---|---|
| Report completes | Yes | The customer received the result |
| Generation fails | No | No result was delivered |
| Internal retry succeeds | Once | It produced one result |
| Customer downloads again | No | It is the same report |
| Report is regenerated as a new result | Decide and document | Product policy must define it |
Create the meter in Tirdad
In Product Catalog, create a meter named Completed AI reports.
For this example:
- event name:
report.completed; - aggregation:
COUNT; - filter: count completed reports only;
- usage reset: billing period.
The meter turns raw events into the number billing needs.
Use another aggregation when the customer unit changes. Sum pages, count unique active users, or track the latest storage amount. Do not choose an aggregation because it is technically available; choose it because it matches the promise on the pricing page.
Send the event after the result exists
The customer’s click begins work. It does not prove that billable value exists. Send the usage event after the report reaches the completed state.
Report 87 moves from product action to billed usage.
The event needs four durable facts:
| Fact | Example | Why Tirdad needs it |
|---|---|---|
| Event name | report.completed | Finds the matching meter |
| Customer | Noura’s customer reference | Attributes usage correctly |
| Event ID | event_87 | Makes retries safe |
| Timestamp | When report 87 completed | Places usage in the correct period |
Build the event ID from the completed business action. If delivery times out, resend event_87. A retry should deliver the same fact, not invent another report.
Make delivery reliable without delaying the customer
The report and its usage event should not be able to disappear independently.
A practical pattern is:
- mark the report completed in your database;
- save a pending usage-event record in the same transaction;
- let a background worker send it to Tirdad;
- mark it delivered after Tirdad accepts it;
- retry with the same event ID when delivery fails.
The customer does not need to wait for the billing call to finish. Your system does need a durable record that the call remains due.
Attach the meter to the commercial rule
The meter only says Noura used 87 reports. The plan decides what that number means.
For Growth:
- 100 reports are included each billing period;
- reports 1–100 add no overage;
- report 101 starts SAR 2 per report;
- usage resets with the next billing period.
The meter measures. The plan decides what happens next.
Metered usage
Growth allowance
No overage yet
SAR 2 overage starts
Keep the policies separate:
- the meter calculates usage;
- the allowance says how much is included;
- the price calculates overage;
- the entitlement decides whether use may continue.
This separation lets you raise the allowance without changing how reports are counted, or change the overage price without rebuilding product events.
Use the same meter for cost and revenue
The cost-sheet guide connected supplier costs to report.completed. The plan charge now uses that same meter for revenue.
That gives Cost Analytics a comparable pair:
revenue from completed reports − cost of completed reports = margin
One meter now answers two different questions without mixing them: what the customer owes, and what serving that usage cost you.
Let the customer understand usage before the invoice
Do not make the invoice the first place Noura discovers report 101 was chargeable. The product should make these facts easy to find:
- current usage: 87 reports;
- included amount: 100;
- remaining amount: 13;
- reset date;
- what happens after 100.
This is a product principle, not a prescription to place a counter beside every button. Show the commercial context where it helps the customer decide.
Debug the full path, not only the event
When usage looks wrong, trace one report through the chain:
report record → event → matched meter → subscription line → allowance → invoice
Tirdad’s event data and meter usage help answer where attribution stopped. Check rejected events, unmatched meter names, wrong customers, late timestamps, and duplicate IDs before changing the invoice manually.
Test the cases that alter money
Before launch, verify:
- report 87 succeeds and counts once;
- the same event ID is sent twice and still counts once;
- a failed report counts zero;
- an event delayed across the billing boundary lands in the intended period;
- report 100 remains included;
- report 101 receives the overage price;
- cancellation and plan changes use the correct period;
- every invoice quantity can be traced back to completed reports.
Your product decides what happened. The meter turns those facts into usage. The plan turns usage into a customer promise and an invoice you can explain.