The Meter Is Accurate. The Price Can Still Be Wrong.
You counted every action correctly. The customer still disputes the bill. Learn which product events deserve a price—and which should never reach an invoice.
Updated 2026-08-15
Not everything you can count deserves a price.
Did the customer receive an outcome?
Can they predict the quantity?
Can the charge trace to one action?
Your meter counted every report correctly. The invoice is mathematically perfect. The customer still asks, “Why am I paying for this?”
That is the uncomfortable truth about usage-based pricing: accurate measurement does not guarantee a fair price. The model works only when the counted unit feels like value to the customer—not activity inside your infrastructure.
Accuracy is not the first test
Not every action you can count belongs on the invoice. The number needs to stay close to the value the customer received.
| Question | Good signal | Warning sign |
|---|---|---|
| Does more usage mean more value? | Every completed report saves time | More retries do not change the result |
| Can the customer predict it? | They know their monthly workload | The number depends on internal operations |
| Can the customer control it? | They can set a budget or cap | The system consumes it without their decision |
| Can you explain it? | Every unit maps to a clear action | The amount comes from a formula they cannot see |
If those answers are not clear, use a subscription price or hybrid model instead of billing every action.
Decide what is allowed to reach the invoice
Write the rule in customer language before naming the event:
Count 1 report when it completes and is ready for the customer. A failure, internal retry, or second download does not create another unit.
That sentence matters more than the event name. It is the contract that keeps product, engineering, finance, and support on the same number.
One event can create four different offers
- Per unit: clear, but the whole bill varies.
- Included limit with overage: gives the customer a predictable base and protects you at high usage.
- Tiers: reduce the unit price at scale but require a clearer explanation.
- Prepaid units: control spend before use and need an understandable record of additions and deductions.
For reports, the hybrid model is easy to follow: a subscription opens the product, includes 100 reports, and sets a known price for every report after that.
Give the customer a brake pedal
The invoice should not be the first place usage appears. Customers need to know:
- usage so far;
- what remains inside the plan;
- when the count resets;
- what the next unit costs;
- what happens at the cap.
You do not need a counter beside every button. Show the information when it changes the customer’s decision: near the limit, before an expensive action, and when the budget is almost spent.
The boundary is where trust breaks
The average will not expose billing defects. Test the last included unit, the first overage, a late event, a retry, and a plan change in the middle of the period.
Usage billing works when support can begin with an invoice line and return to the report that caused it. Tirdad preserves that path across the event, meter, price, and invoice.
Turn the model into a reliable runtime: read From Product Usage to an Invoice with Tirdad