TL;DR: ASC 606 is the same five-step model for everyone, but usage-based and AI pricing put almost all of the weight on two steps that legacy SaaS barely touched: estimating the transaction price (Step 3) and recognizing revenue as the customer consumes it (Step 5). Pure pay-as-you-go is often simpler than people fear, because of the as-invoiced practical expedient. Prepaid credits, minimum commitments, overages, and declining-rate tiers are where it gets hard. This guide walks the five steps, then bends each one around metered revenue, credits, and agents as buyers. For the plain definition of the standard, start with our ASC 606 glossary article.

If you search for ASC 606, lots of the articles were written for a world where a contract sits still. You sign a customer to 12 months of seats, you recognize 1/12th a month, you go home. And while that world still exists, it's not really where most AI and usage-based companies live in today.

Why? Well, when your revenue is metered (tokens, API calls, compute minutes, agent runs, documents generated), the number you'll invoice this month doesn't exist yet at contract signing. ASC 606 still has an opinion about how you book it, but get the opinion wrong and you find out at month-close, three months too late, when your auditor asks why deferred revenue doesn't tie to consumption.

Snowflake, Twilio, OpenAI, and every credit-based AI company live inside this exact question, so this is a long version that explains it. For the one-paragraph definition and the table, the glossary article is the place to start. This guide assumes you already know what ASC 606 is and want to know what it does to your pricing model.

