Revenue Recognition for Usage-Based Billing: An ASC 606 Compliance Guide

Usage-based pricing solves a commercial problem — charging customers closer to the value they receive — but it creates an accounting problem that flat-fee SaaS never had to deal with: the amount you'll ultimately bill isn't known when the contract starts. That single fact is why revenue recognition is consistently the part of usage-based billing that catches finance teams off guard.

This guide walks through how ASC 606 (and its international equivalent, IFRS 15) applies to usage-based and consumption revenue, where the real complexity hides, and how to build a recognition process that survives an audit.

Why usage-based revenue is different

Under a flat-fee subscription, revenue recognition is close to mechanical: recognize the fee ratably over the service period. Usage-based contracts break that simplicity because the transaction price itself is variable — it depends on consumption that hasn't happened yet at the time the contract is signed.

Accounting standards have a specific term for this: variable consideration. ASC 606 and IFRS 15 both require companies to estimate variable consideration and, in many cases, apply constraints so revenue isn't recognized before it's reasonably certain to be earned.

The five-step model, applied to usage-based billing

ASC 606's five-step revenue recognition model still applies to usage-based contracts — but two of the five steps look meaningfully different from a flat-fee arrangement.

ASC 606 / IFRS 15 five-step model applied to usage-based revenue

Step 1 — Identify the contract. Usage-based arrangements often combine a base subscription with usage terms in the same agreement, or reference a separate usage schedule. Both need to be captured as part of the same contract for accounting purposes if they're commercially linked.

Step 2 — Identify performance obligations. A base platform fee and metered usage may represent one combined performance obligation (access to a service, delivered continuously) or be treated separately, depending on how distinct the usage-based component is from the core service.

Step 3 — Determine variable consideration. This is where usage-based contracts diverge most sharply from flat-fee SaaS. Companies must estimate the variable amount using either the expected value method (probability-weighted across possible outcomes) or the most likely amount method, and then apply the variable consideration constraint — only recognizing an estimate to the extent it's probable that a significant reversal won't occur later.

Step 4 — Allocate the transaction price. When a contract includes both fixed and variable components, the variable amount often gets allocated entirely to the performance obligation it relates to (a common practical expedient for usage-based fees tied to a specific period of service), rather than spread proportionally across all obligations.

Step 5 — Recognize revenue as usage occurs. For most usage-based arrangements, the practical outcome is that revenue is recognized as the usage happens and becomes measurable — which is why accurate, timely metering (see our usage metering guide) isn't just an operational nice-to-have, it's an accounting dependency.

Credits, prepaid balances, and breakage

Prepaid credits — common in AI and token-based pricing — add another layer of complexity. When a customer pays upfront for a pool of credits, that payment initially sits on the balance sheet as deferred revenue, not recognized revenue. Revenue is only recognized as credits are actually drawn down against usage.

Two specific situations trip teams up:

• Breakage. When customers don't use their full credit balance before it expires, the unused portion ("breakage") has to be recognized following a specific pattern under ASC 606 — proportionally, in line with the pattern of rights exercised by customers — rather than as a lump sum when the credits expire or when the contract is signed.
• Non-refundable upfront fees. Setup fees or non-refundable minimums bundled into a usage-based contract often need to be recognized over the expected contract term rather than immediately, depending on whether they provide a material right to the customer.

Getting breakage and deferred revenue wrong is one of the more common audit findings in usage-based and consumption-billing companies, precisely because it requires reconciling actual usage draws against a prepaid balance on an ongoing basis — not a one-time calculation.

Where the constraint on variable consideration actually bites

The "constrain estimates" requirement in step 3 exists to prevent companies from recognizing optimistic usage estimates as revenue before they're earned. In practice, this means:

• You generally can't recognize revenue for usage you expect a customer to generate in future periods, even if historical patterns make it likely.
• Highly volatile usage patterns (large batch jobs, seasonal spikes) may require more conservative estimation approaches than steady, predictable consumption.
• Minimum commitments in a usage-based contract are typically recognized as guaranteed revenue regardless of actual usage, since they aren't variable — but usage above the minimum still follows the variable consideration rules.

What this means operationally

Revenue recognition for usage-based billing isn't a quarterly close exercise you can bolt on after the fact — it depends on data flowing correctly, in real time, from the metering layer through to the general ledger:

• Usage data has to be accurate and timely, since revenue recognition is directly tied to measured consumption.
• Deferred revenue balances for prepaid credits need continuous reconciliation, not a one-time calculation at contract signing.
• Breakage patterns need historical usage data to estimate accurately and defensibly for auditors.
• Finance needs visibility into usage trends before period-end, not just after invoices go out, to catch estimation issues before they become restatements.

Why fragmented systems make this harder than it should be

Usage-based revenue recognition requires three data sets to agree: what was metered, what was billed, and what was recognized. When metering lives in one system, billing in another, and revenue recognition calculations happen in a spreadsheet pulling from both, discrepancies aren't a matter of if but when — and they tend to surface during an audit, which is the most expensive possible time to find them.

This is precisely the kind of fragmentation a revenue intelligence platform is built to close. Verlix connects usage, billing, and financial data that would otherwise sit in disconnected systems, giving finance teams a single, auditable view of variable consideration, deferred revenue, and breakage — so revenue recognition becomes a byproduct of accurate operational data, not a separate reconciliation project every close.

FAQ

Is usage-based revenue always considered variable consideration under ASC 606?

Generally yes — any transaction price that depends on future usage, output, or another uncertain factor is treated as variable consideration and subject to the estimation and constraint requirements in step 3 of the model.

How should unused prepaid credits (breakage) be recognized?

Breakage is typically recognized proportionally, following the pattern in which customers exercise their usage rights — not as a lump sum at expiration or at contract signing.

Do minimum usage commitments follow the same variable consideration rules?

No. Minimum commitments are generally treated as fixed consideration since they're guaranteed regardless of actual usage; only consumption above the minimum is subject to variable consideration treatment.

The bottom line

Usage-based billing doesn't just change how you charge customers — it changes how revenue has to be recognized, estimated, and constrained under ASC 606. Companies that treat revenue recognition as a natural extension of accurate metering and billing data close faster and audit cleaner than those trying to reconcile it after the fact.