Every conversation about moving to usage or outcome pricing eventually hits the same wall. Someone asks what the current numbers look like, and the room goes quiet, because nobody is counting anything at the granularity the new model requires.
This is the unglamorous half of the pricing shift, and it takes longer than the commercial half.
The Four Properties Your Meter Needs
- Accurate. Obvious, and harder than it sounds when events arrive out of order, duplicated, or after a service restart.
- Auditable. When a customer disputes an invoice, you must be able to show every event that produced it, months later.
- Real time enough. Customers need to see the meter running. Monthly surprises are the single largest cause of churn under consumption pricing.
- Idempotent. Your systems will retry. If a retry double-counts a billable event, you have invented a fraud allegation.
The Architecture That Holds Up
Emit an event at the point the billable thing happens, with a unique identifier, a timestamp, the account, the quantity and a version for the pricing rules in force.
Store those raw events immutably and separately from your aggregation. Aggregate on read or into a rollup you can rebuild. The rule that saves you: never destroy the raw events, because every billing dispute is resolved by replaying them, and every pricing change requires recalculating history to see what it would have done.
The Mistakes That Cost the Most
| Mistake | What it costs you |
|---|---|
| Aggregating at write time | You cannot recalculate when rules change |
| No event identifiers | Duplicate charges you cannot prove or disprove |
| Metering inside the application | Every service change risks the invoice |
| No customer-facing meter | Disputes arrive as cancellations |
| Timezone handling by accident | Month boundaries become a support ticket |
Metering embedded in application code is the one that quietly ruins a year. A refactor nobody flagged as billing-related changes what gets counted, and you find out at month end.
Build or Buy
Buy, unless metering is genuinely your product. Billing infrastructure is a well-served category, it is boring to build, and the cost of getting it slightly wrong is measured in trust rather than engineering hours.
The part you cannot outsource is defining the billable event, because that is a product decision. Get that definition right and any competent billing system will handle the rest.
What to Do Before the Pricing Change
Run the meter in shadow mode for a full quarter before anyone is billed on it.
Count everything, invoice nobody, and compare what customers would have paid against what they actually paid. You will discover three things reliably: your assumptions about usage distribution are wrong, a handful of customers would see an alarming increase, and at least one event is being counted twice. Finding all of that before launch is worth the quarter.
Conclusion
Emit immutable events with unique identifiers at the moment the billable thing happens, keep the raw stream forever, aggregate on read, and show customers a live meter. Buy the billing infrastructure and own only the definition of the billable event. Then shadow the whole thing for a quarter before a single invoice depends on it. Pricing pages are easy to change. Trust in the meter is not.
Frequently Asked Questions
How real time does the meter need to be?
Same day is usually enough for the customer view. What matters more is that it never moves backwards, because a number that decreases destroys confidence instantly.
What about customers who exceed their budget mid-month?
Notify at thresholds, offer a cap, and never silently cut off service. Surprise overage and surprise suspension are the two fastest routes to a public complaint.
Do we need to keep events forever?
Keep them for at least as long as your contracts allow disputes, plus your audit requirement. Storage is cheap. Being unable to prove an invoice is not.