ASC 606 for AI Startups: Tokens, Inference Credits, and the New Contract Shapes

Q: What if I'm running on someone else's API (e.g., reselling OpenAI)?

That's a different rev rec analysis — agent vs. principal under ASC 606-10-55-36 through 55-40. If you control the service before transfer to the customer, you're principal (recognize gross). If you're just a marketplace/reseller, you're agent (recognize net commission). Most AI wrappers should think carefully about this.

Q: Do I need separate accounting for usage vs. subscription?

Yes. Different revenue categories in your GL. Different recognition patterns. Different metrics reported to investors. Build the chart of accounts to track them separately from day one. ---

Why AI revenue recognition is different

Most ASC 606 guidance was written with traditional SaaS in mind: flat monthly subscriptions, occasional add-ons, predictable usage. AI startups break the model in four ways:

Usage is the primary revenue model. For many AI products, there's no subscription at all — customers pay only for what they consume. Per-token. Per-image. Per-API-call. Per-minute of audio. This is variable consideration at extreme scale.
Reserved capacity is a real thing. Enterprise customers prepay for compute capacity (e.g., dedicated inference endpoints) that they may or may not fully consume. This creates contract liabilities and breakage analysis.
Fine-tuning revenue is a separate service. When a customer pays you to fine-tune a custom model for them, that's distinct from inference usage. It's a discrete deliverable that gets recognized differently.
Hybrid pricing is the norm. Most AI products combine a base subscription, usage charges, and sometimes one-time fees. Each piece needs separate ASC 606 analysis.

These create real accounting complexity. Get it wrong and your revenue numbers will be off by 20-40%.

The four AI revenue patterns

Pattern 1: Pure usage-based (token/call/minute pricing)

Examples: OpenAI API, Anthropic API, Replicate, character.ai per-message billing.

What it looks like:

Customer pays $X per million tokens (input + output separately)
Or $X per second of audio transcribed
Or $X per image generated
No subscription minimum

ASC 606 analysis:

Performance obligation: Stand-ready to deliver inference (a series of distinct services per ASC 606-10-25-15)
Transaction price: Variable consideration entirely
Allocation: 100% to the single PO
Recognition: Practical expedient (ASC 606-10-32-40) — recognize as consumed

Treatment: Recognize revenue when the inference happens, not when the customer prepays credits. Aggregate daily for operational sanity but conceptually it's per-call recognition.

Pattern 2: Subscription + usage overage

Examples: Most B2B AI SaaS — Anthropic Pro/Team plans, Notion AI add-on, Jasper plans.

What it looks like:

Customer pays $20/user/month for "AI features"
Includes a quota (e.g., 100K tokens/month included)
Overage charged per million tokens

ASC 606 analysis:

Performance obligation: Stand-ready obligation (subscription includes inference capacity)
Fixed consideration: $20/user/month
Variable consideration: Overage usage (apply 32-40 expedient)
Recognition: Subscription ratable monthly; overage as incurred

Treatment: Recognize subscription evenly across the term. Recognize overage in the month it's used. Don't try to estimate overage upfront — apply the practical expedient.

Pattern 3: Reserved capacity (committed prepay)

Examples: Enterprise inference contracts — large customers buying dedicated GPU time or committed throughput.

What it looks like:

Customer prepays $500K for 12 months of dedicated inference capacity
Capacity is reserved whether they use it or not
Excess usage above committed level charged separately

ASC 606 analysis:

