Key Takeaways

AI businesses don't fit neatly into traditional SaaS revenue models. Usage-based pricing, hybrid consumption-plus-subscription contracts, GPU cost pass-throughs, and committed capacity deals all create ASC 606 judgment calls that most accounting teams get wrong the first time. This piece walks through the five most common AI revenue patterns we're seeing in 2026, the recognition question each one raises, and the documentation that will hold up in audit.

Over the last eighteen months, we've seen more AI companies restate or rework their revenue recognition than we saw in the entire previous decade of SaaS. The reason isn't that ASC 606 has changed — it's that the contracts have. Usage-based pricing, API metering, per-seat plus per-call hybrids, compute pass-throughs, and reserved capacity deals all create judgment calls that the five-step model was never explicitly written for.

If you're a founder, CFO, or controller at an AI company, here are the five revenue patterns we see most often in 2026 — and the traps that catch even sophisticated finance teams.

Pattern 1: Pure consumption / usage-based

The customer signs a rate card — $X per million tokens, or $Y per API call, or $Z per GPU-hour — with no minimum commitment. They pay for what they use, invoiced monthly.

The right answer, usually: Recognize revenue as usage occurs (variable consideration, resolved each period). This is the cleanest fit for over-time recognition under ASC 606-10-25-27(b) — the customer consumes the benefit as you perform.

The trap: Teams forget that if the rate itself is tiered or includes volume discounts, the effective rate can shift mid-period. If you bill at a blended list rate but the customer is on track to hit a discount tier, you may be over-recognizing in early months and under-recognizing later. Build the forecast into your revenue process, not just billing.

Pattern 2: Subscription plus overage

"$50,000 per year for up to 100 million tokens, then $0.50 per thousand tokens above that." Familiar — and deceptively complex.

The right answer: The base subscription is a stand-ready obligation recognized ratably. The overage is variable consideration and should be recognized when the usage occurs. Two performance obligations, two patterns.

The trap: Bundling the overage estimate into the base subscription to "smooth" revenue. Under ASC 606, variable consideration can only be included in the transaction price if it's probable that a significant reversal will not occur — and when you do include it, you must use either the expected value approach (a probability-weighted amount across a range of outcomes, best when you have a large population of similar contracts) or the most likely amount method (the single most likely outcome, best for binary or narrow-range outcomes). For most early-stage AI products, usage is too volatile to clear the reversal bar under either method — so don't try to include it at all.

Pattern 3: Committed capacity / reserved compute

The customer commits to $1M of consumption over 12 months, with a rate card that locks in a discount. Any unused capacity expires.

The right answer: This is almost always over-time recognition, but how you recognize matters. If the commitment is effectively a fixed fee (customer will use it one way or another) and the services are substantially homogeneous, ratable recognition may be appropriate. If usage varies materially month-to-month and the customer derives benefit as used, recognize as consumed.

The trap: Assuming "commitments" mean "ratable." They don't. The question is whether the customer obtains control over time in a consistent pattern. We've seen deals where a customer consumed 80% of their commitment in Q4 — and the company was still recognizing 1/12 per month. That's wrong, and it's an audit finding waiting to happen.

Pattern 4: Compute / GPU cost pass-through

"We'll charge you our cost of compute plus a 20% margin." More common than you'd think, especially in enterprise AI deals.

The right answer: Principal vs. agent analysis under ASC 606-10-55-36. If you control the compute before transferring it to the customer (you procure, you bear the cost, you bear the risk of unused capacity), you're the principal — recognize gross. If you're just arranging for a third-party provider to deliver to your customer, you may be an agent — recognize net.

The trap: Defaulting to "gross" because it makes the top line bigger. Auditors will push back hard, and if you're approaching an IPO, the SEC comment letter almost always touches this. Document your principal-vs-agent analysis now, not six months before your S-1.

Pattern 5: Fine-tuning, implementation, and professional services

Many AI deals include an upfront services component: custom fine-tuning, prompt engineering, data pipeline setup, or model integration. Often bundled with the subscription for a single price.

The right answer: Is the service distinct? If the fine-tuned model can be used independently (or the customer could get similar services from a third party), it's a separate performance obligation. Allocate the transaction price based on relative standalone selling price and recognize the service revenue as the work is performed.

The trap: Treating implementation as part of the subscription when the services are highly customized and not separately saleable — that may actually be the right answer in some cases (combined performance obligation), but only if you can support it. Have the analysis in writing, signed off by senior finance, before the contract is signed.

Don't forget contract costs (ASC 340-40)

Even as revenue models evolve, one rule hasn't changed: under ASC 340-40, the incremental costs of obtaining a contract — most commonly sales commissions paid only if the contract is signed — must be capitalized and amortized over the period the related goods or services are transferred to the customer.

For AI companies with fast-growing sales teams, this can lift EBITDA materially. A $2M commission expense in the year of booking becomes a capitalized asset amortized over, say, three years — meaning only about $667K hits the P&L in year one. On a growing AI company's balance sheet, contract-cost assets often become one of the larger line items.

Two things to watch:

What great AI finance teams do differently

Across our clients, the teams that avoid the traps share four habits:

  1. They write a revenue policy memo. A short, clear document that describes each revenue stream, the contract terms, the ASC 606 analysis, and the recognition pattern. Updated when contracts materially change. This is the single highest-leverage accounting artifact an AI company can produce.
  2. They involve accounting in deal structuring. Not to slow deals down — to catch revenue issues before they're papered. A 30-minute review of a non-standard contract can save weeks of audit remediation.
  3. They reforecast variable consideration monthly. Usage patterns change fast in AI. The transaction price and constraint analysis should be living, not something you do at contract inception and forget.
  4. They disaggregate revenue in their reporting. ASC 606 requires revenue to be disaggregated into categories that depict how the nature, amount, timing, and uncertainty of revenue are affected by economic factors. For AI companies, that almost always means splitting usage-based revenue from subscription revenue — and often further by product line, customer segment, or geography. Getting this right early produces cleaner audits, a clearer investor story, and materially easier 10-Q disclosures if you go public.
The difference between an AI company with clean revenue and one facing an audit remediation isn't the complexity of their contracts — it's whether someone looked at the accounting before the contract was signed.

What to do this week

If you're the finance leader at an AI company, three quick actions:

None of this is novel — ASC 606 has been in place since 2018. But the AI business models it's being applied to are genuinely new, and the judgment calls are harder than they look. If you want a second set of eyes on a specific contract or your policy as a whole, we'd be glad to help.


This article is for general informational purposes and should not be relied on as accounting, tax, or legal advice for any specific transaction. Please consult with your advisors.