Usage-Based Revenue Recognition (ASC 606): Complete Guide

A customer uses $12,000 worth of your platform in March. You invoice them in April and receive payment in May. Which month should your finance team recognize the revenue: March, April, or May?

For controllers and revenue accountants at SaaS and AI companies, this is where usage-based revenue recognition gets complicated. The answer can change when a contract includes prepaid credits, minimum commitments, tiered pricing, or token-based consumption. A billing report can show what you invoiced, a usage dashboard can show what the customer consumed, and your general ledger can tell a different story.

Under ASC 606 and IFRS 15, revenue recognition depends on the performance obligations, contractual terms, and applicable accounting guidance, not simply on when an invoice is sent or payment arrives. A $100,000 annual commitment, for example, does not automatically mean $100,000 of revenue can be recognized upfront.

This guide explains how to recognize usage-based revenue, account for credits and minimum commitments, handle true-ups, and build an audit trail that connects each recognized amount to the underlying usage and contract.

What is usage-based revenue recognition?

Usage-based revenue recognition means recognizing revenue as a company delivers services, based on its contract and the applicable accounting rules. Revenue can be recognized before an invoice is issued or payment is collected if the service has been delivered and the recognition criteria are met.

Consider a customer who consumes $12,000 of API services in March, receives an invoice in April, and pays in May. If the fee qualifies for recognition in March, the revenue belongs in March, not April or May.

For the March example, the answer is potentially $12,000 in March, assuming the usage fee qualifies for recognition in that period, no retroactive pricing adjustment changes the amount, and the variable-consideration constraint does not prevent recognition.

*Assumes the fee qualifies for allocation to March's service under ASC 606-10-32-40 and is not subject to a constraint or retroactive pricing adjustment. An unbilled receivable may be appropriate when only the passage of time is needed before payment is due. If the right to payment remains conditional on something other than time, a contract asset may be appropriate.

Controllers should reconcile usage, billing, cash, and revenue, and be able to explain why the figures differ.

This is a common challenge in consumption-based models. In Usage-Based Billing: How SaaS Companies Price by Consumption, Zenskar explores how different pricing models measure customer usage. The accounting question is what comes next: how that usage translates into revenue for the period.

How does ASC 606 apply to usage-based revenue recognition?

ASC 606 requires companies to recognize revenue as they satisfy their performance obligations. For usage-based contracts, the accounting depends on what the company promised, how the price is determined, and when the customer receives the service.

A Controller reviewing a contract should focus on five questions:

1. What did we promise? Check platform access, metered services, minimum commitments, and amendments.
2. What is the customer paying for? Determine whether the arrangement contains one performance obligation or multiple distinct promises.
3. How is the price calculated? Identify fixed fees, variable usage charges, and volume discounts.
4. Does the usage fee need to be estimated? Assess whether the variable-consideration allocation exception applies.
5. When is revenue earned? Recognize revenue as the relevant obligation is satisfied, rather than automatically when an invoice is issued.

Do companies have to estimate all future usage upfront?

Not necessarily. Under ASC 606-10-32-40, qualifying variable fees can be allocated to a specific period or distinct service within a series when the criteria are met. This can allow routine consumption fees to be recognized as usage occurs, without estimating all future usage at contract inception.

That is separate from the variable-consideration constraint in ASC 606-10-32-11, which limits amounts included in the transaction price when a significant revenue reversal may occur. The right-to-invoice practical expedient under ASC 606-10-55-18 is another separate test. It may apply when the invoiced amount directly corresponds to the value transferred to the customer to date.

One important boundary: the usage-based royalty exception applies to qualifying royalties from licences of intellectual property, not simply to ordinary SaaS access.

How should finance teams account for variable consideration and tiered pricing?

Usage-based fees can change with consumption, discounts, or contract terms. Finance must determine whether the fee can be allocated to the period of usage or whether an estimate and constraint are needed under ASC 606.

Consider a SaaS customer charged $0.10 per API call for the first 100,000 calls and $0.07 thereafter. The accounting depends on whether the lower rate applies only to additional calls or retroactively reprices all calls once the customer crosses the threshold.

Controllers should check four things:

1. How the tier works: Confirm whether the discount applies prospectively or retroactively. The distinction can change the transaction price.
2. Whether an estimate is required: Qualifying usage fees may be allocated to the related service period under ASC 606-10-32-40. Other variable amounts may need to be estimated and constrained under ASC 606-10-32-11.
3. When the price becomes final: Recalculate charges when actual usage confirms the applicable tier. If this changes previously recognized revenue, assess the appropriate adjustment.
4. What evidence supports the calculation: Retain the contract rate card, metered usage, pricing logic, and any approved adjustment.

This is where billing accuracy and revenue accuracy meet, but they are not the same thing. For additional technical context, Deloitte’s guidance on allocating variable consideration explains why usage fees do not all receive the same treatment.

