Usage-Based Revenue Recognition
ASC 606 & IFRS 15, with Worked Examples
Usage-based revenue recognition means recognizing revenue as customers consume — not when you invoice. This guide covers how ASC 606 applies to usage and consumption contracts, variable consideration and the constraint, prepaid-credit journal entries, how public companies do it, and where most teams get it wrong.
Usage-Based Revenue Recognition Definition
Usage-based revenue recognition is the practice of recognizing revenue on consumption- or usage-priced contracts as the customer actually consumes the product, under ASC 606 or IFRS 15. Because the billed amount varies each period, the consideration is variable, and revenue must follow consumption — drawing down prepaid credits or recognizing metered usage in arrears — rather than the billing calendar.
The hard part is never the metering. It is reconciling consumption to the signed contract — minimums, tiers, caps, and credits — and producing recognition schedules that survive an audit.
Also referred to as: consumption-based revenue recognition, metered revenue recognition, usage revenue recognition under ASC 606 / IFRS 15.
Why usage-based rev rec is harder than subscription rev rec
A subscription recognizes evenly over the term. Usage recognizes against a moving target — which breaks the spreadsheet the moment volume changes.
Consideration is variable
Each period bills a different amount, so the transaction price is variable consideration that must be estimated or measured as usage occurs — not a fixed subscription you spread evenly.
The obligation is continuous
A stand-ready or consumption obligation is satisfied over time as the customer uses the service, so revenue has to track actual usage, not the billing calendar.
Billing ≠ recognition
You may invoice monthly in arrears, on prepaid credits, or against a commitment — but recognized revenue must follow consumption, which rarely matches the invoice date or amount.
The five-step ASC 606 model, applied to usage
The standard model is the same — the difference is in steps 3 and 5, where variable consideration and consumption-based timing take over.
Identify the contract
Capture the signed terms — rate card, minimum commitments, prepaid credits, caps, tiers, and term — as the source of truth for recognition.
Identify the performance obligations
Most usage-based SaaS is a single stand-ready / consumption obligation satisfied over time; bundles (platform fee + usage + services) may have several.
Determine the transaction price
For pure pay-as-you-go, price equals usage at the rate card. For commitments, tiers, or retroactive pricing, estimate variable consideration (expected value or most-likely-amount).
Allocate to obligations
Allocate the price across obligations using standalone selling price (SSP). Usage tied to a distinct obligation is generally allocated to that obligation as it is consumed.
Recognize as consumption occurs
Recognize revenue as the customer consumes — drawing down prepaid credits or invoicing in arrears — and true up estimates and minimums at period close.
Variable consideration and the constraint
Usage fees are variable consideration. How you recognize them depends on the contract:
- Pure pay-as-you-go, invoiced in arrears: if the invoice corresponds to the value transferred, use the right-to-invoice practical expedient (ASC 606-10-55-18 / IFRS 15.B16) and recognize the amount you have the right to bill — no separate estimate required.
- Commitments, tiers, or retroactive pricing: estimate the variable consideration using expected value or the most-likely-amount, then apply the constraint — include it only to the extent it is probable a significant revenue reversal will not occur. Re-estimate every period.
Common mistake: the sales- and usage-based royalty exception (ASC 606-10-55-65) — recognize at the later of usage or satisfaction — applies only to licenses of intellectual property. Most usage-based SaaS is a service, not an IP license, so the exception does not apply. Misapplying it is one of the most common usage rev-rec errors auditors catch.
Worked example: prepaid usage credits
A customer prepays for a credit balance and draws it down with usage. Here is the full journal-entry path from cash to recognized revenue.
| Event | Debit | Credit |
|---|---|---|
| Customer prepays $120,000 for 1,200,000 credits (12-month term, $0.10/credit) | Cash $120,000 | Contract liability (deferred revenue) $120,000 |
| Month 1 — customer consumes 150,000 credits ($15,000) | Contract liability $15,000 | Revenue $15,000 |
| Months 2–11 — recognized as credits are drawn down | Contract liability (as used) | Revenue (as used) |
| Term end — 50,000 credits expire unused and non-refundable | Contract liability $5,000 | Breakage revenue $5,000 |
Breakage on the expired credits is recognized in proportion to the pattern of rights the customer exercises if it can be estimated; otherwise it is recognized when the likelihood of the customer using the remaining credits becomes remote (ASC 606-10-55-46 to 55-48). A minimum-commitment-plus-overage contract works similarly: recognize the committed amount as the related usage occurs, and recognize overage above the commitment as incurred.
How public companies recognize usage revenue
Consumption leaders all land in the same place: revenue follows usage, and unconsumed prepayments sit in deferred revenue. Summarized from their public 10-K filings.
Snowflake
Sells consumption-based capacity. Customers buy (often prepaid) capacity commitments and draw down as they consume compute, storage, and data transfer. Revenue is recognized as consumption occurs — not ratably — and unconsumed capacity sits in deferred revenue.
Datadog
Runs committed-use contracts plus on-demand overages. Committed amounts are recognized as the related usage occurs, and on-demand usage above the commitment is recognized as it is incurred at contractual rates.
Twilio
Pure usage-based communications (per message, minute, etc.). Revenue is recognized in the period the usage occurs, based on actual usage measured at contractual per-unit rates.
Billing engine vs. rev-rec engine vs. revenue subledger
A metering engine counts usage. A rev-rec engine recognizes revenue from a clean feed. A revenue subledger reconciles usage to the contract and does both on one ledger.
| Billing engine | Rev-rec engine | LedgerUp subledger | |
|---|---|---|---|
| Meters usage events | Yes | No (consumes a feed) | Reads from your engine |
| Reconciles usage to the signed contract | No | Assumes clean input | Yes |
| Catches unbilled overages / under-billing | Limited | No | Yes |
| ASC 606 / IFRS 15 schedules | Partial or add-on | Yes | Yes |
| Variable consideration & the constraint | No | Yes | Yes |
| Billing + revenue on one reconciled ledger | No | No (separate reconcile) | Yes |
| Where it runs | Standalone app | Standalone + ERP | Slack + your CRM, billing & ERP |
Bottom line: keep your billing engine (Stripe, Orb, Metronome) to meter usage. Add a revenue subledger to reconcile that usage to the contract and recognize it under ASC 606 — so billing, cash, and revenue never drift apart.
How LedgerUp automates usage-based rev rec
LedgerUp's AI agent Ari reconciles consumption to the contract and turns it into audit-ready recognized revenue — on the same ledger that runs your billing.
Usage-to-contract reconciliation
Ari matches metered usage and overages against the signed contract — minimums, tiers, caps, and credits — catching under-billing before it becomes lost revenue.
Automated ASC 606 / IFRS 15 schedules
Recognition schedules are generated directly from consumption, handling variable consideration, the constraint, and prepaid-credit drawdown without monthly journal-entry spreadsheets.
Audit-ready, on one ledger
Billing reconciliation and revenue recognition live on the same subledger, so what you billed, collected, and recognized always agree — with a full audit trail for diligence.
Posts to your ERP
Recognized revenue and deferred-revenue waterfalls sync to NetSuite, QuickBooks, or Sage Intacct — no re-keying, no drift between systems.
“Ari took a job we dreaded and turned it into something we don't even think about anymore. Billing just works now. And we found $72K we didn't know we were leaving on the table.”
- Varez, GTM Lead at HappyRobot
Related Guides
How metered billing works, the five pricing models, and how to reconcile it.
The full five-step model for B2B SaaS across subscription, milestone, and usage contracts.
How LedgerUp automates ASC 606 / IFRS 15 schedules and deferred-revenue waterfalls.
Where usage-based billing quietly loses revenue — and how to catch it.
Usage-Based Revenue Recognition FAQ
Frequently asked questions about recognizing revenue on usage-based and consumption contracts.
What is usage-based revenue recognition?
Usage-based revenue recognition is the process of recognizing revenue for consumption- or usage-priced contracts as the customer actually consumes the product, in accordance with ASC 606 or IFRS 15. Because the amount billed varies each period, the consideration is variable and revenue must follow consumption rather than the billing calendar — typically by drawing down prepaid credits or recognizing metered usage in arrears.
How is revenue recognized for usage-based billing under ASC 606?
Apply the five-step model with the usage twist: identify the contract and the (usually single, over-time) consumption obligation, determine the transaction price as variable consideration, allocate it, and recognize as the customer consumes. For straightforward pay-as-you-go where the invoice corresponds to the value transferred, you can use the right-to-invoice practical expedient (ASC 606-10-55-18) and recognize the amount you have the right to bill. Commitments, tiers, and retroactive pricing require estimating variable consideration and applying the constraint.
Is usage-based revenue variable consideration? Do I estimate it at contract inception?
Yes — usage-based fees are variable consideration. For pure pay-as-you-go invoiced in arrears, the right-to-invoice practical expedient often lets you recognize the invoiced amount without a separate estimate. When there are minimum commitments, tiered or retroactive pricing, or you recognize ahead of invoicing, you estimate the variable consideration (expected value or most-likely-amount) and apply the constraint — including it only to the extent it is probable a significant revenue reversal will not occur.
Does the sales- and usage-based royalty exception apply to my SaaS?
Usually no. The royalty exception (ASC 606-10-55-65), which recognizes revenue at the later of usage or satisfaction, applies only to licenses of intellectual property. Most usage-based SaaS is a service, not an IP license, so the exception does not apply — and misapplying it is a common error. For SaaS, recognize as the service is consumed, generally using the right-to-invoice expedient or a variable-consideration estimate.
How do I recognize revenue on prepaid usage credits?
When the customer prepays, record the cash as a contract liability (deferred revenue) — no revenue yet, because the consumption obligation has not been satisfied. As credits are drawn down by usage, move the corresponding amount from contract liability to revenue. If credits expire unused and are non-refundable, recognize breakage — in proportion to the pattern of rights exercised if you can estimate it, otherwise when the likelihood of the customer using the remaining credits becomes remote.
How do I handle minimum commitments plus overages?
Recognize the committed minimum as the related usage occurs (or ratably if it is a stand-ready commitment satisfied evenly over time), and recognize overage usage above the commitment as it is incurred at contractual rates. The key control is reconciling actual metered usage to the commitment each period so the split between committed and overage revenue is correct and any unused commitment is treated per the contract.
What about late-arriving usage and the billing-vs-recognition frequency mismatch?
Usage events frequently arrive after period close, and you may bill monthly while consumption happens daily. Set a clear cutoff policy (consumption date vs. processing date), accrue unbilled usage as needed, and reconcile late-arriving events in the following period. The recognition frequency should follow consumption, not the invoice cycle, which is why a reconciliation layer between metering and the ledger matters.
Is usage-based revenue recognition different under IFRS 15?
Largely the same. IFRS 15 and ASC 606 are substantially converged for usage-based revenue: both provide a right-to-invoice practical expedient and both limit the usage-based royalty exception to licenses of intellectual property. Differences are minor and mostly outside usage recognition (for example, certain licensing and collectibility nuances), so a single policy can usually serve both with documented exceptions.
Can my billing engine (Stripe, Orb, Metronome) do revenue recognition?
Only partially. Billing engines meter usage and produce charges; some offer a rev-rec add-on, but they generally do not reconcile usage against the signed contract or run a full ASC 606 subledger. Most teams pair a billing engine with a revenue subledger that reconciles usage to the contract, catches under-billing, and generates audit-ready recognition schedules.
How does LedgerUp automate usage-based revenue recognition?
LedgerUp is an AI revenue subledger that sits on top of your billing engine. It reconciles metered usage and overages against the signed contract, generates ASC 606 / IFRS 15 schedules directly from consumption (handling variable consideration, the constraint, and prepaid-credit drawdown), and posts recognized revenue and deferred-revenue waterfalls to your ERP — keeping billing, cash, and revenue on one reconciled ledger.