Revenue recognition for usage-based and hybrid pricing models in ASC 606

With a flat subscription, you know right at the beginning what the customer is going to pay you. With usage-based pricing, you don't. Let's say customers pay you based on the number of API calls they make. A customer might make 50,000 calls in March and 400,000 in April, and the amount for either month is not known until the month is over. Your books, however, still have to close on time.

This is the problem ASC 606 has to solve for usage-based and hybrid pricing models, where a fixed platform fee is combined with variable usage charges. This article explains how ASC 606 treats these models, the concepts that matter the most, and how to apply them with simple examples. If you would like a refresher on the basics first, check out this guide on the five-step revenue recognition model and this one on ASC 606.

Why usage-based pricing is different

In a flat-fee contract, the transaction price (Step 3 of the five-step model) is fixed and agreed to when the contract is signed. In a usage-based contract, the price depends on what the customer does later. ASC 606 and the other standards, like IFRS 15 and Ind As 115, treat this as variable consideration, and this is what makes usage-based revenue recognition different from a regular subscription.

For every usage-based contract, there are two questions the business should answer:

• How much of the variable amount can be included in revenue?

• Which period does it belong to?

Variable consideration and the constraint

Variable consideration includes usage fees, volume rebates, credits, and performance bonuses. Under ASC 606, you estimate it using one of two methods:

• Expected value – The probability-weighted average of possible outcomes. This works well when you have a large number of customers with similar usage patterns.

• Most likely amount – The single most likely outcome. This works better when there are only two possible outcomes, such as a bonus that is either earned or not.

You then apply the constraint. Variable consideration is included in revenue only to the extent that it is probable that a significant reversal of it won't happen once the uncertainty is resolved. This is crucial and doing it wrong might result in overstating or understating revenue. Let's say a new customer with no usage history has been promised a rebate if they cross a certain volume. With nothing to base an estimate on, being conservative is the safer approach compared to recognizing revenue that may have to be reversed later.

Why most usage fees are recognized as the usage happens

This is where usage-based contracts turn out to be simpler than they actually look. A cloud or API service is often delivered continuously through a series of similar service periods, such as each day or month of access. ASC 606 allows variable fees to be allocated entirely to the period in which the usage happens, if two conditions are met:

• The variable fee relates specifically to your effort in delivering that period's service, or to the customer's usage in that period.

• Allocating it to that period is consistent with how the price would be allocated overall.

The practical effect is that you don't need to estimate a full year of usage upfront. Revenue for each month's usage is recognized in that month. Let's say a customer is charged $0.01 per API call and makes 200,000 calls in March. Revenue for March is $2,000. If you invoice on the first of April, the revenue still belongs to March, so it is accrued at the end of the month as unbilled revenue.

When the invoice is raised in April, the unbilled receivable moves to accounts receivable.

This treatment doesn't work when the pricing makes the fee for one period depend on the volume of another period, such as retroactive discounts and commitments. Those are covered below.

How common usage-based pricing structures are treated under ASC 606

Tiered pricing

If each tier's rate applies only to the units within that tier, there is nothing to estimate. Let's say the first 10,000 units cost $0.10 each and the units after that cost $0.07 each. A customer using 15,000 units is charged, (10,000 × $0.10) + (5,000 × $0.07) = $1,350, which is recognized in the month of usage.

Retroactive volume discounts

When crossing a threshold lowers the price for all units, including the ones already billed, the discount is variable consideration. Let's say units are billed at $0.10, but if the customer crosses 120,000 units in a year, the price drops to $0.08 for all of them. If you expect the customer to cross the threshold, recognize revenue at $0.08 per unit from the start and carry the $0.02 difference as a refund liability. Revisit the estimate every period as actual usage comes in.

Minimum commitments

Let's say a customer commits to a minimum of $10,000 a month and is charged for any usage above that. In a month where usage comes to only $7,000, the customer still owes $10,000, so revenue is $10,000. The committed amount is fixed consideration. Only the usage beyond the committed amount is variable.

Prepaid credits and drawdown

Let's say a customer buys $12,000 of credits to use over a year. The cash is a contract liability (deferred revenue) when received and is recognized as the credits are consumed. If some credits expire unused, that unused portion is called breakage. It can be recognized in proportion to how the customer uses the rest of their credits, if you have historical behavior patterns to estimate it, or on expiry if you don't. This is covered in detail in the guide on gift cards and breakage.

Hybrid pricing models

Most usage-based businesses actually run hybrid models: a fixed platform fee, a usage component, and often a one-time onboarding fee. Each of these follows its own pattern, and applying a single treatment to the entire contract will get at least one of them wrong.

• Platform fee: The customer has access to the platform whether or not they use it. This is a continuous obligation and is recognized evenly over the contract term.

• Usage fees: Recognized in the period of usage, as explained above.

• Onboarding fee: If it delivers something the customer can benefit from on its own, recognize it as the work is delivered. If it is just set up for the subscription, spread it over the contract term.

Let's say a contract has a $1,000 monthly platform fee and charges $0.05 per unit above 10,000 units. In month three, the customer uses 14,000 units, so the overage is 4,000 × $0.05 = $200. Assuming the platform fee was invoiced in advance and is sitting in deferred revenue, month three looks like this:

Common mistakes in usage-based revenue recognition under ASC 606

• Waiting for the invoice: Revenue should be recognized when the usage happens. Billing in arrears shouldn't push revenue into the next period.

• Estimating a full year of usage upfront: This is often unnecessary when the usage fees can be allocated to the period of usage, and it risks overstating revenue.

• One treatment for every fee in a hybrid contract: Platform, usage, and onboarding fees each follow their own pattern.

• Ignoring retroactive discounts: Price breaks that apply to earlier units need to be estimated and trued up. They shouldn't be recognized only when the discount is finally triggered.

• Forgetting expiry on prepaid credits: Unused credits need a breakage assessment instead of sitting in deferred revenue indefinitely.

• Treating plan changes casually: A change in tiers or commitments mid-term is a contract modification and should be assessed as one. The guide on booking revenue recognition journal entries shows how these changes flow into the books.

Check the detailed guide on revenue recognition mistakes to go through the other mistakes businesses make and how to avoid them.

How Zoho Billing supports usage-based and hybrid pricing

Zoho Billing lets you set up metered billing, where customers are charged based on actual usage on top of a base fee. Usage can be billed automatically from usage records, and prepaid plans can deduct charges from a prepaid balance as usage happens. It applies established revenue recognition principles to subscriptions, including those with usage-based pricing, and provides reports that give you a clear view of recognized and deferred revenue.

For arrangements that don't fit a standard schedule, manual revenue recognition lets you control revenue at the line-item level. The Enterprise edition of Zoho Billing adds advanced usage-based billing controls and flexible revenue recognition configurations, with an audit trail behind every change.

If you want to see how this applies to your own pricing model, you can connect with our team for an exclusive demo of Zoho Billing.

Conclusion

Usage-based and hybrid pricing don't change what ASC 606 asks you to do. They change how often you have to answer the same two questions: What is the price? and When has it been earned? Treat fixed fees as fixed and usage as variable, recognize usage in the period it happens, and be careful with anything that ties one period's price to another period's volume, like retroactive discounts, commitments, and prepaid credits. With clear policies for each of these and a billing system that tracks usage accurately, usage-based revenue stays accurate even when the invoices lag behind.

Frequently asked questions (FAQs)