Revenue recognition under ASC 606 and IFRS 15 is more straightforward for subscription contracts than most people expect. A customer pays $1,200 for annual software access, you recognize $100 per month as the performance obligation is satisfied. The math is simple because the consideration is fixed.
Usage-based contracts break that simplicity at every step. One major reason is the consideration is variable and the performance obligation is satisfied continuously in amounts you don’t know in advance. In addition, the billing metric may change, and contracts can get amended mid-period. Customers purchase prepaid credits that may or may not be consumed. Each of these creates accounting complexity that finance teams need to resolve before the first invoice goes out.
This guide covers how ASC 606 and IFRS 15 apply to the most common usage-based billing structures and where the accounting gets complicated.
The Core Problem: Variable Consideration
Under ASC 606 Step 3 (determine the transaction price), usage-based revenue is almost always variable consideration. The total contract value isn’t known at inception because it depends on how much the customer actually consumes.
The standard requires you to estimate variable consideration using either the expected value method (a probability-weighted average of possible outcomes) or the most likely amount method (the single most probable outcome). The method you choose should better predict the amount you’ll ultimately be entitled to, and you need to apply it consistently across similar contracts.
The constraint is where it gets harder. You can only include variable consideration in the transaction price to the extent it’s probable that a significant revenue reversal won’t occur when the uncertainty resolves. For usage-based contracts where consumption can vary dramatically, this is often the harder question: how much estimated usage can you recognize before you’re at risk of a reversal?
In reality, most controllers apply a conservative estimate and update it each reporting period as actual usage data accumulates. The cumulative catch-up approach under ASC 606 means that changes in estimates are recognized in the period the estimate changes, not prospectively and not restated. Your billing system needs to feed accurate, timestamped usage data into the revenue recognition engine each period so those estimates can be updated correctly.
Performance Obligations in Usage-Based Contracts
Before you can recognize any revenue, you need to identify what you’ve promised to the customer. For usage-based contracts, this is more complex than a subscription because the contract often bundles multiple elements.
Platform access plus consumption
If you charge a platform fee plus a usage rate, these may be one performance obligation or two, depending on whether the platform access is distinct. If a customer can’t get value from the platform without consuming the usage-based service, then it’s likely a single combined obligation. However, if platform access has standalone value, they are separate obligations that require allocation of the transaction price.
Professional services and implementation
If onboarding or implementation services are included in the customer’s contract, it’s important to determine whether they’re distinct from the ongoing usage-based service. Services that are highly integrated with the platform capability are generally not distinct. However, routine implementation that any qualified third party could perform is more likely to be distinct.
Usage credits and prepaid amounts
When a customer pays upfront for a block of usage credits, the performance obligation is to provide access to those credits as they’re consumed. Revenue is recognized as credits are used, not when they’re purchased. This is covered in more detail in the prepaid credits section below.
Minimum commitments
A minimum commit doesn’t change the performance obligation structure. It affects the transaction price and variable consideration estimate, which is covered in the true-ups section below.
Getting the performance obligation structure right matters because it determines how you allocate the transaction price across elements and the pattern in which you recognize revenue as each obligation is satisfied.
Recognizing Revenue as Usage Occurs
For a pure usage-based performance obligation (ASC 606 Step 5), revenue is recognized over time as the customer uses the service. Progress is usually measured in units of consumption, such as each API call, token, or transaction that is processed. Revenue equals the usage in the period multiplied by the applicable rate.
This sounds clean in theory, but three things make it operationally difficult.
Data latency
Usage events may not reach your billing system in real time. When there’s a delay between consumption and reporting, you have usage that occurred in one period but hasn’t been processed yet. You need a clear policy for cutoff, which usually uses the consumption date instead of the processing date. Your billing system also needs to be able to backdate event attribution to the correct period.
Out-of-period events
Customers may sometimes disagree with usage, ask for changes, or send in corrected data after the period is over. This makes changes to the variable consideration in the period when the correction is made, not a restatement of previous periods. Write down your policy for how to deal with these changes before they happen.
Tiered pricing and retroactive re-rating
If your pricing model lowers the rate for a customer after they reach a certain volume, you have variable consideration that changes based on how much they use it over the entire period. You need to estimate the effective rate for each period based on how much you think you’ll use it and then make sure it’s right at the end of the period. As a customer moves closer to the next tier, their recognized revenue needs to be adjusted.
Minimum Commitments and True-Ups
Minimum commitments are common in enterprise usage-based contracts. A customer agrees to pay at least $X per period regardless of actual consumption, with additional charges if usage exceeds the commitment. The accounting treatment depends on the structure.
Usage exceeds commitment
This is straightforward because revenue is recognized as usage occurs. The minimum commitment is simply a floor that wasn’t binding.
Usage falls below commitment
In this scenario, the customer pays the minimum regardless of their usage. Recognize the minimum commitment amount as revenue in the period. The shortfall is effectively a breakage question such as did the customer forfeit value?
True-up at period end
If the contract specifies a true-up at the end of a defined period, you have variable consideration that becomes fixed at that date. During the period, estimate the likely true-up amount and recognize revenue accordingly. When the true-up period closes, recognize the actual amount and record the cumulative catch-up adjustment.
Period boundary note
If the true-up crosses a reporting period boundary, usage in Q4 that determines a true-up payable in Q1 for example, you need that liability accrued at period end. The accounting entry exists in Q4 even though the invoice goes out in Q1.
Prepaid Credits and Breakage
When customers buy usage credits ahead of time, the payment creates a contract liability (deferred revenue). When credits are used up, revenue is recognized, which means the performance obligation has been met.
Breakage accounting is needed for credits that expire without being used. There are two ways to do things under ASC 606:
Proportional method
Recognize breakage based on how credits are used up. If a customer buys 1,000 credits and your historical data shows that 10% of those credits go unused, you should recognize 10% of the credit revenue as the other 90% is used. This is the most common way to go when you have reliable historical data on redemptions.
Remote method
Only recognize breakage when the chance of redemption is very low. This is true when redemption patterns are difficult to predict, or when expired credits might be subject to legal obligations like unclaimed property laws.
It is important to use the method consistently and back it up with historical data. You’ll need a supportable estimate and documented basis for your policy if you are launching a new product without a history of redemption.
One practical complication: if credits never expire, or if your contract gives customers the right to roll over unused credits, you may have a customer option for additional goods or services, which is a material right under ASC 606 that requires separate accounting treatment.
Contract Modifications
Usage-based contracts often get amended. For example, customers negotiate new pricing tiers, add product lines, change minimum commitments, or extend contract terms. Each modification needs to be evaluated under ASC 606 to determine whether it’s a new contract or a modification of the existing one.
A modification is treated as a new contract if the new goods or services are distinct, and the price reflects their standalone selling price. In that case, account for it prospectively.
If the modification doesn’t meet both criteria, it’s treated as a modification of the existing contract: either a cumulative catch-up adjustment (if the remaining goods and services are distinct) or part of a single performance obligation going forward (if they’re not).
In practice, most usage-based contract amendments are modifications of existing contracts because the ongoing service is continuous and not distinct from prior periods. Document the modification, reassess the variable consideration estimate, and apply the cumulative catch-up.
What Your Billing System Needs to Support
The accounting described above isn’t achievable without accurate, timestamped usage data feeding directly into your revenue recognition process. The gap between billing and revenue recognition is where audit risk accumulates.
At minimum, your billing infrastructure needs to attribute every usage event to the correct customer, billing period, and contract; support backdated event processing with clear period cutoff controls; rate usage so variable consideration estimates are grounded in actual consumption data; and generate the journal entries for recognized revenue, deferred revenue, and accrued revenue automatically as usage is processed.
When billing and revenue recognition run in separate systems, every month-end close requires a reconciliation. Differences accumulate, adjustments get made manually, and the audit trail becomes difficult to defend. The cleanest solution is one where the billing event and the revenue recognition entry come from the same system and the same data.
BillingPlatform’s revenue recognition is built into the billing workflow. Usage events flow from ingestion through rating, invoicing, and revenue recognition in a single system. Finance teams get real-time revenue schedules, automated journal entries, and a complete audit trail without a separate reconciliation process.
For a full breakdown of platform requirements, see the Usage-Based Billing: The Definitive Enterprise Guide.
To see how BillingPlatform handles revenue recognition specifically, visit the revenue recognition solution page.
Additional resources
