The ultimate guide to revenue recognition with usage-based pricing

Your pricing strategy? It’s simple—$0.001 per API call.

But revenue recognition? Not as simple.

Here’s why: Usage-based revenue recognition comes with its own set of challenges.

Traditional subscription models provide predictable, stable income through fixed periodic fees. Regardless of whether a customer uses your service extensively or barely at all, you end up receiving the same payment. This predictability makes financial planning straightforward and appeases investors who value stability.

In contrast, usage-based models create variable revenue streams that fluctuate with customer consumption patterns. While this more accurately reflects the value delivered, it introduces significant complexity for financial forecasting, cash flow management, and revenue recognition.

When implemented correctly, usage-based pricing can increase customer satisfaction, reduce barriers to adoption, and create more accurate value-to-price alignment. However, it requires specialized knowledge of both regulatory requirements and technical implementation to get right.

If you’re looking to understand how usage-based revenue recognition works and how you can make it easier for your team, this guide is for you.

Let’s jump in.

Understanding usage-based revenue in SaaS

Usage-based revenue is income generated when a customer actually consumes your service instead of paying a flat fee.

Say you offer a communications API platform and charge $0.0075 per SMS. One of your clients, an ecommerce company, sends 2,000,000 SMS messages a month and pays you $15,000.

Unfortunately, business has slowed down. Last month, they sent only 1,000,000 SMS messages and paid $7,500.

Usage-based pricing is an excellent model because it gives your customers more flexibility. But it makes revenue recognition a bit more complex for you.

The complexity of usage-based revenue is not in the math. It’s in handling the variability in usage patterns. This volatility in revenue makes forecasting revenue and cash flow a lot more challenging than other revenue models.

Types of usage-based pricing models

Here’s an overview of types of usage-based pricing models:

• Time-based pricing: Customers are charged based on the duration they use the service, such as hourly billing for virtual machines or meeting rooms.
• Consumption-based pricing: Pricing is tied to the quantity of resources consumed, such as gigabytes of data stored or the number of API calls.
• Tiered pricing: Usage falls into predefined tiers. Each tier offers a fixed amount of usage for a set price. For example, you might offer users 0–10,000 API calls for $100/month and increase pricing in blocks of 10,000 API calls.
• Volume-based pricing: The price per unit decreases as usage increases—think bulk discounts where higher usage leads to lower rates per unit.
• Peak loading: Pricing varies based on demand or peak usage periods. This is often the case with energy companies or cloud services, where users pay more during high-traffic times.
• Event-based pricing: Charges are triggered by specific user actions or events. For example, a SaaS company may charge a customer for sending a transaction or triggering a webhook.
• Pay-as-you-go pricing: A flexible, real-time model where customers are billed only for actual usage. No commitments. No tiers. This model is perfect for unpredictable workloads, such as a data analytics platform running ad-hoc queries or processing event data that varies daily.

And, if these aren’t complicated enough, many SaaS companies use a hybrid pricing model. A hybrid pricing model could consist of two or more usage-based pricing components or a usage-based component combined with a subscription or minimum commitment fee. 

Revenue recognition principles for usage-based SaaS models

All publicly-owned US companies are required to comply with ASC 606 (or IFRS 15, where applicable) to recognize revenue. When dealing with usage-based revenue recognition, here are some key principles you must follow:

• Recognize revenue when remaining performance obligations (RPO) are satisfied: Revenue should be recognized only after you’ve delivered the service (i.e., when usage occurs), not when the contract is signed or money is received.
• Ensure usage is measurable and trackable: You need a reliable system that can track usage data accurately and in real-time. For example, if you charge customers per API call, you might track usage with a metering system that logs every call.
• Revenue recognition should mirror how the customer actually receives value: In usage-based models, this usually means recognizing revenue only when usage occurs.
• Only use accepted methods to estimate variable consideration: You can only use either the expected value or the most likely amount method—whichever best reflects the usage pattern—to estimate variable consideration.
• Early recognition constraints: You can recognize usage-based revenue before the actual usage only if it passes the constraint test. According to ASC 606-10-32-11, you can recognize revenue before usage only if it’s “highly probable that a significant reversal of cumulative revenue recognized will not occur when the uncertainty is resolved.”
• Allocate transaction price in bundled contracts based on relative standalone selling prices (SSPs): When you receive payment for a bundled product or service, you must split the revenue based on the SSP of each product or service among all items in the bundle. We’ll explore the concept of SSP, which is covered in ASC 606-10-32-31, in the next section.

How to do usage-based pricing revenue recognition

To recognize revenue according to ASC 606 or IFRS 15, use the following five-step model:

• Step 1. Identify the contract: Ask yourself if there’s a customer and a legally binding contract with them.
• Step 2. Identify performance obligations: What exactly are you promising to deliver in the contract? That’s your performance obligation.
• Step 3. Determine the transaction price: What’s the total amount you expect to earn? For companies that charge based on usage, determining the transaction price is possible only at the end of the period. It’s calculated by multiplying the per-unit cost by the number of units used.
• Step 4. Allocate the transaction price to obligations: When there’s just one performance obligation, the full transaction price is allocated to that obligation.
• Step 5. Recognize revenue: You recognize revenue only once the customer has used your service.

Example of revenue recognition with a usage-based pricing model

Suppose you sign a contract with a customer to offer API calls for $0.01 per API call. You don’t charge any upfront fees.

You’re providing access to your API—that’s your single, ongoing performance obligation.

