The accounting standards for consumption-based revenue haven't changed. ASC 606 handles it the same way it handles every other variable consideration arrangement — estimate, constrain, re-estimate every period. What's changed is the prevalence of the model and the complexity of the pricing. Consumption-based contracts are no longer edge cases. For AI companies and usage-driven SaaS, they're the primary revenue structure.
The failures that follow are structural. They're not about misunderstanding the standard — they're about applying a close process built for fixed fees to contracts where the transaction price is uncertain until billing closes.
Running a Subscription Close on a Consumption Business
The most pervasive problem in consumption-based revenue recognition isn't an accounting error — it's a process mismatch. Companies that grew up on subscription SaaS have close processes designed for fixed, predictable revenue: set the transaction price at inception, recognize ratably, move on. When they shift to consumption pricing, they apply the same process. It doesn't work.
Consumption revenue requires re-estimation at every close — not as a special adjustment, but as the core of the recognition process. That means billing data available before close, not after. It means re-estimation built into the close calendar, not bolted on at the end. And it means the accounting team needs visibility into usage actuals in something close to real time.
The companies that handle this well redesigned their close process before the revenue problem became material — not after an audit surfaced it.
Not Knowing Which Contract Structure You Have
There's a fundamental accounting difference between a pure consumption contract and a committed-minimum-plus-overage structure — and it determines your entire recognition approach. A committed-minimum contract has two distinct pieces: a fixed floor recognized ratably or as service is provided, and a variable overage that goes through the estimation and constraint process. A pure consumption contract has no floor at all.
On the pure consumption side: if the contract involves a license of intellectual property and the fee is a usage-based royalty, the exception in ASC 606-10-55-65 may apply — recognize only as usage occurs, no upfront estimation required. If it's a services arrangement rather than an IP license, you're in variable consideration territory with a potentially very wide constraint.
The committed-minimum structure is common in AI API contracts and usage-driven platforms because it gives vendors a revenue floor while giving customers flexibility. Getting this wrong isn't subtle. A company that treats a committed-minimum contract as pure consumption and defers all recognition to usage occurrence is systematically underrecognizing revenue. A company that treats a pure consumption contract as having a committed minimum it doesn't have is overrecognizing. The contract review that resolves this takes an afternoon. The restatement that follows getting it wrong takes significantly longer.
Estimating AI Consumption With No Comparable Data
AI-priced products — charged on tokens, API calls, compute time, or inference runs — create an estimation problem that traditional usage-based pricing doesn't. The constraint analysis for variable consideration explicitly considers experience with similar contracts as a factor. For AI products in their first year of a new pricing model, that experience simply doesn't exist.
What teams frequently do: estimate variable consideration based on sales forecasts or customer-provided projections, apply a perfunctory constraint analysis ("we believe it's probable the revenue will be earned"), and include the full estimated variable amount in the transaction price. That's not supportable. The constraint test requires that it be probable there will be no significant reversal. A projection based on customer intent is not the same as experience-based data.
AI consumption can spike dramatically as customers move workloads into production, or flatline if a use case doesn't work. Both outcomes are common. Until a company has 12–18 months of comparable usage data across similar customers, the constraint position should be conservative: recognized committed minimums plus variable amounts supported by actual usage actuals. Build the data. Then expand the estimate.
Misapplying the Right-to-Invoice Expedient
The right-to-invoice practical expedient (ASC 606-10-55-18) is genuinely useful for consumption contracts: if the amount you invoice each period equals the value delivered in that period, you can recognize revenue in that amount without estimating total contract consideration. For straightforward consumption contracts — fixed per-unit price, bill on usage, usage equals value — this expedient is clean and appropriate.
The expedient runs into difficulty with tiered pricing. If per-unit rates decrease as volume increases — a common structure in AI API contracts — the amount invoiced in a given period may not reflect the blended per-unit value across the full contract term. Let's say the first 1,000 API calls are billed at $0.10 each, the next 10,000 at $0.07, the next 100,000 at $0.05. In a low-consumption month, the invoice reflects the higher early-tier rate. In a high-consumption month, it reflects mostly lower tiers. Whether those invoiced amounts correspond to value delivered in each period requires analysis — it's not automatic.
Companies applying the expedient to tiered consumption contracts should document that analysis explicitly. If the invoiced amounts don't correspond to proportionate value in each period, the expedient isn't available and the contract needs to be treated as variable consideration with an estimated transaction price. The error tends to become visible when the contract term closes and cumulative invoiced revenue doesn't reconcile to cumulative value delivered.
What to Do With This
Consumption-based revenue recognition isn't harder than subscription revenue recognition in principle. It's harder operationally, because the transaction price isn't fixed at inception. Handling it correctly requires structure in three places:
Identify the contract structure before you build the recognition policy — pure consumption versus committed-minimum-plus-overage determines which recognition approach applies.
Apply the variable consideration constraint conservatively until you have 12–18 months of comparable usage data. Customer projections are not a substitute for experience-based estimates.
Evaluate the right-to-invoice expedient with analysis, not assumption — tiered pricing structures require documentation that invoiced amounts correspond to value delivered each period.
Build re-estimation into the close calendar as a primary process step, not a quarterly reconciliation. That's the discipline consumption revenue accounting requires.
For the full framework — including series guidance, committed-minimum structures, and re-estimation requirements — see Revenue Recognition for Consumption-Based and AI-Priced Products.
Frequently Asked Questions
What's the difference between a pure consumption contract and a committed-minimum-plus-overage structure?
A pure consumption contract has no floor. Revenue depends entirely on usage. A committed-minimum structure has a fixed floor recognized ratably or as services are provided, plus variable overage that goes through the variable consideration estimation and constraint process. The accounting is different for each. Getting the contract structure wrong means running the wrong recognition model.
Can I apply the sales-usage royalty exception to AI API contracts?
Only if the fee is a usage-based royalty on a license of intellectual property. If it's a services arrangement rather than an IP license, the exception in ASC 606-10-55-65 doesn't apply and you're in variable consideration territory. The characterization of the arrangement matters. Don't apply the IP royalty exception by default to usage-based pricing; confirm the contract qualifies first.
How conservative should variable consideration estimates be for new AI products?
Conservative enough to reflect actual experience. If you don't have 12-18 months of comparable usage data, customer projections don't substitute for experience-based estimates. Include committed minimums plus variable amounts supported by actual usage actuals. Build the data, then expand the estimate. The constraint test requires probable non-reversal; customer intent doesn't satisfy that standard.
What does the right-to-invoice expedient require for consumption contracts?
That the amount invoiced each period corresponds to the value delivered in that period. For flat per-unit pricing, this is usually straightforward. For tiered pricing where per-unit rates decrease as volume increases, the analysis is required and not automatic. Document that invoiced amounts correspond to proportionate value delivered each period, or treat the contract as variable consideration with an estimated transaction price.
How should close processes change for consumption-based revenue?
Re-estimation needs to be a core step in the close calendar, not a quarterly reconciliation bolted on at the end. Billing data needs to be available before close, not after. The accounting team needs access to usage actuals in something close to real time. Companies that handle this well redesigned the close process for consumption revenue before it became a problem.
