Revenue Recognition Policy Design for Credit-Based AI Products

Every credit-based AI product forces a set of revenue recognition decisions that ASC 606 has always technically required but that subscription-era finance teams never actually had to make. The standard hasn't changed. What's changed is that usage is now volatile, non-linear, and often the majority of contract value, which means judgment calls that used to be minor now determine whether the financials hold up under audit.

Subscription revenue recognition ran on rails: fixed fee, ratable release over a known term, deferred revenue unwinding on a schedule finance could set at contract signing and forget. Credit-based AI products break that model in three ways at once. The dollar amount is variable, since credits consumed swing by period and by customer. The timing is uncertain, since a chunk of purchased credits may never get used at all, a problem called breakage. And the pattern is non-linear: a customer running light workloads in Q1 can spike to multiples of that spend by Q4 once a project moves from pilot to production. None of this is hypothetical anymore. Per the 2025 Monetization Monitor, 59% of software companies expect usage-based approaches to grow as a share of revenue this year, up 18 percentage points from 2023, and credit models among the top 500 AI and SaaS companies grew 126% in a single year. Pure seat-based pricing fell from 21% to 15% over the same period, while hybrid consumption models grew from 27% to 41%. The finance team confronting this for the first time isn't behind or misconfigured. It's just facing questions the standard always contained but that never used to matter this much.

The structural question that determines everything: does a committed minimum exist

Before any recognition policy gets drafted, every contract has to get sorted into one of two structures, because the accounting treatment diverges completely depending on which one applies.

Structure A is pure pay-as-you-go: the customer pays only for what they consume, with no revenue floor. If that arrangement qualifies as a sales- or usage-based royalty on a license of intellectual property, ASC 606-10-55-65 governs, and revenue gets recognized only as usage occurs, with no upfront estimation required at all. But if the arrangement is a service contract, meaning API access, inference as a service, or compute time where the vendor is providing a service rather than licensing a model, the royalty exception doesn't apply. Variable consideration estimation and the constraint take over instead. Whether an AI inference product is a license or a service is not always obvious on its face, and it needs to get resolved with auditors before a word of policy gets written.

Structure B is a committed minimum plus overage, and it's the dominant shape of enterprise AI contracts. The customer commits to a base spend, say a fixed annual amount, and pays overage for anything consumed above that floor. The committed minimum is fixed consideration, recognized ratably or as service is delivered. The overage is variable consideration, estimated and constrained separately under ASC 606-10-32-5 through 32-16. These are not the same accounting event just because they land on the same invoice. OpenAI, Anthropic, and Cohere all price consumption at the API level by token, yet enterprise buyers frequently negotiate committed-use deals for predictability, making Structure B a common shape at enterprise scale.

A company running direct API pay-as-you-go alongside enterprise committed deals needs two sub-policies. One policy applied uniformly across both structures will misstate one of them.

Variable consideration and the constraint: what "probable no significant reversal" actually requires for AI consumption

ASC 606-10-32-5 through 32-16 says variable consideration only enters the transaction price to the extent it's probable a significant revenue reversal won't occur once the uncertainty resolves. Subscription SaaS could handle this without much strain, since the variable slice (overages, add-ons) was usually small next to a known base. Credit-based AI products flip that ratio. The variable component can be the majority of the contract's value, which means the constraint analysis is no longer a footnote decision, it's the central judgment call in the policy.

Three things make this harder than ordinary usage-based pricing. First, the variance in usage is wide: token consumption doesn't creep, it jumps, especially as workloads move from test environments into production. A customer's Q4 run rate can be several multiples of Q1, and that width forces an aggressive constraint until actual consumption data piles up. Second, there's often no benchmark to lean on. ASC 606-10-32-12 requires the constraint analysis to draw on experience with similar contracts, but a vendor in year one of a new pricing model, or a new model version, simply doesn't have that experience yet, and the constraint has to reflect that absence honestly rather than borrow confidence from adjacent products. Third, model version changes reset comparability. When the underlying model gets updated, different token costs, different inference behavior, the prior cohort's usage data may no longer describe what customers will do next, and finance has to document whether that older cohort still counts as "similar contracts" for constraint purposes.

