Consumption pricing has become the default for infrastructure, API and AI companies, and it is spreading into conventional SaaS as hybrid models. Commercially it is attractive: revenue grows with customer success, and the entry price is low.
Accounting-wise, it introduces a category of problem that seat-based subscriptions do not have.
Under AASB 15, the transaction price includes variable consideration — amounts that depend on future events. Usage-based fees are the textbook example.
You are required to estimate that variable amount, using either the expected value or the most likely amount, and then apply the constraint: you only include it to the extent that a significant revenue reversal is not probable when the uncertainty resolves.
In plain terms: you cannot recognise optimistic usage estimates and correct them later. You have to be conservative in a way you can defend.
Estimation on immature accounts. A customer three months into a contract has almost no usage history. Your estimate is genuinely uncertain, which is exactly when the constraint bites hardest.
The lag between usage and billing. Usage happens continuously; invoicing happens monthly in arrears. At period end you have delivered service you have not invoiced, which is unbilled receivable or contract asset — not deferred revenue, and it behaves differently on the balance sheet.
Commitments with drawdown. A customer prepays for a pool of credits and consumes them unevenly, sometimes with expiry. Now you have a contract liability that releases on consumption rather than on time, plus a breakage question for unused credits.
Tiered and blended rates. If the unit rate falls as volume rises, the effective rate for the period cannot be known until the period ends — which affects both the estimate and any interim reporting.
With seat-based subscriptions, the revenue schedule is a function of the contract. With usage-based pricing, it is a function of the contract and a continuous stream of metered events.
That means the accounting system has to reconcile against a usage source — your product telemetry, a metering service, or a billing platform. Three things have to agree every period: what the product recorded, what the billing system invoiced, and what the ledger recognised.
When those three drift, it is rarely caught quickly, because each system looks internally consistent. The usual discovery point is a customer disputing an invoice, or an auditor sampling usage records against revenue.
Practical requirements:
Most companies do not run pure consumption. They run a platform fee plus usage, or a committed minimum with overages, or seats plus API calls.
Hybrids require allocation. If a customer pays a bundled amount covering both a subscription and a usage entitlement, you have to allocate the transaction price across performance obligations by standalone selling price — and the usage component may need to be estimated and constrained while the subscription component is recognised rateably.
This is where generic billing engines struggle, and where contract management that feeds the revenue engine directly earns its place.
You should be able to answer, for any customer, without opening a spreadsheet: what did they consume this period, what were they billed, what did we recognise, and what is the difference made of?
If the answer takes more than a few minutes, the reconciliation is not really running — it is being reconstructed on demand.
Usage-based and hybrid models are among the more demanding configurations we do. The work is in getting the contract terms into the system as structured data, connecting the usage source, and building the reconciliation so it runs rather than being rebuilt.
If you are moving to consumption pricing or already there and the numbers are getting difficult to defend, we are happy to look at it with you.