Master usage based billing for your SaaS business. Learn pricing models, ASC 606 revenue recognition, implementation steps, and migration strategies
Usage based billing has moved from an experiment to a structural change in SaaS monetization. Adoption rose from 27% of SaaS companies in 2020 to 46% in 2022, and a later survey found 85% of 100 SaaS companies already using the model by January 2025, according to BillingPlatform's usage based billing overview. The finance implication is easy to miss: charging by consumption changes not only your pricing page, but also your metering, invoicing, revenue recognition, forecasting, customer support, and month-end close.
For a $500K to $20M revenue business, the commercial logic can be compelling. Customers pay in proportion to the value or resources they consume, while you capture expansion without renegotiating every contract. But the model exposes weak controls quickly. A duplicate event can create a disputed invoice, a missing event can create revenue leakage, and an invoice issued after month-end can still require revenue recognition in the period when consumption occurred.
Usage based billing spread quickly because SaaS economics changed. The model grew from 27% adoption in 2020 to 46% in 2022, then reached 85% of surveyed SaaS companies by January 2025, based on the adoption data compiled by BillingPlatform. OpenView also projected that 61% of the general SaaS index would adopt some form of usage-based pricing by the end of 2023, reinforcing the view that consumption pricing had become a mainstream monetization strategy rather than a niche approach for utilities or infrastructure vendors.

The timing matters. AI products incur costs through model calls, tokens, compute, and storage. Infrastructure products already tie their economics to consumption. A flat subscription can hide the relationship between customer value and your marginal cost, while a usage metric gives you a more direct way to charge for the resources or outcomes customers use.
Seat pricing works when seats reasonably represent value. It becomes less effective when one customer has a small team generating heavy automated usage and another has a large team using the product lightly. Consumption pricing addresses that mismatch by charging against a metric closer to actual activity, such as API calls, processed records, storage, compute, or credits.
The model also changes how growth appears in your financials. A customer can expand usage inside an existing relationship, without a new seat purchase or contract amendment. That creates upside, but it also makes revenue less predictable. Your forecast now needs product usage signals, customer-level trends, committed minimums, and expected overages.
Finance rule: Usage based billing is a commercial decision with an accounting system attached to it. Treating it as only a pricing project guarantees rework after launch.
The market is large enough that this architecture now extends beyond SaaS. One estimate values the global usage based billing market at $9.4 billion in 2025, with a projection of $28.6 billion by 2034 and a 13.2% compound annual growth rate, while another estimates $5.4 billion in 2024 growing to $16.8 billion by 2033 at a 13.5% CAGR, as summarized by Orb's usage based billing statistics. Telecommunications represented 28.6% of 2025 revenues, or about $2.69 billion, in the segment data cited there.
For companies still using flat rates, the question isn't whether usage pricing is fashionable. It's whether your current model accurately captures value, protects gross margin, and gives customers a credible path to start small and expand.
The right structure depends on how predictable usage is, how clearly customers understand the unit, and how much marginal cost each unit creates. A storage platform can charge for usage directly. An AI product may need credits or a hybrid plan because customers want a predictable base while your costs vary with consumption.
The examples below use simple pricing to show the mechanics.
| Model | Best For | Example | Trade-offs |
|---|---|---|---|
| Pure consumption | Variable API, compute, or storage use | 20,000 API calls at $0.01 each equals $200 | Clear alignment, but monthly bills fluctuate |
| Tiered pricing | Customers with recognizable usage bands | First 1,000 units at $0.10, next 4,000 at $0.08 | Easy to package, but threshold behavior can confuse buyers |
| Volume pricing | Buyers that want one rate based on total volume | 5,000 units at a single $0.08 rate equals $400 | Rewards scale, but a threshold can change the price of every unit |
| Hybrid pricing | SaaS products needing a predictable base | $500 platform fee plus 3,000 overage units at $0.10 equals $800 | Supports forecasting, but requires careful allocation and overage logic |
With pure consumption, a customer using 20,000 API calls at $0.01 per call receives a bill of $200. If usage falls to 12,000 calls, the bill becomes $120. That simplicity works when the metric is easy to understand and customers can monitor it.
Under tiered pricing, the first 1,000 units at $0.10 costs $100. The next 4,000 units at $0.08 costs $320, producing a total of $420 for 5,000 units. The customer pays different rates within the same invoice, so your invoice must show the bands clearly.
Volume pricing applies one rate to the entire quantity. At 5,000 units priced at $0.08, the bill is $400. This can encourage customers to consolidate usage, but the threshold needs careful design because crossing it changes the effective rate for all units.
Hybrid pricing combines a fixed fee with variable charges. A $500 base fee, including a defined allowance, plus 3,000 overage units at $0.10, produces an $800 invoice. This structure often fits AI and infrastructure products because it gives customers a known starting point while preserving upside from heavy consumption.
For a practical view of how line items and service costs can be presented, review the NotFair cost breakdown. The useful lesson isn't the specific pricing format. It's that customers need to see what they're paying for, which units were included, and which units generated an additional charge.
Choose the least complex model that matches your economics. A rating engine won't rescue a metric customers can't forecast.
Usage-based charges create variable consideration. Under ASC 606 and IFRS 15, revenue is generally recognized when the customer consumes the service, not when you issue the invoice or collect cash, according to Stripe's usage-based revenue recognition documentation.

