Usage-based pricing (also called consumption-based, metered, or pay-as-you-go pricing) charges customers based on how much they actually use a product rather than a flat monthly fee. It aligns cost with value, lowers the barrier to entry, and powers companies like Snowflake, Twilio, and AWS. The tradeoff is that revenue moves every month, which is why most companies run a hybrid: a committed base plus usage on top.
This guide covers what usage-based pricing is, the models available, how to choose the metric you bill on, real examples, and the two things most articles skip: how to forecast revenue that changes every month, and what it actually takes to operate.
If you are still deciding between pricing models rather than implementing this one, start with the guide to SaaS pricing models and strategy. This page goes deep on usage.
Understanding Usage-Based Pricing
Usage-based pricing is a model where customers pay based on their actual use of your service rather than a fixed monthly or annual fee. Think of it like your electricity bill: you pay for what you consume, no more and no less.
For example, Stripe charges per successful transaction, AWS bills based on computing resources used, and Twilio charges per message sent. This differs significantly from traditional subscription models where customers pay the same amount regardless of how much they use the service.
Usage-based, consumption-based, metered, pay-as-you-go: same thing
The terms are used interchangeably and the distinctions are mostly stylistic:
- Usage-based pricing is the general term in SaaS.
- Consumption-based pricing is the same idea, more common in cloud and infrastructure.
- Metered billing describes the mechanics: you meter events, then rate and invoice them.
- Pay-as-you-go usually implies pure usage with no commitment.
- Outcome-based pricing is a genuinely different thing, covered near the end. It bills for a result, not a unit of consumption.
The model has gained significant traction in recent years. According to OpenView's research on usage-based pricing, companies that adopt it tend to post stronger net dollar retention, and among recent software IPOs the best-retaining companies disproportionately use usage-based models. Companies like Snowflake have grown from startup to multi-billion dollar enterprise while using usage-based pricing from day one.
Types of usage-based pricing models
Almost nobody runs pure usage. The practical question is which structure you wrap around it.
| Model | How it works | Revenue predictability | Example |
|---|---|---|---|
| Pure usage | Pay per unit consumed, nothing else | Lowest | Twilio (per message or minute) |
| Hybrid (base + usage) | Platform or subscription fee plus metered usage on top | Good, the base is a floor | HubSpot, Salesforce Data Cloud |
| Tiered | Unit rate changes as volume rises | Same as underlying model | AWS |
| Package / prepaid credits | Customer buys a bundle of units up front and draws it down | High, cash is collected early | Snowflake credits, SendGrid |
| Pooled | Usage aggregated across a period or accounts before rating | Better, spikes smoothed | CDNs billing 95th-percentile bandwidth |
| Commit plus overage | Annual or monthly minimum commitment, overage billed above it | Highest, standard in enterprise | Most enterprise data and infra contracts |
| Percentage of value | A cut of the transaction or value flowing through | Tracks the customer's business | Stripe (% per transaction) |
Two of these deserve a closer look. Tiered pricing can be structured as volume-based (the new lower rate applies to all usage once a tier is reached) or graduated (different rates apply to usage within each tier). The choice changes the customer's bill dramatically at tier boundaries, and graduated is usually the safer default because volume tiers create a cliff where consuming one more unit lowers the total bill. Pooled pricing often charges on a percentile of usage, so temporary spikes do not blow up the invoice.
How to choose your billing metric
This is the decision that determines whether the model works. Everything else is implementation. Score each candidate metric against five criteria:
| Criterion | The question | Failure mode if you get it wrong |
|---|---|---|
| Value alignment | Does it rise as the customer gets more benefit? | You bill more while the customer feels no more value, so they churn at renewal |
| Predictability | Can the customer forecast and control it? | Surprise invoices, which is the number one source of usage-based churn |
| Visibility | Can they see and explain it internally? | The metric fails procurement because nobody can budget for it |
| Measurability | Can you meter it accurately and dispute-proof? | Billing disputes, credits, and a support burden that eats the margin |
| Growth headroom | Does your revenue expand as they scale? | You cap out on your best accounts |
Metrics that commonly work: API calls, records or rows processed, gigabytes stored or transferred, messages or minutes, transactions, documents, seats above a threshold, and for AI products, tokens consumed or agent actions completed.
Two anti-patterns worth naming. First, billing on something the customer cannot control, such as background system events, guarantees disputes. Second, billing on a metric that falls when the customer succeeds, for example charging support tools per ticket when the customer's goal is fewer tickets, puts your revenue and their success in direct opposition.
You do not have to pick only one. Many products meter a primary metric and add a second for a distinct cost driver, though each extra dimension makes the invoice harder to explain.
Usage-based pricing examples
| Company | Bills on | Structure |
|---|---|---|
| AWS | Compute, storage, bandwidth consumed | Tiered usage |
| Snowflake | Compute credits and storage | Prepaid credits, drawdown |
| Twilio | Messages sent, call minutes | Pure usage |
| Stripe | Percentage of each successful transaction | Percentage of value |
| Datadog | Hosts monitored, events, log volume | Hybrid, per-host plus usage |
| SendGrid | Emails sent | Prepaid packages |
| OpenAI and other model providers | Tokens processed | Pure usage |
| Intercom Fin | Resolved customer conversations | Outcome-based, $0.99 per outcome |
Snowflake's approach to data warehouse pricing, based on actual compute and storage usage, helped them achieve one of the largest software IPOs in history. Their model let customers start small and grow usage naturally, producing net revenue retention that peaked above 170% (moderating as the company scaled). Stripe shows the other end of the range: a percentage of transaction value works equally well for a business processing occasional payments and an enterprise handling millions.
Usage-based vs subscription vs per-seat
| Per-seat | Flat subscription | Usage-based | |
|---|---|---|---|
| Customer pays for | Number of licences | Access, regardless of use | Actual consumption |
| Expansion happens when | Headcount grows | They upgrade a tier | They use more, automatically |
| Expansion needs a sales motion? | Usually yes | Yes | No |
| Typical NRR | ~95-105% | ~95-105% | ~115-130% (m3ter) |
| Revenue predictability | High | Highest | Lower, unless you add a commit |
| Risk | Customer cuts headcount and your revenue falls with it | Heavy users are underpriced, light users churn | Usage dips hit revenue immediately |
The NRR gap is the whole argument. Usage and hybrid models tend to post net revenue retention around 115-130%, while flat per-seat models cluster nearer 95-105% (m3ter). The mechanism is structural rather than clever: when revenue scales with a metric the customer's own success drives, expansion happens without anyone selling it. Expansion revenue has grown from roughly a quarter to about 40% of new ARR for the median SaaS company between 2022 and 2024 (Maxio/Benchmarkit), so the pricing model you pick increasingly decides how much of your growth is free.
The per-seat risk cuts the other way now too. If a customer automates work and cuts headcount, seat-based revenue shrinks even though the customer is getting more done with your product.
Benefits of Usage-Based Pricing
Usage-based pricing aligns your revenue directly with the value customers receive. When customers get more value from your product (indicated by higher usage), you earn more revenue. That alignment creates a natural incentive for you to make customers succeed.
It also reduces barriers to entry. Instead of committing to a large monthly fee, customers start small and scale spending as they grow. A startup on AWS might begin with minimal cloud resources and increase usage as their user base expands.
Consider an email marketing platform. On a traditional subscription, a small business might pay for a plan allowing 10,000 emails per month even if they send 2,000. Under usage-based pricing they pay only for what they send. That fairness tends to produce higher customer satisfaction and longer retention.
Finally, growth paths get smoother. As customers scale and increase usage, your revenue grows automatically without uncomfortable renegotiations or plan upgrades.
Potential Drawbacks
The most significant drawback is revenue predictability. When customers vary usage month to month, forecasting gets harder, which affects financial planning and investor conversations. The next section is entirely about fixing this, because it is solvable.
Customers also struggle with budget planning. Without a fixed monthly cost they have to monitor usage and estimate future needs, and that uncertainty makes some buyers hesitant, particularly enterprises with strict budgeting processes.
The model requires real infrastructure for metering usage, rating it, and invoicing accurately. This is the part founders underestimate, so it gets its own section below.
One more that gets missed: usage-based revenue falls faster in a downturn. A customer who would have kept paying a flat subscription while using your product less will simply consume less and pay less. Your revenue is more responsive in both directions.
How to forecast usage-based revenue
Usage-based revenue is not unforecastable. It is forecastable in a different shape: instead of one number per customer per month, you model a floor plus a distribution.
First, build a floor into the pricing
Four structural levers restore predictability without giving up the upside:
- Minimum commitments. The customer commits to a dollar floor for the term and pays overage above it. This is standard in enterprise consumption contracts and it is what makes the revenue plannable at all.
- A platform or base fee. A flat component that covers access, billed regardless of usage.
- Prepaid credits with drawdown. Cash arrives up front and revenue is recognised as credits are consumed. Watch the rollover and expiry terms, they determine whether unused credits ever become revenue.
- Annual rather than monthly terms. Same usage, far less month-to-month noise in the commitment.
Most companies that look like clean usage-based businesses from the outside are running commit plus overage underneath.
Then model it as a distribution, not an average
The mistake is forecasting average usage per customer. Usage is almost always skewed: a small number of accounts drive most consumption, so the average sits above the median and a single large account moving materially changes the total. A workable approach:
- Split the revenue into committed and variable. The committed portion forecasts like a subscription. Only the variable part needs usage assumptions.
- Model usage by cohort and ramp. New accounts rarely start at steady-state consumption. Ramp curves by cohort beat a flat per-customer average.
- Segment by account size. Model your top accounts individually and the long tail statistically. Blending them hides the concentration.
- Forecast a range, not a point. Run a low, base and high usage case, because the honest answer to "what is revenue next quarter" is a band.
- Track the leading indicators: usage trend per account, consumption against commitment (are they on pace to burn their commit?), and the share of accounts trending below their minimum. Under-consumption against a commit is the single best early warning of a downgrade at renewal.
This is why usage-based businesses need a driver-based financial model rather than a revenue spreadsheet. The drivers are accounts, usage per account, and price per unit, and revenue is the output. Get that structure right and the variability becomes something you can bound instead of something that surprises you. It also flows straight into runway, since more volatile revenue means you want more buffer for the same risk.
Revenue recognition for usage-based pricing (ASC 606)
Worth understanding before you launch, because it changes what you can report. This is a general explanation rather than accounting advice, so confirm the treatment with your accountant.
Under ASC 606, usage fees are variable consideration: the total depends on future events you do not control. That creates two paths.
The as-invoiced practical expedient. For straightforward pay-as-you-go billed in arrears, where the amount invoiced corresponds directly to the value delivered in that period, you can recognise revenue at the amount you have the right to invoice (the right-to-invoice expedient, ASC 606-10-55-18). This is the simple case and it covers a lot of pure usage models. Usage in the month, invoice for the month, revenue in the month.
Estimating variable consideration. Once you add minimum commitments, retroactive volume tiers, prepaid credits, or anything where recognition and invoicing diverge, you have to estimate. ASC 606 offers two methods: the expected value method (a probability-weighted average of outcomes) and the most likely amount method (the single most likely outcome). You then apply the constraint, including the estimate only to the extent it is probable a significant revenue reversal will not occur, and re-estimate every reporting period.
The practical consequences: your billed amount and your recognised revenue will not match month to month, tier structures with retroactive rates are meaningfully harder to account for than graduated ones, and prepaid credits sit as a liability until consumed. If you want reporting to stay simple, that is an argument for graduated tiers and billing in arrears.
What you need to operate it: metering and billing
Usage-based pricing fails operationally more often than strategically. Four capabilities are non-negotiable:
- Metering. Reliable ingestion of usage events at volume, with idempotency so a retry does not double-bill, and late-arriving events handled correctly.
- Rating. The engine that turns metered events into charges, applying tiers, discounts, commitments, credits, minimums and overage. This is where the complexity actually lives.
- Invoicing and collection. Variable invoices, mid-cycle changes, proration, and disputes.
- Reporting. Usage and revenue views your finance team can reconcile, plus the customer-facing view so buyers can see what they are spending before the invoice lands.
That last point is underrated. A usage dashboard the customer trusts prevents most billing disputes and most surprise-invoice churn.
On build versus buy: metering and rating look deceptively simple and are not. Purpose-built billing platforms exist for exactly this (Stripe's usage-based billing, along with specialist vendors such as Metronome, Orb, m3ter, Chargebee, Recurly and Ordway among others). We have not benchmarked them and this is not a recommendation, evaluate against your own metric and volume. The general rule holds: build it yourself only if your metering is genuinely unusual, because rebuilding a rating engine after you have live contracts is painful.
Migrating from per-seat without churning customers
Repricing an existing book is riskier than launching with usage. What tends to work:
- Model the impact per account first. Apply the new pricing to last year's actual usage and see who pays more. If a meaningful share of your base faces a large increase, the metric or the rate is wrong.
- Grandfather existing contracts and launch the new model for new customers. You learn on accounts with no expectations to break.
- Cap the increase for migrating accounts for the first term. A ceiling costs less than the churn.
- Run both in parallel for a period and let customers pick. The self-selection tells you which segments the new model actually suits.
- Give usage visibility before you start billing on it. Show customers what they would have paid for a cycle or two first. Nothing generates goodwill like no surprises.
Expect some downgrades from over-served accounts. That is not necessarily a failure, since those customers were paying for capacity they never used, but model it so the transition does not look like a churn problem to your board.
Outcome-based pricing: the next step
Usage-based pricing bills for consumption. Outcome-based pricing bills for a result. The distinction matters more as AI products take over work rather than assist with it, because consumption stops being a good proxy for value: nobody wants to pay per token, they want to pay for the job getting done.
The clearest live example is Intercom's Fin, priced at $0.99 per outcome. Intercom counts an outcome when the customer confirms their issue is resolved, or does not ask for more help after Fin responds, or Fin completes a workflow, and charges once per conversation regardless of how many questions were answered. Failed attempts are not charged. Other vendors are experimenting with per-conversation and per-action pricing on AI agents.
It is still early and still a small minority of products, for good reasons. Defining the outcome precisely enough to bill on it is hard, attribution is contested when a human also touched the work, and your gross margin now depends on how efficiently your model resolves cases, so inference cost becomes a direct margin question rather than an infrastructure line. If you are considering it, the definition of the billable outcome is the entire design problem. See the full outcome-based pricing guide for examples and how to price it.
Is Usage-Based Pricing Right for Your SaaS?
It fits when most of these are true:
- You have a clear usage metric that correlates with the value customers get, and you can measure it accurately today.
- Usage varies widely across your customer base. If everyone consumes roughly the same amount, a flat subscription is simpler and forecasts better.
- Your costs are largely variable and scale with that same metric. High fixed costs point toward a hybrid with a meaningful base fee.
- Your market expects it. In cloud infrastructure, APIs and data, usage-based is the norm. In team collaboration tools, subscriptions still are.
- You can fund the billing infrastructure, or buy it.
If usage does not vary much, or you cannot meter the metric cleanly, a hybrid with a small usage component gets you most of the expansion benefit at a fraction of the operational cost. That is usually the right first move rather than a full switch.
Usage-Based Pricing FAQ
What is usage-based pricing?
A model where customers pay according to how much they consume, such as messages sent, gigabytes stored, or API calls made, instead of a fixed subscription. Think of it as a utility bill for software.
Is usage-based pricing the same as consumption-based or metered billing?
Effectively yes. "Consumption-based" is more common in cloud and infrastructure, "metered billing" describes the mechanics of metering and rating events, and "pay-as-you-go" usually implies no commitment. Outcome-based pricing is different: it bills for a result rather than a unit of usage.
What are the main usage-based pricing models?
Pure usage (pay per unit), hybrid (base fee plus usage), tiered (rates change by volume, either graduated or volume-based), prepaid packages or credits, pooled (aggregated over a period), commit plus overage (a minimum commitment with overage above it), and percentage of value like a cut of each transaction.
How does usage-based pricing affect revenue predictability?
It lowers it unless you build in a floor. The four levers are minimum commitments, a platform fee, prepaid credits, and annual terms. Then forecast the committed portion like a subscription and model only the variable portion, by cohort and account size, as a range rather than a point. Most apparently pure usage businesses run commit plus overage underneath for exactly this reason.
How do you forecast usage-based revenue?
Split revenue into committed and variable, model usage by cohort with a ramp curve rather than a flat average, handle large accounts individually and the tail statistically, and produce a low/base/high band. Track consumption against commitment as your leading indicator, since accounts pacing below their minimum are the ones that downgrade at renewal.
How is usage-based revenue recognised under ASC 606?
Usage fees are variable consideration. For simple pay-as-you-go billed in arrears you can often use the right-to-invoice practical expedient (ASC 606-10-55-18) and recognise what you have the right to bill. Add minimum commitments, retroactive tiers or prepaid credits and you must estimate using the expected-value or most-likely-amount method, apply the constraint, and re-estimate each period. Confirm the treatment with your accountant.
What software do you need for usage-based billing?
Four capabilities: event metering (with idempotency and late-event handling), a rating engine that applies tiers, commitments and credits, variable invoicing, and reporting your finance team can reconcile plus a usage view customers trust. Purpose-built platforms cover this; building your own rating engine is harder than it looks and painful to replace once contracts are live.
Usage-based pricing vs subscription: which is better for NRR?
Usage and hybrid models tend to post net revenue retention around 115-130% versus roughly 95-105% for flat per-seat (m3ter), because expansion happens automatically as customers consume more instead of requiring an upsell conversation.
What is a minimum commit?
A contractual floor: the customer commits to spend at least a set amount over the term, and pays overage for consumption above it. It gives you a plannable revenue base and gives the customer a volume rate. It also creates the useful diagnostic of tracking who is under-consuming their commit.
How do you move from per-seat to usage-based pricing?
Model the new pricing against last year's real usage per account first, grandfather existing contracts, launch to new customers, cap increases for migrating accounts, and show customers their usage for a cycle or two before billing on it. Expect some downgrades from accounts that were over-served.
What are the downsides of usage-based pricing?
Revenue is harder to forecast, customers struggle to budget without a fixed cost, it requires real metering and billing infrastructure, and revenue falls faster in a downturn because customers simply consume less rather than having to cancel.
Is usage-based pricing right for my SaaS?
It fits best when you have a clear usage metric that correlates with value, customers whose usage varies widely, and largely variable costs. If everyone uses roughly the same amount, a flat subscription may serve better, and a hybrid with a small usage component is often the right first step.
Related pricing and revenue reading
- SaaS pricing models and strategy, the pillar guide for choosing between models.
- Net revenue retention (NRR), the metric usage-based pricing moves most.
- Expansion revenue and MRR expansion, where the compounding shows up.
- How to build a SaaS financial model, the driver-based structure a usage business needs.
- Transaction fees, if you are pricing as a percentage of value.
