Consumption-based revenue, where customers pay for what they use rather than a fixed periodic fee, creates specific ASC 606 challenges that seat-based SaaS models rarely face: variable consideration that varies in every billing period, potential usage-based royalty exceptions, and re-estimation requirements that scale with contract volume. AI-priced products add a layer of unpredictability, as token or compute consumption can be highly volatile and hard to estimate from historical data. The core question in every consumption contract is whether a committed minimum exists, because the answer determines whether you estimate and constrain upfront, or recognize revenue only as usage occurs.
Variable consideration: ASC 606-10-32-5 through 32-16 · Usage-based royalty exception: ASC 606-10-55-65 · Series guidance: ASC 606-10-25-14(a) and 25-14(b) and 606-10-25-15
Subscription revenue was complex but predictable. Consumption-based pricing changed that — revenue is earned continuously as usage occurs; estimates must be revised at every close, and the range of possible outcomes for any given contract can be significant.
AI-priced products charge on tokens processed, API calls, compute time, or inference runs, push this further. Usage patterns can spike unpredictably, scale non-linearly with customer growth, and have no historical baseline in the early months of a contract. The standards haven’t changed (ASC 606 governs all of it), but the judgment calls required to apply them are harder when comparable data doesn’t exist yet.
The Structural Question That Determines Your Approach
Most consumption-based contracts fall into one of two structures, and which one you have determines your entire recognition approach.
Structure 1: No committed minimum (pure consumption). The customer pays only for what they use. There is no floor on revenue. The accounting depends on contract structure: if the arrangement is a sales- or usage-based royalty on a license of intellectual property, ASC 606-10-55-65 applies — revenue is recognized only as usage occurs, no upfront estimation required. If the arrangement is a service contract — API access, compute time, data processing where the vendor provides inference as a service rather than licensing the underlying model — the IP royalty exception does not apply, and variable consideration estimation and constraint govern. With limited usage history in early periods, constrain aggressively.
Structure 2: Committed minimum plus overage. The customer commits to a base amount — $50K annually, for example, and pays overage fees for consumption above that floor. The committed minimum is fixed consideration, recognized ratably or as the service is provided. The overage is variable consideration, estimated and constrained under ASC 606-10-32-5 through 32-16. This structure is common in AI API contracts and usage-based SaaS because it gives the customer flexibility while giving the vendor a revenue floor.
Know which structure you have before building your recognition policy, because the accounting treatment is very different between them.
Why Consumption Contracts Are Usually a Series
Under ASC 606-10-25-14(a) and 25-14(b) and 606-10-25-15, a series of distinct goods or services that are substantially the same and have the same pattern of transfer can be treated as a single performance obligation. For most consumption-based contracts, this is the right treatment as each unit of service (each API call, each token processed, each compute hour) is distinct and substantially the same as every other unit.
The series guidance matters for two reasons. First, it simplifies the performance obligation structure — instead of thousands of individual micro-obligations, you have one. Second, it allows use of the “right to invoice” practical expedient under ASC 606-10-55-18: if the amount invoiced each period corresponds to the value delivered, you can recognize revenue in that amount without estimating total contract consideration upfront.
ASC 606-10-55-18A adds a constraint: the entity must have a right to consideration in the amount that reflects performance completed to date — not simply the right to invoice any amount. For straightforward consumption contracts where billing equals usage, this is clean and appropriate. It’s not available when the invoiced amount doesn’t reflect period value — which can happen with tiered pricing structures where per-unit rates change with volume, and where the rate applicable in one period depends on cumulative volume across the contract. Confirm with your auditor before applying it.
What Makes AI-Priced Products Harder to Estimate
The variable consideration framework works reasonably well when you have historical data on similar contracts. AI-priced products frequently don’t — especially in the first year of a new model or pricing structure.
Three characteristics of AI consumption make estimation harder than traditional usage-based pricing:
- High variance in usage patterns. Token consumption can spike dramatically as customers move workloads into production. A customer at $5K monthly in Q1 might be at $80K by Q4. That distribution width means the constraint will exclude most of the estimated upside until actual data accumulates.
- No industry benchmark data. ASC 606-10-32-12 requires the constraint analysis to account for experience with similar contracts. For AI vendors in year one of a new pricing model, that experience doesn’t exist yet — and the constraint must reflect that absence. Comparable data is the precondition for expanding the recognized estimate, not an afterthought.
Early-stage AI product guidance
If you’re recognizing revenue on AI-priced contracts in the first year of a new pricing model, with no comparable usage data, the prudent constraint position is to recognize only committed minimums plus variable amounts supported by actuals. “We believe consumption will be high” is not a supportable basis for including variable consideration above the constraint. Recognize the conservative amount and document the constraint basis at each reporting period; as comparable usage data develops, the constrained estimate can expand.
Re-estimation at Scale — The Operational Reality
A company with 50 consumption-based contracts that require re-estimation under ASC 606-10-32-14 is manageable. It’s an operational challenge for a company with 5,000. Every contract with a variable component requires a fresh estimate at each reporting period, updated probability weights, revised constraint analysis and catch-up calculation.
Companies that handle this well have three things in place:
- Billing data and rev rec data in the same system, or a defined integration that makes actuals available to accounting before close, not after.
- Automated catch-up calculation at the contract level, with exceptions flagged for controller review rather than manual review of every contract.
- A tiered review process: contracts below a materiality threshold get automated treatment; contracts above it get controller sign-off on the estimate and constraint assessment.
The Bottom Line of Revenue Recognition for AI
Consumption-based and AI-priced products don’t require different accounting standards, they require more rigorous application of the ones that exist. Identify your contract structure (pure consumption vs. committed minimum plus overage). Apply the series guidance and evaluate the right-to-invoice expedient. Constrain aggressively until usage history develops, especially for new AI pricing models. And build re-estimation into your close process as a system-supported operation, not a manual project.
Frequently Asked Questions
How is revenue recognized for consumption-based SaaS contracts under ASC 606?
It depends on whether the contract has a committed minimum. For pure consumption contracts with no floor, revenue is recognized as usage occurs: either under the usage-based royalty exception (ASC 606-10-55-65) for IP licenses, or by estimating and heavily constraining variable consideration when there is limited usage history. For committed-minimum-plus-overage structures, the committed amount is recognized ratably or as service is provided; the overage is variable consideration subject to estimation and the constraint test.
Does the usage-based royalty exception apply to AI API pricing?
Possibly, but it depends on contract structure. The exception under ASC 606-10-55-65 applies to sales- or usage-based royalties on licenses of intellectual property. An AI API contract that grants a license to use a model and charges based on inference runs may qualify. An API access arrangement structured as a service contract, where the vendor provides inference as a service rather than licensing the underlying model, likely does not. The distinction matters significantly for when revenue is recognized, and it’s worth a specific conversation with your auditor.
What is the “right to invoice” practical expedient, and when does it apply to consumption contracts?
The right-to-invoice expedient (ASC 606-10-55-18) allows a company to recognize revenue in the amount it has the right to invoice if that amount corresponds to the value the customer received in that period. For consumption contracts where billing equals usage and usage equals value delivered, this eliminates the need to estimate total contract consideration and allocate proportionally. The expedient is not available when invoiced amounts don’t reflect period value which is common in tiered pricing structures where per-unit rates change with volume.
How should AI companies constrain variable consideration when they have no usage history?
Aggressively, until data develops. ASC 606-10-32-12 includes a lack of experience with similar contracts as a factor that increases the likelihood of a significant revenue reversal. For AI-priced products in their first year of a new pricing model, that factor weighs heavily. The practical position is to recognize committed minimums plus variable amounts supported by actual usage data and expand the recognized estimate as comparable contract history accumulates. Document the constraint analysis and the basis for your estimate at each reporting period.
For the full revenue recognition framework, see the Enterprise Revenue Recognition Guide. For a practitioner to look at where consumption-based recognition breaks down in practice, see Consumption-Based Revenue Recognition in Practice: What Finance Teams Get Wrong on Rev-Venue.
