Revenue recognition for usage-based billing: how to do it under ASC 606

Under ASC 606, revenue from usage-based billing is generally recognized in the period the customer uses the service, at the contracted rate. Usage fees are variable consideration, but for most SaaS and AI products you do not need to estimate them upfront. The variable consideration allocation exception, or the right-to-invoice practical expedient, lets you recognize each period's usage in that period. Minimum commitments, prepaid credits, and retroactive tiered pricing are where the treatment gets harder.

The accounting is rarely the bottleneck. The data is. Usage lives in a metering system, rating lives in billing, and revenue lives in the ERP, and each can close on a different day. This guide covers the ASC 606 treatment for each common usage model, with journal entries, and the step-flow that gets metered usage to a recognized entry without a spreadsheet in the middle.

Key takeaways

• Usage-based fees are variable consideration under ASC 606, but most can be allocated to the period in which usage occurs, so no upfront estimate is needed.

• Two tools do most of the work: the allocation exception for series of distinct services (ASC 606-10-32-39 to 32-40) and the right-to-invoice practical expedient (ASC 606-10-55-18).

• Minimum commitments split into a fixed and a variable piece; the committed amount is recognized as the service is provided, and overage is recognized as it is used.

• Prepaid credits are a contract liability, and expected unused credits (breakage) are recognized in proportion to the customer's usage, subject to the constraint.

• Usage delivered but not yet invoiced at month-end is revenue now, recorded against an unbilled receivable.

• Loopfour, the deterministic finance workflow automation platform, moves usage from meter to rated amount to invoice to revenue entry with the same rules every close, and holds the run when the totals don't tie.

How do you recognize revenue for usage-based billing?

You recognize usage-based revenue when the usage occurs, as long as the usage fee relates specifically to that period's service and reflects the value delivered. Most usage-based SaaS and AI products provide a service that is a series of distinct periods, such as days or months of platform access. ASC 606 then lets you allocate each usage fee to the period that generated it.

Two routes lead to the same answer for plain usage pricing:

• Variable consideration allocation exception. ASC 606-10-32-40 lets you allocate variable consideration entirely to a distinct service period when the variable terms relate specifically to your efforts in that period and the result is consistent with the allocation objective.

• Right-to-invoice practical expedient. ASC 606-10-55-18 lets you recognize revenue in the amount you have a right to invoice when that amount corresponds directly with the value delivered to date, such as a fixed rate per API call.

Neither route applies automatically. PwC's guidance notes that upfront payments, back-end rebates, or pricing that does not track value can prevent the right-to-invoice expedient. Document which route you use and why. For the underlying rules on estimates and the constraint, see our guide to variable consideration under ASC 606.

The usage-to-revenue step-flow

Usage-based revenue recognition is a data pipeline before it is an accounting entry. Each stage has an owner, a system, and a control, and a break at any stage shows up as a revenue error at close.

→ Usage event. The product emits an event: an API call, tokens processed, a seat-day, a gigabyte stored.

→ Metered. Events are aggregated per customer and period. Duplicates, late events, and test traffic are filtered.

→ Rated. The aggregate is priced against the customer's contract: rate card, tiers, minimums, credits, and discounts.

→ Invoiced. Billing issues the invoice, often in arrears, days after period-end.

→ Recognized. Revenue is recorded in the period of usage, not the period of invoicing.

→ Reconciled. Metered usage, rated amounts, invoices, and revenue are tied out before close.

The rated amount, not the invoice, drives revenue. If usage is billed on the fifth of the following month, the revenue still belongs to the month the usage happened. That means your close depends on rated usage being available before the invoice exists. Stripe's own documentation notes that its basic Billing Meters reconcile usage at invoice time, and it points newer integrations to Metronome, now part of Stripe, for real-time usage visibility.

How ASC 606 treats each usage pricing model

The pricing model determines whether you need an estimate, a split, or nothing extra. The table summarizes the usual treatment for each common model.

Minimum commitment with overage: worked example

An AI API company sells a monthly plan with a $20,000 minimum that covers up to 10 million API calls, plus $0.0025 per call above that. Usage is invoiced in arrears on the fifth of the following month. In March, the customer makes 12 million calls.

• Committed fee: $20,000.

• Overage: two million calls × $0.0025 = $5,000.

• March revenue: $25,000, recognized in March even though the invoice goes out in April.

If March usage had been eight million calls, revenue would still be $20,000, because the customer paid for a stand-ready monthly service with an included allowance, not only for calls made. The unbilled amount is a receivable rather than a contract asset because only the passage of time stands between you and payment.

Annual minimums are harder. If the commitment is $240,000 a year and usage is lumpy, you need a documented policy for recognizing the committed amount, usually ratably across the service period, and a clear rule for when overage begins to count.

Prepaid credits with breakage: worked example