The defensible position for early-stage AI contracts without comparable data is narrow: recognize the committed minimums, plus whatever variable amount actuals already support. "Consumption is trending high" is a forecast, not a basis for releasing the constraint. Cohen and Company's 2025 ASC 606 compliance analysis found that transaction price allocation, specifically variable consideration, SSP estimates, and discounts, is where errors cluster most for software and SaaS companies. That tracks with a broader pattern: improper revenue recognition accounts for 43% of all SEC enforcement incidents, according to the Anti-Fraud Collaboration's analysis of more than 500 enforcement actions. The constraint methodology needs to be written down, applied the same way every close, and revisited every period. It is not a judgment call made once at contract signing and then filed away.

The usage-based royalty exception and whether your AI product qualifies

ASC 606-10-55-65 carves out sales- or usage-based royalties tied to a license of intellectual property: recognize revenue only as the underlying sale or usage happens, skip the upfront estimation, skip the constraint analysis entirely. For a pure pay-as-you-go AI product, that exception is tempting, because it removes the estimation burden altogether. The catch is that it only applies if the arrangement is actually a license of IP, not a service.

The line between the two matters more than it looks. A license of IP means the customer gains rights to use the model itself, for instance a model-weights license or a self-hosted deployment where the customer runs the model on its own infrastructure. A service contract means the vendor runs inference on its own infrastructure: the customer sends inputs, gets outputs back, and the model never leaves the vendor's servers. That second structure is how most API-based AI products actually work, OpenAI, Anthropic, and comparable vendors price by token at the API level, and where such arrangements are structured as services rather than IP licenses, the royalty exception simply doesn't apply. Variable consideration constraint governs instead, full stop.

Getting this wrong isn't a disclosure footnote problem, it's a methodology problem. A finance team that applies the royalty exception to what's actually a service contract has skipped required estimation and constraint steps that ASC 606 demands, and an auditor catching that will require restatement, not a revised disclosure. On-premises or sovereign-cloud deployments, where the model is genuinely licensed and run on the customer's own infrastructure, may qualify for the exception, but the policy has to document the legal structure of the deal, not the commercial pitch used to sell it. Legal, finance, and product need to classify each offering jointly at the point of contract design, before the first invoice goes out.

Deferred revenue on prepaid credits: the liability, the breakage estimate, and the disclosure

Selling credits upfront creates a contract liability on day one. Cash comes in, but no performance obligation has been satisfied yet, so it sits on the balance sheet as deferred revenue until each credit gets consumed. Revenue only moves off that liability as consumption events actually occur.

Then there's breakage: some portion of purchased credits will lapse, expire, or simply never get used because the customer churns. The vendor keeps cash for a service it will never deliver, and ASC 606 requires that breakage get estimated and recognized, either proportionally as credits are consumed (if the entity expects to be entitled to a breakage amount) or only once the likelihood of exercise becomes remote (if it doesn't). Two methods follow from that split. Pro-rata breakage spreads the expected unused portion across the consumption period, recognizing it in proportion to how credits actually get used. Remote likelihood waits: it recognizes the leftover deferred balance only once exercise becomes unlikely, say at contract expiry or confirmed churn. Choosing between them is a policy election, not a one-off judgment, and it has to be documented, disclosed, and applied the same way every period. Switching methods later requires its own disclosure and justification.

Pro-rata breakage in particular needs real inputs: historical credit utilization by cohort, renewal behavior, expiration terms in the contract. Most early-stage AI companies don't have that data yet in year one, which narrows the defensible options considerably. Whatever method gets chosen, it belongs in the revenue recognition footnote, and auditors will check that the disclosed method actually matches the recognition pattern in the books, not just what the policy memo says.

There's a further wrinkle for hybrid contracts. A customer holding a subscription plus a prepaid credit balance at the same time has two separate deferred revenue streams unwinding on two different schedules, and they can't get netted into one liability line without a specific policy justification for doing so. Per Bain & Company's analysis of more than 30 SaaS vendors introducing generative AI capabilities, roughly 65% had adopted hybrid pricing. Subscription-plus-credits is now the common commercial form, which makes the dual deferred revenue problem the normal case finance has to build for, not an edge case to handle later.

Series guidance and the right-to-invoice practical expedient, and when they are and are not available

ASC 606-10-25-14(a), 25-14(b), and 25-15 let a series of distinct goods or services get treated as a single performance obligation, provided they're substantially the same and transfer in the same pattern. For most API-based AI products, that fits well: each API call, each token processed, each agent action is distinct but substantially identical to the last one, so treating the whole stream as one performance obligation is both simpler and defensible.