Performance obligation: Stand-ready capacity (you're holding inference capacity for them)
Fixed consideration: $500K
Variable consideration: Overage above committed level
Recognition method: Ratable over the 12 months (you're delivering capacity continuously, regardless of usage)

Treatment: Recognize $41,667/month for the prepay. Track usage but the revenue isn't usage-driven — it's capacity-driven. If the customer uses less than they committed, you still recognize the full amount (no breakage — they paid for capacity, not consumption).

This is meaningfully different from Pattern 2 (subscription + overage). Pattern 3 customers paid for capacity reservation, not for usage. Don't conflate them.

Pattern 4: Fine-tuning / custom model fees

Examples: Companies that train custom models for enterprise customers (e.g., Anthropic offering custom Claude variants, smaller companies doing custom fine-tuning).

What it looks like:

Customer pays $50K-$500K to fine-tune a model on their data
Plus ongoing per-inference fees for using the custom model
Sometimes plus a license fee for exclusive use

ASC 606 analysis:

Multiple performance obligations:
- Fine-tuning service (one-time deliverable)
- Hosted inference of the custom model (subscription/usage)
- Exclusive license (if applicable)
Each is potentially distinct under ASC 606-10-25-19
Recognition:
- Fine-tuning: point-in-time when model is delivered (or over time if cost-to-cost can be measured)
- Inference: as consumed (Pattern 1)
- License: depends on functional vs. symbolic IP nature

Treatment: Bifurcate the contract into distinct POs. Allocate transaction price based on relative SSP. Recognize each PO per its own pattern.

This is the most complex AI revenue pattern. Most founders try to lump it together — auditors don't like that.

The judgment calls that show up most often

Judgment 1: Is "model access" a license or a service?

When a customer pays for access to your AI model, is that:

A license of intellectual property (point-in-time recognition under ASC 606-10-55-58A), or
A service (over-time recognition)?

For most B2B AI products, it's a service. Customers don't get to download your model weights. They access your API. The model lives on your infrastructure. You're providing inference-as-a-service.

But fine-tuned models that get deployed to the customer's environment (or are exclusively licensed) can be considered IP licenses. The treatment depends on:

Does the customer control the model after delivery?
Can they use the model without your ongoing service?
Is the value primarily in the IP or in the ongoing inference?

For most cases: service. Document the reasoning.

Judgment 2: How do you handle prepaid credits with no expiration?

Many AI APIs let customers prepay (e.g., $1,000 in OpenAI credits). The credits often don't expire.

Treatment:

Prepayment creates a contract liability (deferred revenue)
Recognize as credits are consumed
If credits truly never expire, no breakage analysis needed (yet)
If credits expire after a long period (e.g., 2 years), analyze breakage per ASC 606-10-55-46/49

Most AI startups make a policy choice: credits expire after 12-24 months. Then breakage applies.

Judgment 3: Refundable vs. non-refundable credits

If your customer can request a refund of unused credits, that's variable consideration with a constraint. You probably can't recognize the full amount until the refund window closes.

If credits are explicitly non-refundable, you can recognize as consumed without significant constraint.

Judgment 4: Free tier conversions

Many AI products give away inference for free up to a quota. The economics: you're absorbing cost (compute, GPU) without revenue.

Free tier usage is NOT revenue. Don't recognize any revenue for free tier inferences. The cost is just R&D / customer acquisition expense.

When a free user converts to paid, the new contract starts fresh. Don't try to retrospectively allocate "free tier value" — there isn't any from an accounting perspective.

Judgment 5: Volume discounts in usage pricing

Most usage pricing has volume tiers. $0.20 per million tokens up to 100M. $0.15 above 100M. $0.10 above 1B.

If you can estimate the customer's usage band, recognize at the expected price. If usage is volatile, recognize at the actual blended rate as you go. The practical expedient under 32-40 lets you mostly avoid upfront estimation.

Judgment 6: Fine-tuning costs as customer acquisition

If you give a customer free fine-tuning to land their business, the fine-tuning cost is an SG&A expense, not COGS. No revenue offset.

But if the fine-tuning is part of a paid contract (even at a discount), allocate the consideration to the fine-tuning PO based on relative SSP. Don't treat it as "free."

A worked example: Hybrid AI contract

Scenario: AI startup signs an enterprise customer to a 12-month contract on January 1, 2026.

$200K annual subscription (includes 50M tokens/month)
$0.05 per 1,000 tokens above the included quota
$30K one-time fine-tuning fee (delivered March 2026)
12-month exclusive use of the fine-tuned model

Performance obligations:

Base subscription (stand-ready obligation, ratable)
Fine-tuning service (one-time deliverable, point-in-time)
Hosting of fine-tuned model (could be combined with PO1 if not distinct)
Exclusive license to the fine-tuned model (potentially distinct if functional IP)

Transaction price:

Fixed: $200K + $30K = $230K
Variable: overage tokens (estimate based on customer's projected usage, apply expedient)

Allocation (using SSPs):

Base subscription SSP: $200K (priced standalone)
Fine-tuning SSP: $40K (customer-specific based on cost-plus method)
Exclusive license SSP: $5K (residual method)
Total SSP: $245K → allocation factor of $230K / $245K = 93.88%
- Base subscription: $200K × 93.88% = $187,755
- Fine-tuning: $40K × 93.88% = $37,551
- Exclusive license: $5K × 93.88% = $4,694

Wait — the allocated amount totals $230K. ✓

Recognition:

Base subscription: $187,755 / 12 = $15,646/month ratably
Fine-tuning: $37,551 fully recognized in March (when delivered)
Exclusive license: $4,694 / 12 = $391/month ratably (functional IP delivered over the license term)
Overage: as consumed each month

Judgments documented:

Distinct PO determination for fine-tuning (capable of being distinct + separately identifiable)
SSP for fine-tuning (cost-plus method, since no observable standalone sales)
Treatment of exclusive license (functional IP, over-time recognition over the exclusivity term)
Practical expedient applied to overage
Variable consideration estimate constrained to zero (no historical data)

This contract has 4 POs, 3 SSP determinations, 4 judgments, and a variable consideration constraint. Done in a spreadsheet, this is a 6-hour analysis per contract. Done in a tool, it's a 15-minute review of the AI's proposed treatment.

The most common AI startup mistakes

Mistake 1: Treating all usage as recurring revenue

Pure usage-based revenue is not "recurring" in the traditional MRR sense. Reporting it as recurring revenue can mislead investors. The right reporting:

Consumption revenue (usage-based, volatile)
Subscription revenue (recurring, predictable)
Services revenue (one-time, project-based)

Three categories. Don't conflate them.

Mistake 2: Recognizing prepaid credits as revenue at receipt

Customer prepays $10K for credits. You don't have $10K of revenue. You have $10K of contract liability. Recognize as credits are consumed.

Mistake 3: Missing the fine-tuning PO separation

Founders often bundle fine-tuning with subscription in their accounting. Wrong. Fine-tuning is a distinct service with a point-in-time recognition. Bifurcate.

Mistake 4: Not handling free tier costs correctly

Free tier compute costs are R&D or customer acquisition. They're not COGS until the user converts to paid. Watch your gross margin calculations.

Mistake 5: Over-estimating variable consideration

When in doubt, constrain heavily. Recognizing aggressive usage estimates that don't materialize creates true-down adjustments that auditors flag and investors question.

Mistake 6: Treating reserved capacity as usage revenue

A customer who paid for committed capacity gets revenue recognized based on the capacity, not their usage. If they use 60% of what they paid for, you still recognize 100% — they paid for the reservation.

How to report AI revenue to investors

Three breakdowns matter:

Subscription / Recurring revenue: Predictable, ratable. The MRR/ARR number.
Consumption / Usage revenue: Variable, growth-driven. Track usage growth as a separate metric.
Services / One-time revenue: Project-based. Volatile but high-margin.

Report all three separately in your board updates. Investors are sophisticated enough to value each appropriately. Pretending all $1M of your revenue is "ARR" when half is usage-based hurts your credibility when due diligence reveals the truth.

Frequently asked questions

Is per-token pricing considered "recurring" revenue?

No. It's usage / consumption revenue. Don't include it in MRR/ARR calculations as if it were recurring. Track it separately.

How do I forecast usage revenue for investor decks?

Use historical usage trends, customer cohort analysis, and growth assumptions. Make the assumptions transparent. Investors expect usage revenue to be more volatile than subscription revenue.

What about retroactive pricing changes?

If you change your pricing mid-contract (with customer agreement), that's a contract modification. Apply the modification framework (separate contract / prospective / cumulative catch-up).

Do I need different rev rec policies for B2C vs. B2B?

The accounting principles are the same. But B2C contracts (e.g., a consumer paying $20/month for AI access) have different practical considerations: shorter commitment periods, higher churn, simpler structures.

How do I handle credits that customers refund?

Refundable credits create variable consideration. Constrain them out of revenue until the refund window expires. If you have historical refund data, you can use it to estimate the expected refund amount.

What if my customer is using my AI in their commercial product? Does that change anything?

Not from ASC 606 standpoint. The customer's use case doesn't affect your revenue recognition. (It might affect your contract terms — e.g., revenue share clauses — which would create their own analysis.)

What's the right gross margin metric for AI businesses?

This is hotly debated. The conservative view: include all compute, GPU, and inference costs in COGS. The aggressive view: treat compute as R&D and have very high software-margin metrics. Most AI startups land somewhere in between. Be consistent and disclose your methodology.

Should I capitalize my model development costs?

Generally no for early-stage. Model development is R&D under ASC 730. Capitalization is allowed under ASC 985-20 for some software costs but it's complex and rarely worth it for AI startups <$10M ARR.

What if I'm running on someone else's API (e.g., reselling OpenAI)?

That's a different rev rec analysis — agent vs. principal under ASC 606-10-55-36 through 55-40. If you control the service before transfer to the customer, you're principal (recognize gross). If you're just a marketplace/reseller, you're agent (recognize net commission). Most AI wrappers should think carefully about this.

Do I need separate accounting for usage vs. subscription?

Yes. Different revenue categories in your GL. Different recognition patterns. Different metrics reported to investors. Build the chart of accounts to track them separately from day one.

The bottom line

AI revenue recognition is harder than traditional SaaS because the pricing models are messier. Pure usage, hybrid subscription + usage, reserved capacity, fine-tuning fees, exclusive licenses — each is a different accounting story.

The fundamentals of ASC 606 still apply. The challenge is applying them consistently across hundreds of contracts that mix and match these patterns.

For AI startups specifically, the right approach is:

Categorize each revenue stream (subscription, usage, services, capacity)
Apply ASC 606 treatment per category
Document judgments per contract
Report revenue categories separately to investors

In a spreadsheet, this is brutal. In a tool, it's manageable.

If you're an AI startup struggling to map your contracts to ASC 606, try RevRec Engine. Built for AI-native SaaS founders. Handles per-token billing, reserved capacity, fine-tuning fees, and hybrid pricing natively. Audit-defensible workpapers for each contract. Free up to 3 contracts.

About the author: Chris is a CPA and founder of RevRec Engine. He's worked with AI startups on revenue recognition since 2022, including companies in inference-as-a-service, voice AI, image generation, and enterprise AI agents.

Related reading: