Ask a SaaS founder in 2022 how much revenue they'd book this month, and the answer was a spreadsheet formula: seats times price, prorated for the days left in the contract. Ask an AI-native founder the same question today, and the honest answer is "it depends how much our customers used the model." Token consumption can double in a week when a customer pushes a feature into production, or flatline when they pause an experiment. There's no seat count to anchor the forecast to.
That shift from subscription to consumption isn't just a pricing decision. It's an accounting problem, and it lands squarely inside ASC 606 — the same revenue recognition standard that's governed SaaS since 2018, just applied to a much less predictable input. Get it wrong and you're not looking at a rounding error; you're looking at a restated year during due diligence, right when you can least afford it.
Why Token-Based Pricing Breaks the Old Playbook
Traditional SaaS revenue recognition is comparatively forgiving. A customer pays $12,000 for an annual plan, you recognize $1,000 a month, and the biggest judgment call is whether a contract modification requires reallocation. The consideration is fixed. The performance obligation — access to the software over time — is straightforward. Auditors have seen a thousand contracts just like it.
AI and usage-based pricing removes the fixed part. Customers pay for tokens processed, API calls made, inference runs completed, or compute-seconds consumed. That consideration is variable by design, and ASC 606 has a whole section — the "variable consideration" guidance in ASC 606-10-32-11 through 32-13 — devoted to exactly this problem. The core challenge isn't philosophical, it's practical: how much revenue do you recognize in a period when you genuinely don't know, at the moment you close your books, exactly how much a customer will end up owing?
For an early-stage AI company, this gets harder before it gets easier. A mature SaaS business can lean on years of usage history to estimate consumption confidently. A company that shipped its token-based pricing model eight months ago has no such comparables. Usage can swing wildly as customers move from pilot to production, and last quarter's pattern may say little about this quarter's.
The Two Contract Shapes That Determine Everything
Before you can recognize a dollar of usage-based revenue correctly, you need to know which of two structures you're actually in — because they're accounted for differently.
Pure consumption, no committed minimum. The customer buys a pool of credits or agrees to pay per unit consumed, with no floor. If the arrangement is a straightforward service (you're providing access to a hosted model, not licensing IP the customer exploits independently), you generally can't use the narrow "usage-based royalty on IP" exception in ASC 606-10-55-65 — that's built for licensing arrangements like royalties on a patent, not for a hosted API. Instead, you estimate variable consideration using the expected value or most likely amount method, subject to the constraint that you shouldn't recognize amounts where a "significant reversal" is probable once uncertainty resolves.
Committed minimum plus overage. The customer commits to, say, $2,000 a month of usage and pays more if they exceed it. Here the floor behaves like fixed consideration — recognize it on a systematic basis as the customer receives value — while anything above the minimum is variable consideration subject to the same estimation and constraint rules. This hybrid shows up constantly in AI pricing: a base platform fee plus metered inference on top.
Knowing which shape you're in changes your journal entries, your disclosure footnotes, and how nervous your auditor should be about your estimates.
The Practical Expedient Most AI Companies Actually Use
Here's the good news: ASC 606 has a shortcut built for exactly this situation, and most well-structured usage-based contracts qualify for it.
The "right to invoice" practical expedient (ASC 606-10-55-18) lets you skip estimating total contract consideration altogether. If what you invoice each period corresponds directly to the value the customer received in that period — you charged $0.002 per 1,000 tokens, the customer used 4 million tokens, you bill $8 — you can simply recognize that $8 as revenue in the period it was earned. No forecasting, no constraint analysis, no re-estimation at each close.
The catch is in the phrase "corresponds directly." If your pricing has tiers where the per-unit rate drops as volume increases, or bundled discounts that don't map cleanly to the period in which usage occurred, the expedient can break down — the invoiced amount stops representing that period's value, and you're back to full variable-consideration estimation. Review your pricing structure with this test specifically in mind before assuming the expedient applies uniformly across your contract book.
Most consumption-based AI contracts also qualify for series treatment under ASC 606-10-25-14: instead of accounting for each API call as its own micro-performance-obligation, you treat the whole stream of usage as one single performance obligation satisfied over time. This is what makes the invoicing expedient administratively workable — you're not tracking thousands of individual obligations, you're tracking one ongoing service with a variable price tag.
Prepaid Credits: Deferred Revenue and the Breakage Problem
Plenty of AI platforms sell prepaid credit packs — buy $500 of tokens upfront, draw them down over the following months. This structure is popular because it improves cash flow and locks in commitment, but it introduces two accounting obligations founders routinely miss.
Deferred revenue on the unused balance. The moment cash lands for a prepaid pack, none of it is revenue yet. It's a liability — you owe the customer either the service or a refund. Revenue moves from the deferred revenue line to the income statement only as tokens are actually consumed. A founder who books the full $500 the day it's collected is overstating revenue and will have to unwind it, usually at the worst possible time: during fundraising diligence, when an auditor rebuilds the schedule and knocks the difference back out of a period that's already been pitched to investors.
Breakage on credits that never get used. Some customers buy a credit pack and never draw it all down before it expires. That unused balance — breakage — isn't simply free money you recognize the day the credits expire. Under ASC 606, you're expected to estimate the breakage rate from historical redemption patterns and recognize that estimated breakage proportionally, as a small uplift to revenue alongside actual usage, rather than waiting for expiration to book it all at once. If you don't have redemption history yet (common for a new credits program), the conservative approach is to wait until you do, recognizing breakage only upon expiration in the meantime, and revisit the policy once you have a few cohorts of data.
Where Constraint Discipline Actually Matters
The "constraint" on variable consideration sounds abstract until you've lived through a quarter where a big customer's usage spiked 4x and then reverted. ASC 606 asks you to include variable consideration in your revenue estimate only to the extent it's probable that a significant reversal won't be needed later. In practice, that means:
- Year one of a new pricing model: lean conservative. Recognize committed minimums and actuals with confidence; treat anything projected beyond invoiced/actual usage with real skepticism, since you have no comparable contracts to benchmark against.
- As usage history accumulates: your constraint can loosen, because you now have a defensible basis (this customer's usage has varied between X and Y for six straight months) for a tighter estimate.
- At every close: re-estimate. Variable consideration isn't a "set it and forget it" number — it's revisited each reporting period as new information arrives, with the cumulative catch-up adjustment flowing through the current period.
For a finance team managing this across hundreds or thousands of contracts, the operational fix is aligning your billing system and your revenue recognition ledger before close, not after — so usage data reconciles automatically instead of requiring a manual audit trail every month-end.
Why This Matters Even If You're Small
If you're a two-person AI tools startup billing a handful of customers by the token, it's tempting to treat all of this as "the kind of thing we'll deal with when we raise a Series A." That's a real risk. Revenue recognition errors are one of the most common findings in SaaS fundraising diligence, and usage-based pricing multiplies the number of judgment calls an auditor will want to see documented: which contracts use the invoicing expedient, which breakage rate you assumed and why, how you handled the quarter a customer's usage spiked.
Getting the mechanics right from day one — even at small scale — means you're not reconstructing eighteen months of revenue history under deadline pressure later. It also means the numbers you're using internally to make pricing and hiring decisions are actually accurate, rather than inflated by unrecognized deferred revenue sitting where it shouldn't be.
Keep Your Books as Clear as Your Pricing Model
Usage-based and token pricing is genuinely more complex to account for than a flat monthly subscription, but the complexity is auditable — it just requires documenting your contract structure, your constraint rationale, and your breakage assumptions as you go, not retrofitting them later. Beancount.io's plain-text accounting makes that documentation trail explicit: every revenue recognition entry, deferred revenue balance, and breakage adjustment lives in version-controlled text you (or your auditor) can trace line by line, rather than buried in a black-box billing platform. Get started for free and keep your ledger as transparent as the pricing model you're building on top of it.