A customer prepays $120,000 for usage credits that expire unused after 12 months. Based on a large, stable history, you expect the customer to use $108,000 and let $12,000 expire. ASC 606-10-55-48 says that when you expect to be entitled to breakage, you recognize it in proportion to the pattern of rights the customer exercises.

In the first month, the customer consumes $9,000 of credits, which is one-twelfth of expected usage ($9,000 ÷ $108,000). Revenue for the month is $120,000 × ($9,000 ÷ $108,000) = $10,000: $9,000 of consumed credits and $1,000 of breakage.

The breakage estimate is variable consideration, so the constraint applies. If your history is thin, recognize breakage only when the likelihood of the customer using the remaining credits becomes remote. If unclaimed property laws require you to remit unused balances to a government, you do not recognize that portion as breakage at all.

Where usage-based revenue breaks at close

Usage-based revenue breaks when the three numbers that should agree (metered usage, rated amount, and recognized revenue) are produced by three systems on three schedules. None of the failures below is an accounting error at first. Each becomes one at close.

• Late or duplicated events change the metered total after the invoice is issued.

• Rate cards drift: sales negotiates a custom rate in the CRM, and billing still rates at list.

• Credits are applied in billing but not in the revenue schedule, so revenue overstates by the credit.

• Month-end accruals are estimated by hand because rated usage arrives after the books close.

• Payouts don't tie, because the payment processor nets fees and refunds against usage invoices. Our guide to reconciling Stripe with NetSuite covers that last mile.

The reporting side feels it too. Usage revenue does not fit neatly into ARR, and the committed portion is what belongs in remaining performance obligations. See contracted ARR, live ARR, and RPO for how to keep those metrics tied to contracts.

Book a workflow review to see where your usage data stops matching your revenue today.

How to choose a process for usage-based revenue

Choose a process in which the same usage data always produces the same rated amount and the same entry, and any mismatch stops the run. That is harder than it sounds when usage volume grows faster than the finance team.

Billing platforms rate usage well, and some offer revenue modules. They still depend on contract terms arriving correctly from the CRM and on usage arriving on time. Horizontal automation platforms can glue the systems together and are flexible, but your team owns the logic, the edge cases, and the maintenance. An AI agent that estimates missing usage at runtime creates a number nobody can re-perform.

A generic script copies usage totals into a journal entry. Loopfour reconciles them first. The workflow pulls metered totals, rates them against the approved contract terms, compares the result to billing, and posts the revenue entry only when the three agree. Differences above your threshold go to a named approver in Slack. The Contract Agent is used for one scoped task, reading rate cards and commitments from signed order forms under a confidence threshold, and every run lands in an execution tree. For an AI company whose revenue outruns its finance headcount, that is the difference between revenue built on reconciled numbers and revenue built on a late estimate.

Frequently asked questions

Is usage-based revenue variable consideration? Yes. Usage-based fees are variable consideration under ASC 606 because the amount depends on future customer usage. For most SaaS and AI services, you can allocate each period's usage fee to that period, so you do not need to estimate total usage upfront.

Can I use the right-to-invoice practical expedient for usage billing? Often, yes. ASC 606-10-55-18 allows you to recognize revenue in the amount you have a right to invoice when that amount corresponds directly to the value delivered, such as a fixed price per API call. Upfront fees, back-end rebates, or rates that do not track value can prevent its use.

How do you recognize revenue for prepaid usage credits? Prepaid credits are recorded as a contract liability and recognized as the customer consumes them. If you expect some credits to expire unused and have reliable evidence, you recognize that breakage in proportion to usage, subject to the variable consideration constraint.

How do you handle usage that is billed after month-end? Recognize the revenue in the month the usage occurred, with an unbilled receivable, and reclassify it to accounts receivable when the invoice is issued. This requires rated usage to be available before close, even if the invoice goes out later.

How do minimum commitments affect usage revenue recognition? A minimum commitment is fixed consideration for a stand-ready service, recognized as the service is provided, usually ratably. Usage above the minimum is variable consideration recognized as it occurs. Annual minimums with uneven usage need a documented policy.

Conclusion

Usage-based billing revenue recognition under ASC 606 is simpler in principle than it looks: most usage is recognized in the period it happens. The hard part is proving the usage, the rate, and the entry agree, every month, before close. Build the pipeline from event to entry, reconcile at each stage, and let only the exceptions reach a person.

Tell us the one workflow your team dreads. We will show it running: deterministic, permissioned, and auditable.

Book a demo.

Sources

• PwC Viewpoint, Revenue guide 6.4, Measures of progress and the right-to-invoice practical expedient

• Stripe Docs, Basic usage-based billing

• FASB, ASU 2014-09, Revenue from Contracts with Customers (Topic 606)

Related reading

• What is ASC 606? The five-step model, explained with SaaS examples

• How to automate ASC 606 revenue recognition without losing the audit trail

• What is deferred revenue? Why it's a liability

• How to automate contract-to-cash, step by step