How should prepaid credits, minimum commitments, and overages be recognized?

Prepaid balances, minimum commitments, and overages can create differences between what a customer pays, consumes, and owes. The accounting depends on the contractual promise and the service delivered, not simply on the amount collected or committed.

A Controller should distinguish four common scenarios:

A $100,000 prepayment for API credits does not automatically create $100,000 of revenue. Amounts received for services not yet delivered may remain a contract liability. Rollover or non-expiring credits may create a material right that needs separate assessment. Under ASC 606-10-55-46 to 55-49, expected breakage may be recognized proportionately to rights exercised when the criteria are met, or when the likelihood of redemption becomes remote.

A minimum-commitment shortfall should not automatically be treated as upfront revenue or deferred revenue. Assess what the customer is required to pay for and what the company has promised to provide. For more detail, see Deferred Revenue: A Guide to Accounting and Recognition, Overage Revenue Recognition, and Entitlement Management.

The practical lesson is to keep credit balances, usage events, contract terms, and revenue schedules traceable to one another. That makes it easier to explain why a customer’s remaining balance differs from the revenue recognized to date.

How should finance teams handle true-ups and mid-cycle contract changes?

True-ups adjust revenue or billing when final usage differs from an earlier estimate or when contract terms change. The key is to identify what changed, which period it affects, and whether the adjustment changes the transaction price or the accounting for the performance obligation.

Before closing the month, controllers should check four areas:

• Estimated versus actual usage: Compare preliminary metering data with finalized usage records and investigate material differences.
• Retroactive pricing adjustments: Check whether a volume threshold, discount, or amended rate changes charges for usage already delivered.
• Credits and corrections: Confirm that service credits, usage corrections, and billing disputes are approved and reflected in the appropriate period.
• Contract amendments: Assess whether an upgrade, downgrade, or additional commitment is a contract modification and apply the relevant ASC 606 guidance.

For example, if March usage was initially estimated at $12,000 but finalized at $13,500 in April, finance should assess the reason for the difference and record the adjustment under the applicable accounting policy. It should not simply post the difference in April because that is when the final usage report arrived.

Maintain a clear trail from the original estimate to the final usage data, contract terms, adjustment calculation, approval, and journal entry. This makes it easier to explain changes during close and support them during an audit.

How do Snowflake and Twilio recognize usage-based revenue?

Their annual reports show how consumption-based models can differ from fixed subscriptions. Snowflake generally recognizes revenue as customers consume compute, storage, and data-transfer resources; capacity arrangements may be billed in advance, while on-demand usage is typically billed monthly in arrears. Twilio says its usage-based fees are recognized in the period usage occurs, while subscription fees are generally recognized over the contract term.

How does usage-based revenue recognition work for AI and token-based pricing?

AI companies may charge customers based on tokens processed, API calls, or other units of consumption. The same principle applies: recognize revenue based on the service delivered and the applicable contract terms.

For example, if a customer prepays for $50,000 of AI usage, finance needs to track token consumption against the contract and assess how unused credits should be treated. If the company also resells third-party model services, it must separately evaluate whether it acts as principal or agent when determining how to present revenue.

For pricing context, see Zenskar’s guide to token-based pricing.

How can finance teams automate usage-based revenue recognition?

An effective automation workflow should support the accounting treatment of usage-based contracts, not just automate billing. Finance teams should check whether the system can:

• Map products to performance obligations so revenue treatment reflects the promises in the contract.
• Calculate revenue schedules from usage data based on actual customer consumption.
• Support usage-based revenue distribution for products whose revenue depends on measured usage.
• Support entitlement-based revenue distribution where revenue treatment depends on customer entitlements.
• Generate earned and deferred revenue journal entries automatically from the relevant data.
• Push journal entries to the ERP to connect revenue calculations with the general ledger.
• Trace journal entries back to usage, invoices, and payments to support reconciliation, period-end cutoff, and audit review.

Before Zenskar, Yembo recognized overage revenue using the previous month’s usage. This meant revenue could be recognized later than the period in which the underlying usage occurred, creating a cutoff challenge.

After implementing Zenskar, Yembo began recognizing revenue from actual usage data, with journal entries generated automatically from usage, invoices, and payments. The workflow helped connect customer consumption to revenue recognition and reduced the manual effort involved in billing and revenue recognition.

Result: Yembo saved 90% of the time spent on billing and revenue recognition.

Conclusion: How can finance teams make usage-based revenue recognition reliable?

Usage-based revenue recognition works when finance can explain why revenue was recognized in a particular period, how the amount was calculated, and which contract and usage records support it. Clear cutoff rules, accurate pricing logic, and documented true-ups make that process more consistent and auditable.

Want to connect usage, billing, and revenue recognition in one workflow? Book a demo with Zenskar.

‍