Designing a usage pricing model your finance team can close on
Most usage pricing fails in the close, not in the market. Four decisions to make before you launch a metered plan.
Usage pricing is usually designed by product and priced by sales. Finance meets it for the first time at the end of the first cycle, which is the worst possible moment to discover that “tokens processed” has three definitions.
The commercial design is rarely the problem. The operational design is.
Decide what the unit is, and write it down
A meter needs one definition, and the definition has to survive a support ticket. “API calls” sounds unambiguous until you ask whether a call that returns a 429 is billable, whether a retried call is one or two, and whether a batch endpoint is one call or the number of records in the batch.
Pick the answer, write it into the contract, and implement that exact rule. A meter whose definition lives only in code will be redefined by whoever next touches the code.
Decide when an event belongs to a period
Metered events have two timestamps that matter: when the thing happened, and when you found out. They are not the same, and under load they can be hours apart.
Billing on event time is almost always correct, and it means the cycle cannot be finalised the instant it ends. Billing on ingest time lets you close immediately and quietly moves revenue between periods.
Choose event time, then decide explicitly how long you will wait for stragglers before the period is sealed. A stated cutoff is defensible in an audit. An implied one is not.
Decide how credits draw down
Prepaid credits, commitments and overage are where usage pricing gets genuinely hard, because they turn a simple multiplication into a stateful calculation with an order of operations.
If a customer has a commitment, prepaid credits, and a discount, the sequence in which those apply changes the invoice. There is no universally correct order. There is only the order you chose, applied consistently, and disclosed.
Decide what the customer sees before you send the invoice
The single largest driver of usage billing disputes is that the first time a customer sees their consumption is on an invoice. By then the period is over and nothing can be done about it.
Exposing running usage during the cycle converts a dispute into a conversation. It is also the cheapest thing on this list to build.
The test
Before launching a metered plan, run one cycle end to end on real traffic without charging anyone. Then ask finance to close it.
If they can produce the revenue figure without opening a spreadsheet, the model is ready. If they cannot, the pricing is fine and the plumbing is not, and shipping it will simply move the work to the last three days of every month, forever.
Read next
The month-end close for recurring revenue, step by step
A practical sequence for closing a subscription and usage book, and the three places it usually stalls.
Multi-entity revenue: what changes when you add the second entity
The second legal entity is the point at which revenue operations stops being a reporting problem and becomes a structural one.