What is usage-based billing?

Usage-based billing means charging a customer for what they actually used, rather than for access to the thing they used it with. A phone bill is usage-based. A gym membership is not. Most software has spent twenty years in the second category and is now, quite quickly, moving to the first.

The idea is simple enough that it hides how much machinery sits underneath it. This is a guide to that machinery: what the pieces are called, what each one has to get right, and where the money goes missing when one of them does not.

The four stages

Every usage-based billing system, however it is built, does four things in order. Metering, rating, invoicing, and reconciliation. They are separable, and most of the pain in the field comes from treating them as one.

1. Metering

Metering is recording that something happened: a call of 372 seconds to 447700900123 at 14:02, an API request against an endpoint, 18,402 tokens sent to a model. Each of these is an event, and an event has a handful of properties — when, who, what, how much, and whatever else is relevant to how you price it.

Metering sounds like the easy part and is where most systems first go wrong. Events arrive twice because a client retried. They arrive late because a switch was offline. They arrive with a timestamp in the future because a clock is wrong. If your meter counts a duplicate, you have overcharged someone; if it drops a late event, you have undercharged yourself.

2. Rating

Rating turns a quantity into an amount. It is the part people underestimate most, because the rules are rarely as simple as multiplying by a rate.

• Increments: a 61-second call on 60-second billing charges for 120 seconds.
• Minimums: a five-second call with a 30-second minimum charges for 30 seconds.
• Matching: which rate applies at all — usually by prefix, longest match first.
• Versioning: which price list was in effect at the moment the event happened, not the moment you are looking at it.
• Rounding: where, and how, fractions of a penny resolve.

Each of those is a place where two reasonable implementations produce different numbers. That is why the same traffic run through two systems rarely agrees to the penny, and why 'rounding difference' is the most expensive phrase in billing.

3. Invoicing

Invoicing groups rated events into a statement for a period. The period is where timezones bite: 'March' means something different in Europe/London than in UTC, and the difference is two hours of traffic at each end plus whatever the clocks did in between.

4. Reconciliation

If you resell anything — carrier minutes, transit, model tokens, warehouse space — you receive invoices as well as sending them. Reconciliation is checking that what you were charged matches what you actually consumed. It is the stage most businesses skip, because doing it by hand across tens of thousands of lines is not realistic.

The six things that have to be right

If you are evaluating a system, or building one, these are the questions worth asking early. Each of them is cheap to get right at the start and expensive to retrofit.

• Idempotency. If the same event is sent twice, is it billed once? The usual answer is a client-supplied event identifier and a deduplication window.
• Late arrival. If an event turns up three days after it happened, is it rated into the period it belongs to, or the period it arrived in?
• Plan versioning. When you correct a price, does last month's invoice change? It should not.
• Precision. Is the money maths fixed-point, and is rounding applied once at the end rather than at every step?
• Traceability. Can you click an amount and reach the events behind it, and click an event and see the arithmetic?
• Exit. Can you get every raw event back out, in an open format, without asking permission?

Why it is worth the trouble

Usage-based pricing aligns what a customer pays with what they get, which makes it easier to sell and harder to churn out of. It also means your revenue moves with your customers' success rather than with your renewal calendar.

The catch is that it moves billing from a quarterly administrative task to a continuous engineering concern. Every event is now a financial record. That is a real change in posture, and it is why the six questions above matter more than the pricing model you eventually choose.

Where to start

Start by metering, before you price anything. Get events flowing and stored, look at a week of them, and find out what your usage actually looks like — the distribution is almost always different from what people assume. Pricing decisions made against real data are better decisions, and you can change a price plan far more easily than you can recover usage you never recorded.