The report ran once. The event was sent twice.

A customer completes one AI report. Your product sends the usage event to billing, but the network drops before the response comes back.

The product cannot tell whether the event arrived, so it sends it again.

Two requests reached billing. The customer completed one report and should pay for one.

The event is the receipt for the action

A usage event is a small record of something billable that actually happened: a report completed, a message sent, a document processed, or a delivery finished.

It connects the customer’s action to every decision that follows:

• add one to the meter;
• subtract units from prepaid usage;
• compare usage with the plan allowance;
• and create the invoice line.

If the event is wrong, every downstream number can agree and still produce the wrong bill.

Create it when the value is delivered

The customer clicks Generate report, but the AI job may fail halfway through. Counting the click would charge for work the customer never received.

For this product, the commercial rule is simple:

Record one usage event after the report completes successfully.

Other products may choose a different moment. A delivery platform may count a dispatched order or a completed delivery. A document product may count pages accepted for processing or files successfully returned. Pick the moment that matches what the customer believes they bought.

One event needs five useful facts

The event for this report carries:

Field	Value	Why it matters
Customer	Acme workspace	Puts usage on the right account
Event	report.completed	Says what happened
Quantity	1	Says how much to count
Occurred at	18 July, 10:42	Puts it in the right billing period
Event ID	report_87	Prevents the retry from counting twice

These fields are not engineering decoration. Each one answers a question the customer or finance team may ask about the invoice.

Send the same ID when you retry

The first request reaches Tirdad, but the response is lost. Your product retries with the same event ID: report_87.

One action, two sends

The same event ID prevents a double charge

Report completedProduct creates the eventreport.completed · report_87 · quantity 1

→

First sendFirst sendTirdad receives it, but the response is lost

→

RetryRetrySame event · same ID report_87

→

OutcomeOutcomeAccepted once · meter +1 · invoice +1

Tirdad recognizes that report_87 already exists and returns the original result. The meter increases by one, prepaid units are deducted once, and the invoice includes one report.

A new ID on every retry would make the two requests look like two different reports. Reliable networks do not remove this risk; timeouts and retries are normal in every production system.

Use the time of the action

Suppose the report completes at 11:58 PM on 31 July, but a delayed batch sends the event at 12:03 AM on 1 August.

The event belongs to July because that is when the customer completed the report. Store both facts if needed—the time it happened and the time it arrived—but use the occurrence time for the billing period.

Without that distinction, late events move between invoices based on network timing instead of customer usage.

Keep the event names stable

Event names become part of pricing, analytics, and customer history. Avoid creating a new name every time the interface changes.

report.completed can remain stable while the product changes the button label, report design, or internal AI model. Pricing should follow the customer action, not the current screen layout.

Write the event definition in one sentence:

report.completed is recorded once when a report is ready for the customer to open.

That sentence gives product, engineering, finance, and support the same counting rule.

One record should explain every total

In Tirdad, the same accepted event feeds the meter, plan allowance, prepaid-unit ledger, and invoice. The event ID protects retries, the occurrence time assigns the correct period, and the customer can be traced from the invoice total back to the operation that created it.

A usage event is trustworthy when it records one delivered action, once, for the right customer and period.

Continue with the practical implementation: How to build a subscription that survives the first change