At the end of the period, your customer used 100,000 API calls. That makes $1,000 (100,000 x $0.01) your transaction price.

You recognize $1,000 in revenue at the end of the period based on the 100,000 API calls used during that month.

But there’s a catch here. What if you offer bundled products? How do you split revenue between those obligations?

That’s where SSP comes in.

How SSP works

Now let’s look at another example to understand how SSP works...

All steps in the revenue recognition process remain unchanged, except Step 4. Instead of directly allocating the full transaction price, you split it across each performance obligation based on its SSP.

Say you sell a package for $2,000 per month that includes:

• Dashboard Access (usually sold for $1,000 per month)
• Analytics API Access (usually sold for $800 per month)
• Premium Support (usually sold for $400 per month)

In this case, your SSP is $2,200 ($1,000 + $800 + $400).

Now, allocate the $2,000 (price of the package) based on the relative SSP of each item:

• Dashboard Access: ($1,000 / $2,200) x $2,000 = $909.09
• API Access: ($800 / $2,200) x $2,000 = $727.27
• Premium Support: ($400 / $2,200) x $2,000 = $363.64

When you recognize revenue in Step 5, you don’t just book $2,000 to one line item. You split the transaction price proportionally based on SSP and recognize revenue whenever you deliver any part of the service.

Challenges in recognizing usage-based revenue for SaaS companies

Here are some common challenges you might encounter when dealing with usage-based revenue as a SaaS company:

• Metering and measurement challenges: You can’t recognize revenue until you can measure usage reliably. An unreliable usage-tracking system introduces the risk of underbilling and over-recognition. That’s why you need an accurate, audit-ready tracking system to stay compliant.
• Revenue forecasting challenges: Revenue is inherently volatile for companies with a usage-based pricing model. Predicting future usage is tough when customer behavior fluctuates based on demand, budgets, or app integrations.
• Audit challenges: Auditors will ask for evidence that shows revenue was recognized based on actual, measurable performance obligations. Expect friction if your tracking lacks transparency or your recognition methods aren’t well-documented. To avoid trouble, maintain an audit trail and follow ASC 606’s five-step model like gospel.
• Billing system limitations: Many SaaS billing platforms aren’t built with usage-based pricing in mind. For example, a traditional billing system might fail to handle multi-attribute pricing, where you charge $0.001 per API call but only after 1,000 free calls, and only during business hours. You might be able to fix these problems with custom integrations, but being mindful of your tech stack’s limitations is critical.
• Currency fluctuations: Billing in foreign currencies while reporting in your home currency adds another layer of complexity to usage-based revenue recognition. Before recognizing revenue from bills in foreign currencies, familiarize yourself with the guidelines provided in ASC 830, which governs foreign currency matters.

‍Best practices for usage-based revenue recognition in SaaS

Here’s an overview of best practices you should follow if you recognize revenue based on usage:

• Build a reliable system to track usage: Build a system that can accurately track usage in real-time. Faulty metering leads to revenue leakage and compliance headaches, so test your system’s accuracy before taking it live.
• Develop clear revenue recognition policies: Define your revenue recognition policies in compliance with ASC 606 or IFRS 15 as applicable. A well-documented policy eliminates room for guesswork. For example, your policy can include details like when a performance obligation is considered satisfied, how usage is tracked, and what information is shared with finance teams, auditors, and regulators.
• Integrate your systems: Integrate your usage-tracking, billing, and accounting systems. The ability to exchange data eliminates a lot of manual work. Manually transferring data between systems also risks delays and errors.
• Use advanced forecasting models: Predict revenue using historical usage patterns and, if possible, a machine learning algorithm. This gives you a sense of what revenue might look like next year and helps manage investor expectations.
• Maintain comprehensive documentation: Record how usage is measured, when revenue is recognized, and any judgment applied. Good documentation will help you later during an audit and make scaling much smoother.‍
• Stay current with regulatory changes: Revenue recognition standards evolve, so assign someone to monitor FASB/IASB updates. Staying compliant now helps you avoid tedious retrospective adjustments later.

Revenue recognition is easier with the right tools in place

Usage-based revenue recognition isn't mathematically complex. It's just tedious because it requires you to calculate SSP and proportionate revenue every period. To comply with ASC 606 or IFRS 15, you must track every dollar of revenue and customer contracts. Make one mistake, and you risk running into trouble during the audit. 

Drivetrain is a powerful, intuitive FP&A platform designed specifically to address the challenges of usage-based revenue recognition. It integrates seamlessly with your usage tracking systems to ensure data accuracy, provides real-time validation, and creates audit-ready trails of all transactions. For revenue forecasting complexities, Drivetrain can help predict future usage patterns, create multi-scenario forecasts, and enable granular revenue projections across customers, products, and geography.

What makes Drivetrain particularly powerful for usage-based revenue recognition is its ability to function as a single source of truth by integrating data from accounting, ERP, CRM, billing systems, and data warehouses. Its driver-based modeling capabilities allow you to build sophisticated revenue models where usage metrics directly drive revenue calculations. 

With multi-dimensional analysis, you can break down revenue recognition by any dimension (customer, product, region, or time period) while continuous planning features let you easily update models as usage patterns change. Real-time P&L, cash flow, and balance sheet reporting show the impact of recognized revenue immediately across all financial statements.

The bottom line: Drivetrain eliminates manual work, reduces compliance risk, and provides the insights you need to forecast revenue accurately even with the inherent variability of usage-based models.