(Standard disclaimer, because it matters: this is not accounting advice. Talk to your auditor before you book anything. I run growth at a billing company, I'm not your controller.)

What does ASC 606 require from you?

ASC 606 requires you to recognize revenue when you transfer a promised good or service to a customer, in the amount you expect to receive in exchange - when control of the thing transfers, not when cash arrives.

It does this through one five-step model that applies to every industry and every contract. FASB issued it in 2014, it became effective for public companies in fiscal years after December 15, 2017, and it replaced more than 100 pieces of industry-specific guidance (ASC 605, SOP 97-2, and the rest). IFRS 15 is the international twin from the same joint project. The five steps are identical across both. For the full history and the legacy-GAAP comparison, see the glossary article and the revenue recognition principle entry.

The concept that matters most for modern software is the performance obligation. Revenue recognizes when a performance obligation is satisfied. For a SaaS subscription that's continuous. For metered usage it's a series of tiny satisfactions, one per unit consumed. That distinction is the whole guide.

What is the five-step revenue recognition model?

The five steps run in order. Every revenue arrangement gets evaluated against all five, every time.

1. Identify the contract with a customer.

2. Identify the performance obligations in the contract.

3. Determine the transaction price.

4. Allocate the transaction price to the performance obligations.

5. Recognize revenue when (or as) each obligation is satisfied.

   
   

For the textbook walkthrough of each step with a vanilla SaaS example, the glossary article has it. Below I'm doing the version where the contract won't hold still.

Where the five steps bend for usage-based and AI pricing

Same model, different center of gravity. For a classic annual-seat deal, Steps 1, 2, and 4 do most of the work and Step 5 is a straight line. For usage-based and hybrid pricing, Steps 1 and 2 get easier and Steps 3 and 5 get genuinely hard. Here's each one.

Step 1: Identify the contract (when nobody signs anything)

Legacy SaaS had a signed order form. A lot of AI-native companies have a clickwrap "I agree" and a credit card on file. That's still a contract under ASC 606. The standard accepts approval "in writing, orally, or through customary business practice".

That means that a self-serve developer who runs npm install, pastes an API key, and starts burning tokens has a contract the moment usage begins and collection is probable.

We've identified two potential issues here:

1. Collection probable (~75-80% likely under US GAAP, the lower "more likely than not" bar under IFRS 15) is a real test for self-serve, where you're extending micro-credit to strangers.

2. AI Agents: When an autonomous agent provisions itself and spends against a budget, the "approval" and the "customary business practice" still anchor to a human or an entity behind the agent. The contract exists. The buyer just isn't sitting at the keyboard.

Step 2: Identify performance obligations (the series trick)

For a metered product, the performance obligation usually isn't "10 million API calls." It's the standing promise to serve calls on demand for the contract period. ASC 606 has specific guidance for this, the series provision (ASC 606-10-25-14/15): a series of distinct goods or services that are substantially the same and have the same pattern of transfer counts as a single performance obligation.

That's why most usage-based SaaS lands on one performance obligation (access plus consumption) rather than thousands. It also tells you where multi-element gets real: implementation, premium support, a one-time model fine-tune, an SLA that transfers something separate.

Each of those is its own "distinctness" test. For example, if you bundle a fine-tuned model that the customer keeps with a metered inference API, you may have two obligations recognizing on two different clocks.

Step 3: Determine the transaction price (this is now the whole game)

For a fixed annual contract, the transaction price is the number on the order form. For usage-based revenue, the transaction price is mostly variable consideration, and you have to estimate it. This is the step that breaks people.

ASC 606 gives you two estimation methods: expected value (probability-weighted, good for a large population of similar contracts) and most likely amount (good for binary outcomes like a single performance bonus). Then it makes you apply the constraint: you only include variable consideration to the extent it's highly probable a significant reversal won't happen later. Aggressive usage forecasts get clipped by the constraint.

Now the part that saves usage-based companies a lot of pain. The as-invoiced practical expedient (ASC 606-10-55-18). If the amount you have the right to invoice corresponds directly to the value transferred to the customer (you bill a fixed rate per unit consumed, you bill in arrears), you can recognize revenue in the amount you have the right to invoice. No upfront estimation of the whole year's usage. You recognize what you metered, as you meter it. Pure pay-as-you-go at a flat per-unit rate is, honestly, one of the cleaner things to account for under ASC 606.

If an entity has a right to consideration from a customer in an amount that corresponds directly with the value to the customer of the entity's performance completed to date (for example, a service contract in which an entity bills a fixed amount for each hour of service provided), the entity may recognize revenue in the amount to which the entity has a right to invoice.
(Paragraph 606-10-55-18 [B16])

The expedient stops being available the moment your rate stops corresponding directly to value. Declining-rate tiers (cheaper per token after 100M tokens), retroactive volume discounts, prepaid credits at a discount, minimum commitments with overage, a free tier that subsidizes later usage. All of those break the direct correspondence, and you're back to estimating and allocating. This is the fork in the road for AI pricing, and almost every AI company is on the hard side of it.

Step 4: Allocate the transaction price (credits and standalone selling price)

With a single usage performance obligation and as-invoiced recognition, allocation is trivial. With prepaid credits, bundles, and discounts, it's not.

Two things to watch out for:

1. Standalone selling prices for usage components are often not directly observable (what's the SSP of a token?), so you estimate them, usually expected-cost-plus-margin or adjusted market assessment.

2. Material rights: if you sell credits at a discount, or a bonus credit pack, or a tier that grants below-market future pricing, that discount on future purchases can be a separate performance obligation. You allocate some of today's payment to the future right and recognize it when the customer uses it (or lets it expire).

Step 5: Recognize revenue (as consumed, not on a schedule)

For usage, recognition is over time, and the measure of progress is consumption. The customer simultaneously receives and consumes the benefit of each API call, so you recognize as the calls land. Not straight-line. Not 1/12th a month. As-metered.

This is the line item that doesn't reconcile if your metering and your ledger are two different systems.

If your usage data says 8.3 million calls in March, so your revenue schedule needs to recognize exactly that, draw down exactly that much deferred revenue, and survive an auditor pulling the underlying event log. If those numbers are stitched together in a spreadsheet after month-end, that's a revenue assurance failure, and the recognition error rides along with it. (More on that in revenue assurance.)

Variable consideration is the part that actually breaks

Step back. In legacy SaaS, variable consideration was a footnote: the occasional rebate or performance bonus. In AI and usage-based businesses, variable consideration is the revenue. The whole top line is an estimate that resolves over the period.

That changes what your finance team does every month. They're not posting a flat schedule. They're truing up estimates against actuals, applying constraints, and re-checking whether the as-invoiced expedient still holds for each contract shape. One AI company's top 5% of users can burn 75% of the compute. If they're all on the same flat plan and your forecast assumed an even distribution, the constraint and the true-up are going to move real money. The CFO who finds that out at quarter-close is the CFO who emails me.

The honest summary: usage-based revenue isn't harder to recognize than subscription revenue. It's harder to trust, because the inputs are high-volume event data instead of a number typed on a contract. The accounting is downstream of whether your metering is clean.

Credits and prepaid wallets under ASC 606

Prepaid credits are the dominant AI pricing primitive right now, and they're a specific ASC 606 pattern worth its own section. (Hybrid pricing is the default now, and credits are usually how the prepaid part works.)

When a customer prepays for a pool of credits, you've received cash for a performance obligation you haven't satisfied. That's deferred revenue, a contract liability. You recognize revenue as credits are consumed against actual usage, drawing the liability down. Three things make it interesting:

• Breakage: Customers buy 1,000 credits and use 850. The other 150 expire. ASC 606 (606-10-55-46 to 55-48) says if you expect breakage, you recognize it in proportion to the pattern of rights actually exercised, rather than waiting for expiry. If you don't expect breakage, you wait until the likelihood of exercise is remote. Either way you need historical redemption data to support the estimate.

• Discounted credits as a material right: Sell $1,000 of credits for $900 and that $100 discount may be a separate performance obligation allocated and recognized over the redemption pattern.

• Credits that don't expire and roll over: These extend the liability and complicate the consumption pattern. The wallet is a ledger, and the ledger is the source of truth for recognition.

A real example: an AI company with credits and overage

Numbers make this concrete. An AI agent company signs an annual deal. The customer commits to $120,000 for the year, prepaid, which buys a pool of platform credits. Usage above the committed pool bills in arrears at $0.04 per 1,000 agent actions. There's also a one-time onboarding and data-migration fee of $15,000.

Step 1. The signed order plus the clickwrap terms is the contract. Collection is probable (enterprise customer, prepaid).

Step 2. Two candidates: the platform (access plus metered agent actions, a single series performance obligation) and onboarding. Onboarding here transfers a distinct service the customer couldn't get elsewhere mid-contract, so call it a second performance obligation. (If onboarding were just setup that transfers nothing separately, you'd roll it into the platform obligation)

Step 3. Fixed: $120,000 commit + $15,000 onboarding. Variable: the overage, estimated by expected value across the customer cohort, then constrained to what's highly probable not to reverse. Say you estimate $18,000 of overage and the constraint clips your booked estimate to $12,000.

Step 4. Allocate $15,000 to onboarding (its SSP) and the rest across the platform obligation by SSP. Overage attaches to the platform obligation as it resolves.

Step 5. Onboarding recognizes when delivered (point in time, or over the migration weeks if it transfers over time). The $120,000 commit recognizes as credits are consumed against actual agent actions, drawing down deferred revenue month by month. The overage recognizes as it's metered, trued-up against your $12,000 constrained estimate as the year plays out.

At signing you collected $135,000 in cash and recognized almost none of it as revenue. The commit sits in deferred revenue and bleeds into the P&L as the agents actually run. If usage runs hot, your constrained overage estimate releases. If it runs cold, you've got unused credits and a breakage question at year-end.

That's four recognition patterns in one contract. A spreadsheet can do it once. It cannot do it for 400 customers, every month, audit-ready. Which is the actual point of this guide.

Why this breaks billing v1 like Stripe Billing

Here's what happens in practice. Billing v1 is often Stripe plus orchestration code plus a metering pipeline someone built outside. It invoices fine. It does not produce ASC 606 revenue, because invoicing and recognition are different jobs and v1 only does the first one.

So the revenue schedule gets rebuilt every month in a spreadsheet. Someone exports usage, exports invoices, exports the credit balances, and reconciles the three by hand. So when the auditor asks for the support behind a recognized number and the answer is "let me rebuild it" (I've seen this first-hand, and watched a lot of finance teams live exactly here for months too long.)

The failure isn't the pricing itself because credits and usage and hybrid commits are good pricing. The failure stems from treating revenue recognition as a reporting step downstream of billing instead of a property of the same ledger that meters and invoices. When metering, invoicing, and recognition run on three systems, reconciliation is the job, forever.

Over time or point in time? A decision for usage revenue

Most usage and SaaS revenue is over-time, but the test still has to be run, and a few AI arrangements land on point-in-time. The criteria: recognize over time if the customer simultaneously receives and consumes the benefit, or you create an asset the customer controls as you build it, or you create an asset with no alternative use plus an enforceable right to payment for work done. Everything else is point in time.

A term-based license that grants the right to use IP as it exists at the transfer date recognizes at a point in time, on activation. A one-off fine-tuned model the customer owns outright can recognize on delivery. A metered inference API recognizes over time, as consumed. Same company can have all three on one invoice.

ASC 606 and your SaaS metrics

One trap worth naming: ASC 606 governs GAAP revenue. ARR and MRR are operational metrics you define yourself, and for usage-based businesses they routinely diverge from recognized revenue. A customer can have $0 of "committed ARR" and a large recognized-revenue month if they're a heavy on-demand user. Or a big prepaid commit (high deferred revenue, future GAAP revenue) and a quiet usage month. Report both, reconcile between them, and don't let a board deck imply they're the same number. Your auditor cares about the GAAP line. Your investors usually quote the operating metric.

How Solvimon handles ASC 606 for usage and credits

Short version, because this is a guide and not a pitch. Solvimon runs metering, invoicing, and revenue recognition on one ledger, so the three numbers that have to tie actually come from the same place.

Concretely: every billable event (token, call, agent action) is metered and posted once. Prepaid credits live as a wallet liability that draws down against that same event stream, so deferred revenue is a real balance, not a reconstructed tab. Variable consideration estimation methods (expected value or most likely amount) and the constraint are configured per contract. The as-invoiced expedient is applied where the rate corresponds to value, and full estimate-and-allocate kicks in where it doesn't. Recognition schedules post at contract inception and resolve as obligations are satisfied, with the underlying event log sitting right behind the recognized number when the auditor asks. It produces ASC 606 and IFRS 15 treatment from the same source of truth, and it covers the quote-to-cash path end to end. That's the automated invoicing primitive doing recognition as a property of the ledger, not a monthly export.

We're built by the team that ran billing at €1T+ volume at Adyen. The recognition-as-ledger idea isn't new there. It's just rarely available to companies your size.

Frequently asked questions

Does usage-based revenue have to be estimated up front under ASC 606?

Often no. If you bill a fixed rate per unit in arrears and that rate corresponds directly to the value transferred, the as-invoiced practical expedient (ASC 606-10-55-18) lets you recognize revenue equal to what you have the right to invoice. You only estimate the full transaction price up front when the rate stops matching value, e.g. declining tiers, prepaid discounts, minimum commitments, or retroactive volume rebates.

How do you recognize revenue on prepaid credits?

Prepaid credits are deferred revenue (a contract liability) when sold. You recognize revenue as credits are consumed against actual usage, drawing the liability down. If you expect breakage (unused credits), you recognize it in proportion to the pattern of credits actually redeemed rather than waiting for expiry, provided you have redemption history to support the estimate.

Is usage-based revenue recognized over time or at a point in time?

Over time, in almost all cases. The customer simultaneously receives and consumes the benefit of each metered unit, so you recognize as consumption happens, not on a straight-line schedule. Exceptions are things like a one-time fine-tuned model handed to the customer or a term-license activation, which can be point in time.

What is variable consideration in ASC 606?

Variable consideration is any part of the transaction price that isn't fixed: usage fees, overages, rebates, refunds, performance bonuses. You estimate it using expected value or most likely amount, then apply the constraint, which limits the estimate to the amount it's highly probable won't reverse later. For usage-based businesses, variable consideration is most of the revenue.

How is ASC 606 different from IFRS 15 for usage-based pricing?

The five-step model is identical and the usage treatment is nearly the same. The differences are at the edges: the collectibility threshold (~75-80% "probable" under US GAAP vs "more likely than not" under IFRS 15), disclosure depth, and a few policy elections. For most AI and SaaS companies the recognized revenue is the same under both. See the IFRS 15 glossary entry.

Do agents as buyers change anything under ASC 606?

Not the accounting itself. A contract still requires approval and identifiable rights, which trace back to the human or entity behind the agent. What changes is operational: agent-driven, machine-speed, high-frequency consumption makes clean metering and a single recognition ledger non-optional. The standard didn't move. The volume did.

Why doesn't my deferred revenue tie to consumption?

Usually because metering, invoicing, and recognition run on separate systems and get reconciled by hand after month-end. The fix is structural: recognition has to draw from the same event ledger that meters and invoices, so the deferred revenue balance is a real-time consequence of consumption rather than a monthly reconstruction. This is a revenue assurance problem as much as a recognition one.

Does ASC 606 apply to early-stage and private companies?

Yes. ASC 606 applies to any entity reporting under US GAAP, public or private. Private companies got an extra year to adopt (fiscal years after December 15, 2018). If you're being audited under US GAAP, or you will be at your next raise, the standard applies to you now.

Related reading

• ASC 606 (glossary), the definition, the legacy-GAAP comparison, the full standard

• Revenue recognition principle

• IFRS 15

• Deferred revenue

• Revenue assurance

• Quote-to-cash

• Usage-based pricing and hybrid pricing models

• Credit pricing

• Hybrid pricing is the default now