Usage metering

Metering is the data layer beneath usage-based billing. Before you can rate consumption, you have to count it — reliably, at volume, and in a way that survives being audited by a customer who disputes their invoice.

The requirements are stricter than they look

• Idempotency. Retried event submissions must not double-count. Every event needs a stable identifier that the meter deduplicates on.
• Late arrival handling. Events generated on the last day of a period may arrive after the invoice run. You need either a defined cut-off with a grace window, or a mechanism to true up in the following period.
• Aggregation semantics. “Usage” can mean a sum of units, a peak concurrent value, a count of unique actives, or a final balance. Each aggregates differently and none can be derived from the others after the fact.
• Auditability. When a customer questions a $40,000 usage invoice, you need the underlying events, not a total.

Choose the metric before the price

The most consequential decision in usage pricing is which unit is metered, and it is a product decision rather than a billing one. The unit should track the value the customer receives, be something they can predict and control, and be countable without ambiguity.

Units that fail that test — vaguely defined “credits”, metrics the customer cannot influence, or anything requiring a footnote to explain — generate billing disputes for as long as the pricing model survives. Changing the metered unit later means repricing every existing contract, so it is worth getting right the first time.