That distinction creates two clocks. The billing clock determines when you calculate and invoice the customer. The revenue clock determines when the service was delivered and the consideration became recognizable.
Start by identifying the billable event and the performance obligation it supports. If a customer uses an API during the month, that consumption belongs to the usage period even if your billing platform creates the invoice after the period closes.
A workable sequence looks like this:
Suppose a customer generates 10,000 billable events during a usage period and your contract prices each event at $0.02. The usage consideration is $200, regardless of whether the invoice is issued on the final day of that period or later. The accounting entry must place the revenue in the period of consumption, while the receivable and invoice timing follow your billing process.
Practical rule: Never use invoice date as a substitute for service date when consumption drives the transaction price.
Manual reconciliation becomes impractical beyond roughly 10,000 billable events per month, particularly when contracts combine subscriptions, credits, overages, and usage adjustments, as explained in the ASC 606 revenue recognition workflow from Jumpstart Partners. Your control environment should preserve event-level evidence, daily or monthly rollups, rating outputs, invoice lines, and journal entries.
Use automation where the volume or contract structure demands it. The system should support backfills, adjustment approvals, period locks, and a clear bridge from raw activity to recognized revenue.
The pricing page is usually the easy part. The production system has to capture every billable event, reject duplicates, aggregate consumption accurately, expose usage to customers, enforce limits, calculate charges, and preserve evidence when a customer challenges an invoice.
A reliable metering layer should capture consumption in real time, deduplicate retries, aggregate raw events into billable units, and retain an audit trail. The RevOps guide to usage-based pricing and metering also highlights the need to align metering granularity with billing cadence. You may roll hourly or daily activity into a monthly invoice, but you still need to trace the invoice back to the original events.

Hybrid pricing is becoming the dominant operating challenge. A 2026 benchmark puts hybrid adoption at 61%, with pure subscription below 15%, according to Aforo's usage-based pricing benchmark. Hybrid contracts create multiple reconciliation points because finance must connect the base subscription, included quantities, overages, credits, discounts, and consumption-period revenue.
Real-time billing remains uncommon. The same benchmark found that 17% of companies bill overages in real time, 10% bill daily, and 16% bill weekly. That leaves many teams calculating charges later, which increases the time customers spend without visibility into their liability.
Build controls before launch:
Finance and engineering should own this together. Engineering protects data integrity. Finance defines period controls, approval rules, revenue treatment, and reconciliation requirements. A structured financial operations management framework helps keep those responsibilities visible instead of leaving billing controls inside one team's backlog.
Warning sign: If support can't reproduce an invoice from raw usage data, your billing process isn't controlled enough for scale.
A migration fails when the company changes the price before it proves the meter. Start with measurement, not customer communication.

