How AI and SaaS businesses can approach revenue recognition for usage-based models

Flat-fee subscriptions made revenue recognition straightforward. All a business had to do was divide the contract value by the service term (say 12 months) and recognize revenue accordingly. However, usage-based models break that simplicity, as there is variability in play. When a customer is billed based on the number of API calls, tokens processed, hours of usage, and the like, the amount they owe isn't known at the beginning of the billing period. This means there is no clarity in the amount of revenue that should be recognized either.

AI and SaaS companies today follow this as the default pricing model. Token-based LLM billing, per-request API billing, and similar consumption-based products have made usage-based billing more common. For finance teams, this shift means that variable consideration is at the core of how revenue is estimated and recognized now.

Here's how to think through revenue recognition under the standards and accounting frameworks that apply to your business—from IFRS 15 and ASC 606 to their regional equivalents—and why usage-based models introduce complexities that traditional flat-fee subscriptions rarely had to deal with.

Why usage-based pricing changes the starting point

Under a flat subscription, the transaction price is fixed and agreed to while signing the contract. Revenue is recognized when control is transferred. In usage-based subscriptions, the transaction price is not known at the beginning, and this brings in variable consideration to the center of the process.

IFRS 15 recommends two methods for businesses to estimate variable consideration. One is the expected value method where variable consideration is calculated using weighted-average probabilities of the possible outcomes. The other one is the most likely amount method where, as the name suggests, variable consideration is estimated using the outcome that is most likely to occur. For most AI and SaaS companies, the expected value method works better as the usage volume across a customer base typically follows a distribution rather than a binary outcome.

The variable consideration constraint

Estimating variable consideration alone isn't enough. IFRS 15 also requires businesses to apply a constraint: to include variable consideration in the transaction price only when it is highly probable that a significant revenue reversal won't happen at the end of the period.

For example, let's say an AI company prices its API at $0.002 per token with volume-based rebates. For a long term customer, the usage pattern is predictable and the business can accurately estimate and recognize revenue. However, for a new customer with no historical data, this method of estimation carries the risk of revenue reversal when usage patterns become clear. This is exactly what the constraint is meant to prevent.

Recognizing revenue as usage happens: The output method

For AI and SaaS contracts, revenue is recognized using what is called the output method. Here, progress is measured based on what is delivered to the customer (API calls served, tokens processed, compute hours consumed, and the like). This tends to be a more accurate representation of value transfer than the time-based approach.

For example, a customer on a usage based AI plan makes 3 million API calls in a given month at $0.01 per call. Revenue for that month is calculated purely based on the usage ($30,000).

Where hybrid and tiered pricing add complexity

Often, billing doesn't only happen based on usage. Most companies charge a flat platform fee and add the variable usage part to the top of it. This is also layered with volume tiers or minimum usage commitments. Each of these needs to be evaluated separately. The flat platform fee can be recognized ratably over the contract term. The usage component is recognized based on consumption. Volume tiers or minimum usage commitments also need to be considered, ensuring there is no double counting.

For example, an annual SaaS contract includes a $12,000 platform fee plus usage billed at $0.01 per unit, with a minimum usage requirement of 50,000 units per month. Irrespective of usage, revenue from the platform fee can be recognized at $1,000 per month. If the usage in a given month is 20,000 units, revenue still needs to reflect the minimum threshold of 50,000 units ($500) and not just the lower actual consumption.

Contract modifications are more frequent — and harder to track

Adjustments to contract terms are more common in usage-based models than flat-fee models. Each of these changes can qualify as a contract modification. Depending on the modification, they should be treated prospectively or retrospectively.

If the volume is low, this is mostly manageable. But at the scale most AI and SaaS companies operate, manually tracking these changes and making necessary adjustments becomes a significant operational and compliance burden.

Why manual processes break down fastest here

Usage-based revenue recognition is where spreadsheet-based finance processes tend to fail first, for a simple reason: the inputs change constantly. Unlike a flat-fee structure, where the recognition schedule is set once and rarely revisited, usage-based revenue needs to be recalculated every billing cycle, based on actual consumption data pulled from the product itself. Doing this at scale for hundreds and thousands of customers is a herculean task.

This is exactly the kind of process that benefits from being systematized rather than handled manually. Zoho Billing is built to handle metered and tiered usage billing alongside revenue recognition — recalculating transaction amounts as usage changes, applying the correct output-based recognition pattern, and handling contract modifications with either prospective or retrospective allocation based on the pro-rated amount. For AI and SaaS businesses scaling usage-based pricing, that means recognition stays accurate without finance having to manually reconcile consumption data against revenue schedules every month.

Conclusion

Usage-based billing is a better reflection of the value AI and SaaS products actually deliver — but it puts real pressure on revenue recognition processes that were designed for flatter, more predictable subscription models. Getting it right means treating variable consideration estimation, the revenue constraint, and output-based recognition as core parts of the billing cycle. As usage-based and hybrid pricing becomes the default rather than the alternative, the businesses that build recognition automation into their billing process early are the ones that stay audit-ready.