How is Revenue Recognized for Usage-Based and AI Pricing Under ASC 606?

Subscription revenue was complicated, but at least it was predictable. You knew the contract value, you knew the term, and you spread it accordingly. Consumption-based pricing broke that comfort. Revenue is now earned continuously as usage happens, estimates have to be revisited at every close, and the spread of possible outcomes for a single contract can be wide enough to matter.

AI-priced products push the problem further still. When you charge on tokens processed, API calls, compute time, or inference runs, usage can spike without warning, scale non-linearly as a customer grows, and offer no historical baseline at all during the opening months of a contract. The accounting standards themselves haven’t moved (ASC 606 still governs everything here), but the judgment required to apply them gets noticeably harder when there’s no comparable data to lean on.

The Structural Question That Decides Everything Else

Almost every consumption-based contract lands in one of two structures, and the one you have dictates your entire recognition approach. Get this classification right before you write a single line of policy.

Structure 1: Pure consumption, no committed minimum

 The customer pays only for what they actually use, and there’s no revenue floor. Treatment hinges on the nature of the arrangement. If it’s a sales- or usage-based royalty on a license of intellectual property, ASC 606-10-55-65 applies and revenue is recognized only as usage occurs, with no upfront estimation. If instead it’s a service contract (API access, compute time, data processing where you’re providing inference as a service rather than licensing the underlying model) the IP royalty exception does not apply, and you’re back in variable consideration estimation and constraint territory. With thin usage history early on, constrain hard.

Structure 2: Committed minimum plus overage

The customer commits to a base (say $50K a year) and pays overage on anything above that floor. The committed minimum is fixed consideration, recognized ratably or as the service is delivered. The overage is variable consideration, estimated and constrained under ASC 606-10-32-5 through 32-16. This is the dominant shape of AI API and usage-based SaaS contracts because it hands the customer flexibility while guaranteeing the vendor a floor.

The accounting treatment diverges sharply between the two, so identifying your structure is step one, not a detail you sort out later.

Why Consumption Contracts Are Usually a Series

Under ASC 606-10-25-14(a) and 25-14(b), together with 606-10-25-15, a series of distinct goods or services that are substantially the same and transfer in the same pattern can be treated as a single performance obligation. For most consumption contracts this is exactly right: each unit of service (each API call, each token, each compute hour) is distinct and substantially identical to every other unit.

The series treatment earns its keep in two ways. It collapses what would otherwise be thousands of micro-obligations into one, and it opens the door to the right-to-invoice practical expedient under ASC 606-10-55-18. If the amount you invoice each period corresponds to the value delivered that period, you can recognize revenue in that amount without estimating total contract consideration in advance.

There’s a guardrail attached. ASC 606-10-55-18A requires that you have a right to consideration in an amount that reflects performance completed to date, not merely a right to invoice some arbitrary figure. For clean consumption contracts where billing equals usage, the expedient fits comfortably. It stops fitting when the invoiced amount doesn’t track period value, which happens with tiered structures where the per-unit rate shifts with volume and the rate in one period depends on cumulative volume across the whole contract. Run it past your auditor before you rely on it.

What Makes AI-Priced Products Harder to Estimate

The variable consideration framework behaves well when you have history on similar contracts to anchor the estimate. AI-priced products often don’t, especially in the first year of a new model or pricing structure. Three traits make the estimation problem sharper than traditional usage-based pricing.

First, usage variance is extreme. Token consumption can jump dramatically the moment a customer moves a workload into production. A customer sitting at $5K a month in Q1 can be at $80K by Q4. That width forces the constraint to exclude most of the estimated upside until real data accumulates.

Second, there’s no industry benchmark to fall back on. ASC 606-10-32-12 directs the constraint analysis to weigh your experience with similar contracts. For a vendor in year one of a brand-new pricing model, that experience simply doesn’t exist, and the constraint has to reflect its absence. Comparable data is the precondition for expanding a recognized estimate, not an afterthought you bolt on later.

For early-stage AI products specifically: if you’re recognizing revenue on AI-priced contracts in the first year of a new pricing model with no comparable usage data, the defensible position is to recognize only committed minimums plus variable amounts that actuals already support. “We’re confident consumption will be high” is not a supportable basis for booking variable consideration above the constraint. Recognize the conservative number, document the constraint basis at every reporting period, and let the constrained estimate grow as real usage history develops.

Re-Estimation at Scale: The Operational Reality

Fifty consumption-based contracts requiring re-estimation under ASC 606-10-32-14 is a manageable workload. Five thousand is a different animal entirely. Every contract with a variable component needs a fresh estimate each reporting period, refreshed probability weights, a revised constraint analysis, and a catch-up calculation. Done by hand, that’s where close timelines and audit confidence quietly fall apart.

The companies that handle this without drama tend to have three things in place. Billing data and revenue recognition data live in the same system, or a defined integration makes actuals available to accounting before the close rather than after it. Catch-up calculation is automated at the contract level, with exceptions flagged for controller review instead of forcing a manual pass over every contract. And review is tiered: contracts below a materiality threshold get automated treatment, while those above it get controller sign-off on the estimate and constraint assessment.

This is precisely the operational gap a purpose-built revenue management system is meant to close. Softrax RMS automates the complex mechanics of ASC 606 and IFRS 15 (allocation, scheduling, carve-outs, triggers, revaluation of variable consideration) and integrates with more than 200 ERP and financial systems, so the actuals driving each re-estimate are available without a spreadsheet relay race. Re-estimation at scale stops being a quarterly fire drill and becomes a system-supported routine.

The Bottom Line on Revenue Recognition for AI

Consumption-based and AI-priced products don’t call for different accounting standards. They demand a more rigorous application of the ones already on the books. Identify your contract structure, pure consumption versus committed minimum plus overage. Apply the series guidance and evaluate whether the right-to-invoice expedient genuinely fits. Constrain aggressively until usage history exists, and especially so for new AI pricing models. Then build re-estimation into your close as a system-supported operation rather than a manual project that grows more dangerous with every contract you add.

The standards reward companies that can show their work. The ones that struggle are usually the ones still running variable consideration, constraint analysis, and catch-up adjustments through spreadsheets that no longer match the scale of the business. Automating that layer is what turns compliance from a recurring scramble into a controlled process.

See it in action. Schedule a Softrax RMS demo to see how automated allocation, scheduling, and variable-consideration revaluation handle consumption-based and AI-priced contracts under ASC 606 and IFRS 15.