Define the value metric. Choose a unit customers understand and your product can measure consistently. Avoid metrics that correlate poorly with customer value or fluctuate because of internal system behavior.
Run historical simulations. Apply the proposed rules to prior usage records. Compare the calculated bills with current contract economics and identify customer segments that would experience sharp changes.
Create the contract policy. Decide whether existing customers are grandfathered, offered a migration option, or moved at renewal. Document included usage, overages, credits, minimums, caps, and treatment of corrections.
Build parallel billing. Run the old flat-rate calculation and the new usage calculation at the same time. Don't send the new invoice until finance can explain every difference between the two outputs.
Communicate with examples. Give each customer a plain-language explanation of the metric, allowance, rate, monitoring tools, and protections. Show a low-use, expected-use, and high-use scenario without promising that future consumption will match any example.
Pilot, review, then expand. Begin with a controlled customer group, review disputes and reconciliation exceptions, and expand only after the operational process performs consistently. Keep legacy billing available until the new path is stable.
The technical sequence should follow the same logic: instrument events, validate data, connect the rating engine, generate test invoices, integrate revenue recognition, then expose customer dashboards. A phased rollout lets early adopters use the new structure while legacy customers remain on their existing agreements.
Your deferred revenue schedule also needs a clear treatment for the fixed portion of hybrid contracts and any prepaid credits. Review the deferred revenue guidance from Jumpstart Partners before changing journal logic or closing the first migrated period.
Don't force migration because the new model is easier for your team. Force it when the old structure no longer reflects the product's economics, and give customers enough notice and control to understand the change.
A usage model needs two dashboards, not one. The executive dashboard should explain revenue movement. The operating dashboard should explain the usage events and customer behaviors causing that movement.
Track revenue per customer alongside the underlying usage quantity. If revenue rises while usage stays flat, a pricing or mix change may be responsible. If usage rises without corresponding revenue, investigate missing events, incorrect rating, credits, or unbilled overages.
| Metric | What It Tells You | Review Question |
|---|---|---|
| Usage expansion | Whether customers consume more over time | Are successful customers increasing usage? |
| Revenue per customer | How consumption translates into dollars | Does growth in usage produce expected revenue? |
| Usage-linked churn | Whether declining activity precedes cancellation | Are customers disengaging before they cancel? |
| Bill dispute rate | Whether customers understand and trust invoices | Which metric or contract term causes confusion? |
| Metering exceptions | Whether source data reaches billing intact | Where do events fail, duplicate, or arrive late? |
| Forecast variance | How well usage translates into expected revenue | Which customer assumptions need updating? |
Keep customer-level views separate from aggregate reporting. A total usage increase can conceal a major customer reducing consumption, while a small group of heavy users can make overall revenue look healthy. Your finance team needs contract, usage, invoice, and collection context in the same review.
For definitions and broader SaaS reporting structure, use the SaaS financial metrics guide from Jumpstart Partners. The important discipline is to connect each metric to an action, such as a customer success intervention, pricing review, billing correction, or forecast update.
Keep usage based billing in-house when your event volume is manageable, contracts are simple, and the finance team can reconcile usage to invoices and revenue without delaying close. Bring in specialist support when those conditions stop holding.
The clearest trigger is not customer count alone. It's the combination of high event volume, hybrid contracts, multiple billing systems, manual adjustments, and recurring disputes. If your team can't explain how raw events became invoice lines and recognized revenue, the control gap has already become a finance problem.
Look for a partner that can:
Jumpstart Partners provides outsourced controller and bookkeeping services for SaaS, agencies, and other growing businesses, including ASC 606 workflows, revenue recognition, reconciliations, KPI reporting, and investor-ready financials. Review its outsourced controller services if your team needs finance ownership without building the entire function internally.
If usage based billing is creating reconciliation work, revenue recognition uncertainty, or customer disputes, Jumpstart Partners can help you design the controls, connect billing data to the ledger, and establish a repeatable month-end close. Visit the firm to discuss your current billing stack and build a finance workflow that supports consumption revenue without sacrificing accuracy.