Usage-based pricing charges customers for what they consume, so the bill rises and falls with API calls, compute, storage or transactions instead of a flat monthly fee.
It has moved from niche experiment to mainstream: in a January 2025 survey of 100 SaaS companies, 85% already had some form of it.
You feel the appeal the moment one customer's usage spikes and the flat-fee math stops matching reality. The pricing idea is simple.
The operating model under it isn't: measuring usage, rating it, invoicing and collecting, and owning tax and disputes once buyers sit in other countries.
Most teams end up with a fixed floor and a meter on top, and every choice in that setup shows up on the customer's bill.
Which model you pick, how you package the meter and how you stop a heavy month turning into bill shock decide whether customers trust that bill.
Table of contents
- What is usage-based pricing?
- Which usage-based pricing models can you choose?
- How does usage-based billing work?
- How does consumption pricing change revenue?
- How do you package usage so customers can budget?
- How do you prevent bill shock?
- What changes when you bill usage worldwide?
- Is usage-based pricing right for your product?
- Ready to bill usage worldwide with Creem as seller of record?
- FAQs
What is usage-based pricing?
Usage-based pricing, also called consumption-based pricing, charges customers for measurable product consumption, such as API calls, tokens, compute time, or storage. An AI feature could charge for the tokens it generates.
It works like an electricity bill: the kilowatt-hours recorded by the meter set the consumption charge, with a fixed standing charge alongside it.
How it differs from subscription pricing
Your flat monthly plan sells access for the month. Without usage overages, the price stays the same however much the account consumes.
If an account runs twice its usual jobs, each with the same compute cost, those jobs cost you twice as much to deliver:
- Flat fee: leaves you absorbing that increase.
- Compute-based charge: puts the extra consumption on the customer's bill.
Usage charges can recur monthly too. Monthly billing sets the schedule, not whether the amount stays fixed.
Which usage-based pricing models can you choose?
Does a heavier month cost more or less per unit, and does the customer pay before or after using it?
Usage-based pricing models side by side, from pay-as-you-go to hybrid.
| Model | How charges are calculated | Best fit | Key trade-off |
|---|---|---|---|
| Per-unit pay-as-you-go | Units × unit rate | Infrastructure and API products with consistent billable units | Variable total |
| Graduated tiered | Each band has its own rate | Cheaper rates as usage climbs | Add up each band |
| Volume | One rate applies to all units | Whole-quantity discounts | Thresholds reprice everything |
| Block | Charge per usage bundle | Buying in batches | Unused capacity costs money |
| Hybrid | Base fee plus usage beyond the allowance | Steady access with spiky usage | Fixed fee is due even in a quiet month |
| Prepaid credits | Purchased balance drawn down by usage | Paying before use | Must explain what happens when credits run out |
Pay-as-you-go
Customers know the unit rate, but their final bill depends on consumption through the billing period.
Tiered and volume-based pricing
For an illustrative graduated schedule, charge $1 each for the first 100 units and $0.50 each for the next 100. Using 200 units costs $150.
Under volume pricing, a rule could make every unit cost $0.50 above 100 units. The bill drops from $100 at 100 units to $50.50 at 101.
Volume pricing makes sense when larger customers cost less to serve per unit, or when the product should clearly reward scale.
Hybrid pricing and prepaid credits
A hybrid SaaS pricing plan can include an allowance in the base fee, then charge for usage beyond it. That keeps baseline revenue when consumption varies.
A short video, , walks through how these models compare.
Prepaid credits are paid for before compute runs, without necessarily changing the unit price. Auto-refill buys more when the balance reaches a set threshold, so it does not cap spending.
How does usage-based billing work?
Usage-based billing connects product activity to payment through metering, aggregation, rating, invoicing, and collection:
- Metering records consumption as usage events.
- Aggregation turns those events into the quantity to bill.
- Rating applies your pricing rules to that quantity.
- Invoicing presents the charge to the customer.
- Collection takes payment against the invoice.
The meter records usage, the invoice goes out, the customer questions the charge, and the team spends time tracing it back.
Metering is one piece of billing for SaaS products, and the rest of that chain only works if the meter measures cleanly.
Why aggregation rules change the invoice
If your meter sends running totals of 10, 20 and 30 compute minutes from a zero starting point, the customer used 30 minutes.
Summing the readings produces 60 billable minutes, doubling the charge at a fixed per-minute rate with no allowances or other charges.
Sum aggregation fits events that report new usage, such as minutes consumed by each completed job. For a running total starting at zero for the billing period, last-value aggregation gives the consumed quantity.
Each rule fits a different way of charging:
- Maximum could bill for peak concurrent agents during the month.
- Unique count could bill for distinct active users, counting each user once regardless of how often they call.
- Last value could bill for storage held on the final day.
A hand count from one account's raw events, checked against the draft invoice, catches the wrong aggregation rule before a customer does.
Customers also need to see their own usage near real time, or they will assume the invoice is wrong even when it is correct.
How does consumption pricing change revenue?
A flat plan’s revenue stays set until renewal. The metered part moves with monthly consumption.
A busy account spends more, while a quieter account spends less without canceling.
Where the upside comes from
Once usage exceeds any allowance, an account that runs more jobs pays more at the same rate, with no upgrade conversation or new seat.
Without a minimum commitment, new customers can start small instead of buying a package.
Expansion can hide losses elsewhere. In an illustrative month, existing accounts:
- Start at $1,000 in revenue.
- Lose $200 through departures and lower usage.
- Add $300 through expansion.
They finish at $1,100: net revenue retention is 110%, while gross revenue retention, which excludes expansion, is 80%.
Report gross revenue retention next to net revenue retention every month, so that 110% result doesn’t hide the $200 that left.
Why forecasting and revenue recognition get harder
Good pricing can still be hard finance. A customer who commits an illustrative $12,000 for the year might consume most of it in one quarter.
Dividing by 12 gives $1,000 a month, which misrepresents that demand. Forecast from the account’s actual monthly usage instead.
Keeping the fixed base fee apart from variable usage revenue helps here, and this ARR calculation guide for subscription businesses shows how to separate the two.
When usage revenue counts
Revenue counts when you satisfy the performance obligation, meaning you deliver what the contract promises. Sending an invoice or receiving cash does not fulfill that promise.
Prepaid credits may promise a quantity of service or availability throughout a term, so recognition needn’t follow consumption alone. A quantity limit doesn’t settle that distinction.
These terms affect recognition, so set the schedule with your accountant:
- Unused quantities.
- Rollover rights.
- Continued access after credits run out.
How do you package usage so customers can budget?
“What will this cost us next month if we use it as planned?” Your offer needs a unit customers can predict and a written rule for consumption beyond the allowance.
Choosing a value metric
Choose the metric that your customer can explain in one sentence and your finance team can defend in one spreadsheet.
API calls may be easy to count, but charging equally for calls with different compute costs can leave expensive work underpriced. Compute minutes track that work more closely.
Customers also need control over consumption: the meter should move with jobs they choose to run, rather than invisible background activity.
Setting credit conversion rules
Credits need conversion rules too. For an illustrative wallet, one chat reply could cost 1 credit and one generated image 10 credits.
Ten replies then consume the same balance as one image, so customers can budget from their planned activity.
Building the offer around predictability
If your plan is $30 a month with 100 compute minutes included and $0.20 for each extra minute, a customer expecting 150 minutes can budget $40: the base fee plus $10 for 50 extra minutes.
Make the allowance’s boundaries visible beside the price:
- Billing period: when the allowance starts and resets.
- Covered activities: which work consumes the allowance and which charges sit outside it.
- Pooling: whether the allowance belongs to one user or a shared workspace, where everyone’s usage draws down the same balance.
- Exhaustion: whether work stops, incurs overages, requires a manual credit purchase, or automatically buys more credits beyond the initial balance.
How do you prevent bill shock?
An invoice arrives too late for customers to change the usage behind it. If customers can't see the meter, they'll budget for the worst case.
Spending needs to be visible while they can still pause work.
Controls that warn the customer, slow usage, or stop it before the invoice.
Dashboards, caps, and alerts
An illustrative dashboard might show:
- 4,000 compute minutes used.
- $80 accrued.
- $160 projected by month end.
At day 15 of a 30-day month, continuing at the same pace doubles usage and charges.
That $160 is a forecast. A busy last week can push the bill past it.
Each control acts at a different point:
- Alert: sends an email while jobs keep running.
- Soft cap: warns the customer near the limit without stopping anything automatically.
- Hard cap: a hard spending ceiling stops jobs before covered charges exceed the budget, while periodic checks can stop them after an overshoot.
Either can interrupt work mid-month. The controls need clear copy:
- Alerts: “Email the account owner at $160, or 80% of the $200 budget, with a link to raise it.”
- Soft caps: “You have used 90% of your $200 compute budget. Jobs keep running.”
- Caps: “At $200 in compute charges, stop workspace jobs. The base fee is excluded.” A per-job limit still allows many billable jobs.
- Enforcement: “Usage is checked hourly, so up to an hour of additional usage can land above the cap.”
- Recovery: “Raise the workspace compute budget to resume jobs.” For credits, explain whether buying a top-up restores access.
A monthly refill limit beside the auto-refill switch, and a note on whether an empty wallet stops usage, keep credit spend predictable.
Spend alerts, usage bars and cap controls work as retention features, because customers who can see and control spend keep using the product.
What changes when you bill usage worldwide?
The usage charge adds up, and then the buyer finds a VAT line they did not expect. Your meter explains consumption, but it doesn’t settle:
- The tax line.
- The invoice their accountant needs.
- The currency charged.
- A chargeback that arrives later.
Tax, currency and compliance work that comes with selling metered usage across countries.
A customer signing up with a company name may expect no tax line. Business buyers without a valid tax registration are often treated as consumers for tax.
Collect and check the buyer’s tax registration status at checkout before treating that purchase as B2B. Who owns the rest of the tax work depends on your setup:
- Payment processing alone: leaves you as the legal seller, responsible for tax registration, collection, and filing wherever the sale creates those obligations.
- Merchant of record: becomes the legal seller and takes responsibility for the sale’s indirect taxes.
Creem acts as merchant of record and handles VAT, GST and sales tax, subscription billing, revenue splits and affiliates in one integration. Choose based on who should own that work.
What the vendor still owns
You still set prices and build, deliver, and support the product. Having VAT remitted for you doesn’t settle the income or corporate tax you owe on your earnings.
When a customer disputes last month’s metered charge and asks for money back, your agreement determines the responsibility split. Ask the provider:
- Who receives the refund request?
- Who decides it?
- Who sends the money back?
Keep your own usage ledger to reconcile charges, correct events, and explain bills. Transaction administration can sit elsewhere while your team explains the activity behind the charge. Staying on global card processors still leaves tax registration and chargebacks on your books.
Is usage-based pricing right for your product?
A measurable cost isn’t enough to justify a usage charge. More consumption should also mean more value for the customer.
Otherwise, your bill tracks an expense they have little reason to accept.
Apply the water-meter test. Can you:
- Measure consumption reliably?
- Attribute it to the right account?
- Show a reading the customer can verify?
A compute-minute charge passes only if the customer can trace those minutes to their work.
That leaves three choices:
- Adopt usage pricing when running more jobs delivers more customer value and costs you more to serve, with a meter that passes the test.
- Hybridize when customers pay for an API that stays available and supported all month, with each job they run charged on top.
- Skip usage pricing if consumption hardly changes, customers can manipulate the meter, or charges feel unrelated to value, such as billing for background syncs they never triggered.
Most teams need a fixed floor, then a meter on top. The floor covers a light month, while the meter covers the extra work in a heavy one.
Before you adopt or add a meter, check that metering, billing, tax and collection connect in one money path.
Run one account through it: the customer should be able to open their bill, match each usage charge to their own activity, and see the correct tax line for their country.
Ready to bill usage worldwide with Creem as seller of record?
A usage plan takes an afternoon to decide. Running it across countries is the work that keeps growing:
- A meter customers trust.
- An invoice their accountant accepts.
- The right VAT or GST on every metered charge.
We built Creem so that work sits on one money path. Meters, credit wallets and auto-refill live in the same place as checkout.
As merchant of record, Creem becomes the legal seller in every country a card is charged.
The tax on each metered charge and the payouts to partners then sit beside checkout instead of in separate projects.
Your team keeps the product, the usage ledger and the customer conversations.
Once your value metric and package are set, try Creem on that plan. A buyer in a new country then gets a usage invoice their accountant accepts from the first charge, without a VAT registration from you.
FAQs
What are examples of usage-based pricing?
An API can charge per call, an AI feature per token, and a compute service per minute. Other examples include charging per unit of storage or per transaction processed.
Usage-based pricing vs usage-based billing: what's different?
Pricing chooses the unit, such as tokens, and sets the rules for calculating its charge.
Billing is what happens after: the meter counts the tokens, the billing system applies that rate, issues an invoice, and collects payment.
What types of usage can you charge for?
Requests, tokens, compute minutes, storage, and transactions can all work, as long as you measure consumption reliably, tie it to the right account, and let the customer check the quantity.
A token count shown in the customer’s usage log gives them something to verify against the bill. A count visible only to your backend doesn’t.