That opens the door to the practical expedient under ASC 606-10-55-18: if the amount invoiced each period matches the value delivered that period, revenue gets recognized in the invoiced amount, with no need to estimate total contract consideration upfront. ASC 606-10-55-18A tightens that a little: the right to consideration has to reflect performance actually completed to date, not just a contractual right to invoice whatever number shows up on the bill.

The expedient works cleanly in two situations: pure pay-as-you-go contracts where billing tracks usage at a flat per-unit rate, and committed-minimum contracts where the overage rate stays fixed regardless of cumulative volume. It breaks down elsewhere. Tiered pricing, where the per-unit rate changes based on cumulative volume across the contract, means this period's invoice reflects a rate set by past periods, not just this period's value, so the expedient becomes unreliable. Volume discount structures with retroactive rate adjustments based on end-of-term volume have the same problem: the invoice doesn't isolate the period's actual value delivered. Auditors need to sign off on expedient availability before it gets baked into policy, because a consumption-based contract doesn't automatically qualify just because it's consumption-based.

Series treatment also depends on the service staying "substantially the same" across every period. When a vendor rolls out a new model version with materially different capability, finance has to work out whether that's still the same service for series purposes, or whether it's actually a contract modification requiring its own treatment.

Re-estimation cadence: how often the variable consideration estimate must be revised and what triggers an off-cycle update

ASC 606 requires the variable consideration estimate to get updated at every reporting date, at every reporting date, with higher-frequency updates common for companies with material usage revenue. A company running hundreds of AI API contracts, each on its own usage trajectory with its own committed minimum and overage estimate, can't revise all of that by hand. The process has to be systematized or it doesn't scale.

The standard close-cycle sequence looks like this: pull actual credits consumed and actual overage incurred from the metering system, compare those actuals against the prior period's variable consideration estimate, quantify whatever cumulative catch-up adjustment the gap requires, then update the forward estimate for remaining contract periods using the latest usage trajectory. Apply the constraint to that updated forward estimate, document the basis for any constraint release, and record the cumulative catch-up in the current period under ASC 606's cumulative catch-up method.

Some events can't wait for the next scheduled close. A customer whose usage spikes mid-contract, say a production launch that multiplies consumption overnight, needs an immediate reassessment. So does a model version change or pricing update that resets the comparability of historical data, or a contract modification where a customer upgrades their committed minimum or extends the term. A customer signaling they won't use their remaining credits triggers its own reassessment, this time of breakage timing rather than the consumption estimate.

None of this works without clean metering data. If the billing system can't produce accurate per-contract consumption actuals at close, the re-estimation process falls back on spreadsheet reconciliation, and that scales poorly and invites error. Among companies building AI-enabled products, running several fragmented billing codepaths tends to mean the first week of every month gets spent reconciling consumption data across systems before any actual recognition work can start. That's the operational failure mode the re-estimation cadence exposes, and it's a data infrastructure problem well before it's an accounting one.

Standalone selling price for credits and the allocation problem in hybrid contracts

When a contract bundles a subscription together with a prepaid credit allocation, ASC 606 requires allocating the transaction price across each performance obligation based on relative standalone selling price. That means the subscription piece and the credit piece each need their own defensible SSP, established by what each would sell for on its own, not by whatever split looks convenient on the invoice.

For a vendor that sells the subscription and the credit pack separately at observable prices, this is workable: relative SSP is directly observable, and allocation follows the standard approach with little judgment involved. The harder case is the vendor that only ever sells the bundle, where no standalone credit price exists in the market to point to. That forces an estimated SSP, built from cost-plus-margin, from adjacent market data, or from a residual approach where the subscription's observable price gets used to back into the credit allocation. Whichever method gets picked, it has to be documented and applied consistently across contracts of the same type, because inconsistent SSP methodology across similar deals is exactly the kind of thing that draws audit scrutiny under the allocation guidance in ASC 606-10-32-28 through 32-41.

The credit-based AI product hasn't broken ASC 606. It's just made every judgment call inside it load-bearing in a way subscription pricing never did, and a policy that treats these seven decisions as one-time setup rather than a recurring discipline won't survive its first real audit.