Usage-based billing is no longer a rare thing in the world of enterprise software pricing. OpenAI, AWS, Snowflake, Twilio, and Databricks all use this model. Over 61% of SaaS companies have adopted it, and that number is still going up. If your company is making a product that could be priced based on how much it’s used, the finance team shouldn’t be an afterthought in that decision.
The issue is that most companies don’t involve finance until it’s too late. People in product and sales make pricing decisions, contracts are signed, and then the CFO’s team gets a billing model that they didn’t help design. They have to figure out how much money to expect, how to recognize it correctly, and how to explain it to auditors. That order makes a risk that doesn’t have to happen.
This playbook is for finance leaders who want to be part of the conversation before decisions are made and for those who are now being asked to understand a usage-based model that is already being used by customers. It has seven steps, starting with figuring out what happens to your finances when you switch to usage-based billing and ending with making the case for the change to leadership and the board.
For the complete enterprise guide to usage-based billing — including pricing model definitions, platform requirements, and implementation steps — see Usage-Based Billing: The Definitive Enterprise Guide.
Step 1: Understand What Changes Financially
The most important thing for finance to remember about usage-based billing is that contracts signed no longer determine revenue. It’s based on how customers act.
Once you close a deal and book the ARR, your revenue becomes mostly predictable with a subscription model. With usage-based billing, the contract might set a minimum commitment and a pricing structure, but the real revenue depends on how much the customer uses the product each month. That means that sales activity and revenue outcome are linked in a completely different way.
This makes a lot of things different for finance teams. For instance, forecasting needs more than just pipeline data; it also needs usage trend data. To recognize revenue, you need a clean, time-stamped record of every consumption event, not just a signed order form. The way churn analysis is done is also changing. A customer who stops using your service is sending a different message than a customer who cancels their agreement, and you should respond differently to each.
It also changes the chances of generating more revenue. Without any new sales effort, a customer who grows into your product automatically brings in more money. With pure subscription models, it’s hard to get net revenue retention (NRR) above 100%. But with this model, it’s possible. In fact, the best businesses that charge for usage keep their NRR above 120%.
To understand everything that comes next, you need to understand this change. Usage-based billing isn’t just a different pricing structure. It’s a different operating model for the revenue function
Related: SaaS usage-based pricing trends | Consumption-based pricing guide
Step 2: Build Your Revenue Model Before Pricing Is Set
When prices are set, finance should be part of the discussion. Decisions made during the pricing stage have direct effects on revenue predictability, margin, and financial reporting. It’s easier to deal with these effects before contracts are signed than after.
Scenario modeling is where you start. For any usage-based pricing model being looked at, finance should come up with three scenarios: a conservative case (based on the least amount of expected use), a base case (based on how most customers use similar products or market data), and a high case (based on what happens when a customer scales significantly). Margin problems usually happen in the space between these two scenarios, especially if COGS goes up with usage.
One of the best ways to deal with revenue floor risk is to use minimum commitments. A customer who agrees to pay a set amount each month, no matter how much they actually use, gives finance a revenue floor that they can plan for. To get these terms into contracts, finance needs to be involved in the deal structure phase, not after.
Before they can be offered to customers, volume tiers and discount structures also need to be modeled financially. A tiered pricing model that offers big discounts at higher volumes can lower margins faster than expected if more people start using it. You need to do the math at 2x and 5x the current usage, not just the current usage.
The output of this step should be a revenue model that shows, for different usage scenarios, what the P&L looks like, including the effect on recognized revenue, deferred revenue, and COGS.
Step 3: Map the Cost Structure
With traditional SaaS, the marginal cost of serving one more customer approaches zero. Infrastructure and support costs grow gradually as the customer base expands. Usage-based products are different. For example, every unit of consumption, every API call, every token processed, every gigabyte transferred, and every transaction rated generates real infrastructure cost that scales directly with customer activity.
Finance needs to understand and document the cost structure of the usage-based product before pricing is finalized. That means working with product and engineering to map what it actually costs to deliver one unit of consumption, whatever that unit is for your product. The categories vary by business, but the questions are the same: what are the direct infrastructure costs per unit, what are the platform and tooling costs that scale with volume? What does support cost as usage grows? And what overhead such as logging, monitoring, and compliance, scales with event volume rather than headcount?
Once those costs are mapped, translate them into unit economics. What does it cost to deliver one unit at the current volume? What does it cost at 2x volume and at 5x? This is where companies get surprised: a pricing model that looks profitable today can become margin-dilutive at scale if the cost structure wasn’t modeled at higher usage levels.
It’s also worth understanding that usage costs don’t always scale linearly. Some cost components, particularly infrastructure and compute, can grow faster than usage volume as systems hit capacity thresholds or require architectural changes to scale. Build that into the model before pricing goes live, not after.
The goal of this step is a unit economics model that tells finance exactly what each unit of usage costs to deliver and what the margin looks like across a range of price points and consumption levels.
Step 4: Address Revenue Recognition Before Pricing Goes Live
ASC 606 and IFRS 15 say that finance needs to be involved in figuring out how to recognize revenue for usage-based models before prices are given to customers. The models that are most commercially attractive for usage-based products carry specific accounting implications that, if not addressed in advance, create problems that are difficult to fix after contracts are signed.
Performance obligations
Finance needs to figure out what is different and can be delivered separately for each usage-based contract. Access to the platform, usage credits, professional services, and outcome-based components can all be separate performance obligations, or they can be combined. If you don’t identify the obligations correctly, you might speed up or slow down revenue incorrectly, and it’s hard to fix after the fact.
Variable consideration
Under ASC 606, usage-based revenue is almost always variable consideration because the total value of the contract isn’t known at the start. You have to guess the variable consideration and limit it to the amount that is likely to not be significantly reversed. Before the pricing model goes live, the finance teams need to write down how they came up with the estimates. They also need to update those estimates every reporting period as more data on actual usage becomes available.
Minimum commitments and true-ups
If contracts have a minimum commitment and a true-up at the end of the period, the accounting for the true-up needs to be figured out ahead of time. When a retroactive re-rating happens during a reporting period, it creates variable consideration that should be estimated at the start and updated as the period goes on.
Credit and prepaid balance treatment
When customers buy credits ahead of time and use them up, the accounting is based on deferred revenue, which means that revenue is recorded as credits are used. Unused credits that expire need to be accounted for in a certain way (either the proportional or remote method), and this needs to be done consistently and with the help of historical redemption data.
The most important thing finance can do
Revenue recognition for usage-based contracts should be designed at the same time as the pricing model — not as an afterthought once the sales team is already in the market. Fixing RevRec methodology after contracts are signed is significantly harder than building it in from the start.
Related: Revenue recognition for usage-based billing contracts | BillingPlatform revenue recognition
Step 5: Define the Metrics That Matter
Usage-based businesses require a different set of operating metrics than subscription businesses. Finance needs to define these metrics, establish how they’ll be calculated, and build the reporting infrastructure to track them before the model launches.
Net Revenue Retention (NRR)
This is the single most important metric for a usage-based business. NRR measures how much revenue you retain and expand from your existing customer base, accounting for churn, contraction, and expansion. An NRR above 100% means your existing customers are collectively spending more than they were a year ago which translates to growth without new sales. Best-in-class usage-based businesses sustain NRR above 120%.
Usage growth rate
Track consumption growth per customer, not just total revenue growth. A customer whose usage is growing is a very different risk profile from one whose usage is flat or declining. Usage growth rate is an early indicator of NRR trajectory and is more actionable than lagging revenue metrics.
Revenue per unit
As pricing tiers and discounts evolve, effective revenue per unit can drift significantly from list pricing. Tracking this metric flags when discount structures or volume tiers are compressing margins in ways that weren’t planned.
Revenue leakage rate
The percentage of billable usage events that fail to reach an invoice. Leakage comes from dropped events, duplicate records, transformation errors, and mediation failures. A 1–3% leakage rate is common in organizations without robust mediation infrastructure. At $10M ARR, that’s up to $300,000 in revenue that never gets billed. Finance should treat leakage as a controllable loss and measure it explicitly.
Days Sales Outstanding (DSO)
Usage-based invoices are often more variable and harder for customers to predict, which can slow payment. Tracking DSO for usage-based contracts separately from subscription contracts helps identify where collections processes need adjustment.
Step 6: Evaluate Your Billing Infrastructure
The billing platform is where usage-based revenue strategy either works or breaks down operationally. Finance has a direct stake in this evaluation and should be actively involved, not as an approver at the end of the process, but as a key stakeholder defining requirements from the start.
The most expensive billing infrastructure mistake is selecting a platform based on what your pricing model looks like today, rather than what it will need to handle in two to three years. Usage-based models evolve. New pricing tiers get added, enterprise customers negotiate custom terms, and product lines expand. A platform that requires engineering involvement for every pricing change will become a bottleneck.
Finance should verify the following before a billing platform is selected:
Revenue recognition is built in, not bolted on
If the billing platform requires a separate revenue recognition module or a manual export to a third-party system, every billing cycle creates reconciliation risk. The cleanest architecture is one where usage events flow from ingestion through rating, invoicing, and revenue recognition in a single system. The further apart billing and revenue recognition are, the more manual work and audit exposure you accumulate.
The mediation layer handles your data volume
If your product generates high-frequency usage events like API calls, tokens, or device interactions, the platform needs to ingest, validate, and rate those events in with low latency. Ask for specific volume benchmarks, not marketing language.
Finance teams can configure pricing without engineering
Changes to pricing tiers, discount structures, and contract terms should be configurable through a visual interface without writing code or opening an engineering ticket. If finance can’t control pricing configuration directly, every commercial decision creates a development dependency.
The audit trail is immutable
Every billing event, pricing rule change, invoice adjustment, and revenue recognition entry needs a timestamped, unchangeable audit trail. For companies subject to SOX controls or external audit, this is non-negotiable.
Related: Key platform requirements for usage-based billing | How to choose a usage-based billing solution | BillingPlatform usage-based billing capabilities
Step 7: Build the Internal Business Case
At some point, finance needs to present the decision to adopt or expand usage-based billing to leadership and, in many cases, to the board. The framing matters. Usage-based billing is not just a pricing change. It’s a change to the revenue operating model, and it affects forecasting, financial reporting, investor metrics, and infrastructure investment.
The business case has four components.
The revenue opportunity
Model what NRR looks like at different usage growth rates compared to your current subscription model. Show how a customer who grows into the product generates incremental revenue without incremental sales expenses. If you have data on customer usage patterns in your existing product, use it. If not, use market benchmarks from public companies that have made the transition.
The cost and margin profile
Present the unit economics model from Step 3. Show the margin at current usage, at 2x usage, and at 5x usage. Be explicit about where the cost structure becomes a risk and what mitigations are in place such as minimum commitments, pricing floors, or COGS optimization initiatives.
The operational requirements
Be specific about what needs to be true operationally for this to work like the billing infrastructure, mediation capability, revenue recognition automation, and the reporting infrastructure to track the metrics defined in Step 5. Present these as investments with a clear rationale, not as a cost line.
The risk and mitigation
Acknowledge the risks such as revenue predictability, billing complexity, and revenue recognition compliance, and present the mitigations for each. A board that sees a balanced analysis with explicit mitigations is more likely to approve than one that sees a presentation that only covers the upside.
The CFOs who navigate this transition most successfully are the ones who treat usage-based billing as a strategic infrastructure decision rather than a pricing question. Getting that framing right in the business case sets the tone for how the organization approaches the model going forward.
The Right Infrastructure Makes the Difference
Finance can do all of the work described in this playbook including model the revenue, map the costs, design the revenue recognition treatment, and define the metrics, yet and still run into execution problems if the billing infrastructure can’t operationalize it at scale.
BillingPlatform is an enterprise billing platform built for exactly this. It handles a wide range of usage-based pricing model variants, supports hybrid subscription-plus-usage contracts in a single system, includes built-in ASC 606 and IFRS 15 revenue recognition, and gives finance teams a low-code configuration environment so pricing changes don’t require engineering involvement.
Recognized as a Leader in the 2025 Gartner Critical Capabilities for Recurring Billing Applications (ranked highest in 3 of 5 use cases), the Forrester Wave: SaaS Recurring Billing Solutions Q1 2025, and #1 overall in the MGI 360 Agile Billing report, BillingPlatform serves global enterprises including Panera Bread, Clear Channel, DirecTV, and Carrier.
To see how BillingPlatform handles the billing infrastructure requirements covered in Step 6, visit the BillingPlatform usage-based billing solution page. To request a demo, contact the team here.