Usage-Based Billing: The Complete Guide (How It Works, Models, Examples & Software)

Usage-based billing charges customers for measured consumption during a billing period, such as API calls, tokens, gigabytes or transactions. The product records usage events, a meter aggregates them, a pricing rule turns them into charges, and the billing system issues an invoice. It can stand alone or sit alongside a recurring fee.

Consider a customer that makes 7.2 million API calls. Under graduated overage, its illustrative bill is $2,650. With a volume rate, it is $2,050. The usage is identical; the $600 difference comes from the pricing rule. A customer should be able to understand that rule, and the billing system should be able to prove each charge.

Often called consumption-based billing or metered billing, this approach includes pay-as-you-go and hybrid plans. This guide follows a hypothetical API plan from event to invoice, then examines what Product, Engineering and Finance need to agree on before launch. The prices are examples, not a Lago plan or market benchmark.

The short version

• Pricing decides the unit and rate. Billing executes the contract. A flexible price is useless if the events, credits and invoice cannot be reconciled.
• Tier design changes the bill. Our worked example produces $2,650 with graduated overage and $2,050 with volume-priced overage.
• Start with the customer-visible rule. Define what counts, when it counts, what is included, and what happens when usage exceeds the allowance.
• Test the edge cases before launch. Duplicate or late events, a midcycle plan change and a depleted credit balance reveal more than a clean demo invoice.
• Keep finance in the loop. Metered units, price versions, credits and invoice lines must reconcile to the accounting records.

In this guide

• What is usage-based billing?
• How does usage-based billing work?
• Usage-based pricing models (with formulas)
• Usage-based billing example: a worked calculation
• Usage-based billing examples by industry
• When does usage-based billing make sense?
• How to implement usage-based billing
• How to choose usage-based billing software
• How Lago handles usage-based billing
• What changes for AI products?
• Usage-based billing FAQs

What is usage-based billing?

Usage-based billing charges customers for measured product consumption rather than a fixed fee alone. The product records billable actions, a meter aggregates them by customer and period, and the price plan turns the result into invoice lines. The charge can stand alone or sit alongside a subscription.

Usage-based pricing versus billing

Usage-based pricing is the commercial decision: which unit to charge for, what is included and how rates change with volume. Billing carries out that decision. A price that looks simple on a pricing page still needs unambiguous rules for counting, late events, credits and the invoice.

Metered billing, consumption-based billing and pay-as-you-go

These terms overlap, but the emphasis differs.

Term	What it emphasizes	Common context
Usage-based billing	The full process from measured use to invoice	SaaS, APIs and AI products
Metered billing	Counting a defined unit with a meter	Infrastructure, telecom and utilities
Consumption-based billing	Drawing down a resource or commitment	Cloud and enterprise contracts
Pay-as-you-go	Paying for use without a recurring minimum	Developer products and variable workloads

Usage-based versus flat-rate subscription billing

A flat subscription makes the next invoice easier to predict. Usage pricing can fit customers whose consumption varies widely, but the bill becomes variable. Many companies combine a base fee with included usage and overage.

Decision	Flat-rate subscription	Usage-based charge
Revenue forecast	Recurring amount is known in advance	Amount varies with activity
Fit with customer activity	Same fee within a tier	Charge follows the selected metric
Expansion	Requires a plan, seat or contract change	Can grow as usage grows, if the contract allows it
Billing work	Recurring schedule	Events, aggregation, rating and corrections
Finance work	Forecast from contracts and renewals	Forecast usage and reconcile variable charges

The right mix depends on the buyer's budget, the product's value metric and the vendor's marginal cost. See usage-based versus seat-based pricing.

How does usage-based billing work?

Usage-based billing works in six steps. Your product emits an event for every billable action. A meter deduplicates and aggregates events per customer. Rating applies the price plan. The system generates an invoice, collects payment and retries failures. Finance then applies its revenue recognition policy to what was billed.

[[DIAGRAM: usage-based-billing-flow]] Usage event → Meter → Rate → Invoice → Payment, then revenue reporting.

Step 1: Capture usage events

Every billable action becomes an event sent to the billing system. An event records a fact, never a price.

Event field	Why it matters
Unique event ID	Makes retries safe: the same event sent twice is billed once
Customer or subscription ID	Ties usage to the right plan and contract
Metric code	Says which billable metric the event feeds
Usage timestamp	Places the event in the right period, even if it arrives late
Properties	Quantities and dimensions you price on now or may later (model, region)

A complete event in Lago's format appears in the Lago section. Our guide to adding usage to an existing SaaS covers instrumentation without rewriting core code.

Step 2: Meter and aggregate usage

Usage metering turns raw events into a billable quantity per customer and period. A billable metric pairs an event code with an aggregation rule.

Aggregation	What it computes	Metric example
Count	Number of events	API calls, messages
Sum	Total of a property	Tokens, GB transferred
Max	Highest value in the period	Peak concurrent connections
Unique count	Distinct values of a property	Monthly active users
Latest	Last reported value	GB stored at period end
Weighted sum	Sum prorated by time in use	GB-hours, server-hours

The meter also enforces data quality: duplicates dropped, late events placed by timestamp.

Step 3: Rate usage against the price plan

Rating applies the plan's prices to aggregated usage: the charge model, included allowances, filters such as a rate per model or region, and any negotiated terms. Keep price versions dated so last month's invoice can be reproduced after a change.

Step 4: Generate the invoice

At period end, or when usage crosses a threshold, rated charges become an invoice. Each line should trace back to its metric and events. This illustrative invoice uses the hybrid plan worked through below:

[[IMAGE: annotated-usage-invoice]]

Invoice line	Quantity	Rate	Amount	What it is
Platform fee	1 month	$500	$500.00	Base fee, the recurring floor
API calls, included	1,000,000	$0	$0.00	Allowance inside the fee
API calls, 1M to 5M	4,000,000	$0.40 per 1K	$1,600.00	Overage, tier 1
API calls, above 5M	2,200,000	$0.25 per 1K	$550.00	Overage, tier 2
Subtotal			$2,650.00	Prepaid credits, discounts and tax apply after this line

Many plans bill the fee in advance and usage in arrears, so one invoice can cover two periods. Label both.

Step 5: Collect payment and handle failures (dunning)

A payment provider collects the invoice. Some payments fail, so you need retries and reminders, known as dunning. Usage invoices vary month to month, so clarity matters more than with a flat fee.

Step 6: Recognize revenue (ASC 606 / IFRS 15)

Billing tells you what you invoiced; revenue recognition tells you what you earned. Under IFRS 15 and ASC 606, revenue follows the transfer of the promised service, with rules for variable amounts such as usage fees (IFRS Foundation). Billing owes finance a traceable record. The policy belongs to finance and its auditors, and this isn't accounting advice. See making usage-based revenue auditable.

Usage-based pricing models (with formulas)

A usage-based pricing model defines which units receive which rate. Choose it using real customer usage distributions, including unusually large accounts and months with near-zero activity. These patterns can be combined in a single plan.

Model	Calculation	Main tradeoff
Per-unit (pay-as-you-go)	Billable units × unit rate	Simple to explain; no revenue floor
Graduated tiers	Sum of units in each tier × that tier's rate	Smooth unit economics; invoice needs a tier breakdown
Volume tiers	Chargeable units × rate selected by total volume	Easy discount story; bill can fall at a tier boundary
Packages	Blocks started × block price	Predictable package price; unused units may frustrate customers
Percentage or transaction	Transaction value × rate, plus any fixed fee	Follows payment volume; fees need a clear basis
Hybrid	Recurring fee + rated usage beyond the allowance	Revenue floor; allowance and overage must be legible
Prepaid credits	Starting balance − rated usage + top-ups	Budget control; expiry and exhaustion need rules
Minimum commitment	Contract minimum plus any contract-specific overage or true-up	Predictability; finance must track drawdown and unused commitment
Dynamic or outcome-based	Sum of event amounts, or verified outcomes × rate	Can match variable work; harder to explain and audit

What is the difference between graduated and volume pricing?

Graduated pricing applies each tier's rate only to units in that tier. Volume pricing selects a rate using total usage and applies it to the units specified by the contract. Crossing a volume boundary can reduce the total bill. Model the amount immediately below and above every boundary before publishing the plan. The worked example shows both calculations.

How do hybrid pricing, credits and commitments work?

A hybrid plan combines a recurring fee with usage charges, often after an included allowance. Prepaid credits draw down as usage is rated; top-up and expiry rules must be explicit. A minimum commitment gives a spend floor, but drawdown, overage and true-up terms vary by contract. See credit-based pricing and hybrid pricing models.

When do per-unit, package, percentage and outcome models fit?

Per-unit pricing fits a unit the customer already tracks, such as API calls. Packages sell blocks, such as a quantity of tokens. Percentage pricing follows transaction value. Outcome pricing needs a result both parties can verify. Dynamic rates can track variable delivery cost, but require a clear, auditable rate rule.

Usage-based billing example: a worked calculation

To calculate a usage-based bill, take the plan's fixed fee, subtract any included allowance from metered usage, then price the remaining units with the plan's charge model. The examples below are illustrative, with hypothetical prices, and show how much the choice of model changes the total.

Hybrid plan example

A $500 monthly platform fee includes 1M API calls. Overage is graduated: $0.40 per 1K calls from 1M to 5M, then $0.25 per 1K above 5M. The customer makes 7.2M calls.

• Platform fee: $500
• 1M to 5M: 4,000 × $0.40 per 1K = $1,600
• Above 5M: 2,200 × $0.25 per 1K = $550
• Total: $2,650

The same usage priced as volume

Keep the fee and the 1M included calls, but price overage on volume tiers. The 7.2M total lands above 5M, so all 6,200 thousand-call units of overage bill at $0.25.

• 6,200 × $0.25 = $1,550
• Total: $500 + $1,550 = $2,050

The same usage bills $600 apart. In this example, the volume rate is selected by total usage but applies only to the 6.2M calls above the included 1M. Another contract might apply it to all calls. Spell out that rule. Also test the bill immediately below and above each tier boundary: volume pricing can make the total fall when a customer crosses one. Before you publish, replay real account usage under both models.

The rise of prepaid credits

An illustrative credit plan where 1 credit equals $1:

Event	Balance	What happens
Customer buys 1,000 credits	1,000	Paid up front; credits land once payment is confirmed
Weeks 1 to 3: usage rated at $700	300	Low-balance alert fires at 300
Week 4: usage rated at $80	220	Balance falls below the 250-credit top-up threshold
Automatic top-up of 500 credits	720	New purchase invoice; credits added after payment

Decide the conversion rate, expiry and consumption order before launch. See prepaid credits vs progressive billing.

AI / LLM token billing example

Price input and output tokens separately, per model, with a margin over provider cost. Illustrative rates per million tokens, with a 1.5x markup:

Line	Tokens	Cost per 1M	Price per 1M	Billed
Large model, input	200M	$3.00	$4.50	$900
Large model, output	40M	$15.00	$22.50	$900
Small model, input	1,000M	$0.20	$0.30	$300
Small model, output	300M	$0.80	$1.20	$360

The invoice totals $2,460 against $1,640 of hypothetical model-provider cost, leaving $820, or 33% of billed revenue, before other serving, infrastructure and support costs. The markup keeps this provider-cost spread constant only if the price updates with the actual model and rate used. A fixed price per request can be simpler for buyers, but you must monitor its margin as routing and provider prices change. See how to bill for AI API usage.

Usage-based billing examples by industry

The unit changes by product, but the design test stays the same: can the customer see the activity and explain the charge?

Product	Possible metric	Question to answer before pricing it
AI application	Tokens, requests or completed tasks	Does the buyer understand the unit, and how does model choice affect cost?
API platform	Calls, often by endpoint	Are retries, errors and cached responses billable?
Cloud or data platform	GB stored, data transferred or compute-hours	How is quantity sampled and attributed to an account?
Payments platform	Transaction count or payment volume	Which transaction states and refunds change the fee?
Communications platform	Messages or minutes by destination	Which provider events are authoritative for delivery and duration?
B2B SaaS	Active users, records or workflows	Does the unit reflect customer value more clearly than a seat?
Utilities, telecom or mobility	kWh, data, minutes or distance	Which meter and tariff determine the bill?

These are possible choices, not claims that every company in a category uses the same model. For actual packaging patterns, see usage-based pricing examples.

When does usage-based billing make sense?

Use a usage metric when it reflects value customers recognize or a material cost you incur, and when customers can understand why their bill moved. API calls, compute, storage and transactions often meet that test. A seat or flat tier may work better when value follows the number of people using the product, usage is hard to predict, or the buyer needs a fixed budget. Some products need both.

A lower entry price can make it easier to try the product, and revenue can expand as customers use more. Neither outcome is automatic. A metric that customers cannot forecast can slow a purchase, and revenue tied to usage will fall when usage falls. If provider cost rises faster than your price, usage growth can compress margin.

Question to settle	Owner and decision
What is the customer paying for?	Product and Sales: choose a metric buyers can connect to value
What is included and what happens next?	Product and Finance: define allowance, overage, credits or commitment
Can customers forecast and control spend?	Product and Engineering: expose current usage, alerts and a clear cap policy
Can we reproduce the invoice?	Engineering and Finance: agree on event IDs, timestamps, price versions and reconciliation

A soft cap warns or invoices while work continues. A hard cap requires your application or gateway to stop the billable action. Choose deliberately: shutting down a production workload to enforce a budget can be more costly to the customer than overage.

How to implement usage-based billing

Build the first plan around one billable metric. Write down the unit, counting rule, included quantity, rate, billing period and treatment of late events. Then replay historical usage through the proposed plan. Compare the resulting bills with what your largest, smallest and most volatile customers would expect.

Instrument the product. Send one event per billable action with a stable event ID, customer or subscription ID, metric code, usage timestamp and properties used for pricing. Keep an event ledger that can answer which action produced a charge. Deduplicate retries, and decide what happens when an event arrives after invoice finalization.

Test the commercial rules. Run invoices for a customer just below and just above every tier boundary. Test a midcycle plan change, credit exhaustion, a failed payment, a refund, and a contract with a custom price. Show the resulting invoice to someone who did not build the plan. If they cannot explain it, customers will struggle too.

Close the finance loop. Reconcile metered quantity to rated charges, invoice lines, payments and the accounting export. Decide when a price version takes effect and retain the old version so past invoices can be reproduced. Finance owns the revenue recognition policy under the applicable standard; the billing system supplies the underlying records. See usage-based revenue reconciliation.

How to choose usage-based billing software

You can build the meter and rating logic, or use a usage-based billing platform. The useful vendor test is a replay of your own data and exceptions, not a checklist of supported model names:

1. Events: What happens to a duplicate, a late event and a correction after invoice finalization? Can the system handle your peak ingestion rate?
2. Prices: Can it combine the models and contract terms you need, including filters by model or region, allowances, credits and commitments? Can you reproduce an old invoice after changing a price?
3. Customer controls: How fresh is the current-usage API? Can your product show a balance and alerts? Which system enforces a hard cap?
4. Finance: Can a reviewer trace an invoice line to events, credits and a price version? How do invoices, payments and accounting records reconcile?
5. Operations: What is included in your tier, what requires custom work, and what changes if you self-host? Self-hosting gives deployment control but adds operating work. See self-hosted versus cloud billing.

Metered billing software versus a full billing platform

Metering software counts and aggregates usage. A billing platform also applies prices, credits and contract terms, produces invoices and connects to payment and finance systems. Check whether both use the same event ledger; two competing quantities will create invoice disputes. Open-source software can give teams deployment control and inspectable logic, while self-hosting adds operating work. Compare the actual capabilities and costs of each option.

What changes for AI companies?

AI products add a specific test: an event may need the model, input and output token counts, cached tokens, provider and customer contract. A single blended price can hide changing provider cost. A provider-cost markup is one option, but it does not account for every serving, support or infrastructure cost. See how to bill for AI API usage.

How Lago handles usage-based billing

Lago is an open-source billing platform. You can self-host the free and open-source product or run on Lago Cloud. Your product sends events in Lago's documented format (illustrative values):

{
  "transaction_id": "api_20261008_acct42_search_000731",
  "external_subscription_id": "sub_acct42",
  "code": "api_calls",
  "timestamp": 1791460800,
  "properties": {
    "endpoint": "/v1/search",
    "region": "us-east-1",
    "status_code": 200
  }
}

Lago deduplicates on transaction_id, so a re-sent event is billed once, and assigns events to billing periods by timestamp. The code maps to a billable metric using one of the aggregation types above. Events arrive through the REST API or, at higher volume, through streaming and batch pipelines.

A plan combines a subscription fee with usage-based charges on the standard, graduated, package, volume, percentage, graduated percentage or dynamic models. Charge filters set a different rate per property value, such as region or model.

[[SCREENSHOT: Lago plan with fixed fee + usage charges]]

Your product can read current usage for the open period through the API. Wallets hold prepaid and free credits, with recurring top-ups on an interval or a balance threshold. Lago connects to payment providers natively or through a custom integration.

Some capabilities described here depend on plan or deployment: minimum commitments, progressive billing, alerts, real-time wallet balances, automatic dunning, invoice grace periods, and native CRM and accounting integrations. Check current pricing and the relevant docs for availability. Lago's revenue recognition is documented as an alpha premium feature; finance remains responsible for its accounting policy.

Start with the event ingestion guide, or book a demo to walk through your own pricing.

What changes for AI products?

AI products can shift work between models, cache responses and produce very different provider costs for the same customer-facing task. Charging for every input and output token gives a close cost signal, but may give buyers a bill they cannot predict or connect to an outcome. Charging per completed task is easier to understand only when the task and its completion can be defined and verified. Many teams use a base fee, an included allowance or credits to give buyers a budget while they learn actual usage.

The decision is operational as much as commercial. Keep the underlying model, token counts and task ID in the event record even if the customer sees a simpler unit. That lets you test whether the price still covers delivery cost and explain a disputed bill. For an AI product, the right first metric is the one buyers understand and your systems can measure consistently.

Design the pricing before you automate the invoice. The usage-based pricing playbook helps teams choose a billable metric, included usage, overage and prepaid or postpaid rules.

Usage-based billing FAQs

What does usage-based billing mean?

It means part or all of a customer's bill depends on measured consumption in a billing period. The business defines a billable unit, records and aggregates usage, applies the contracted rate and invoices the result. A recurring fee may sit alongside the usage charge.

Can you give me an example of usage-based billing?

An API platform charges a $500 monthly fee that includes one million calls, then charges for calls beyond that allowance. In the illustrative plan above, 7.2 million calls produce a $2,650 invoice with graduated overage. Volume-priced overage produces $2,050 for the same usage.

Can I bill customers based on usage?

Yes, if the product can measure an agreed billable unit and your contract explains how it is priced. Send events with stable IDs and timestamps, aggregate them by customer and period, apply the plan, and show the calculation on the invoice. Test corrections and late events before launch.

What is consumption-based billing?

Consumption-based billing is another name for charging for measured use, especially resources such as compute, storage, data or tokens. The term often appears with prepaid balances and committed spend. The underlying work is the same: capture, aggregate, price and invoice the use.

Is pay-as-you-go the same as usage-based billing?

Pay-as-you-go is one usage-based model with no recurring minimum: customers pay for the units they use. Usage-based billing is broader. It also covers a base fee with overage, prepaid credits and minimum commitments. Confirm the commercial rule rather than relying on the label.

What is the difference between metered billing and usage-based billing?

Metered billing stresses the counting step: a meter turns events into a quantity such as calls or GB-hours. Usage-based billing includes that meter plus the pricing rules, credits, invoices and collections. In practice, teams often use the terms interchangeably.

What is the difference between usage-based pricing and usage-based billing?

Pricing chooses the metric, rate and package. Billing implements those choices against actual customer usage. For example, pricing may set different rates for input and output tokens; billing must count each correctly, apply the right plan version and produce the invoice.

How do you calculate a usage-based bill?

Aggregate billable units for the period, subtract any included allowance, and apply the contracted per-unit, graduated, volume, package or percentage rule. Then add fixed fees and other charges, apply credits and discounts under the contract, and calculate tax. The tier rule can materially change the total.

What is a billable metric?

A billable metric defines what is counted and how. An API-call metric might count request events; a token metric might sum a quantity on each event; active users might require a distinct count. The definition also needs rules for retries, errors and the billing period.

How do you prevent bill shock with usage-based pricing?

Show customers the current quantity, the applicable price and how close they are to an allowance or budget. Send alerts before thresholds are crossed. If you promise a hard cap, enforce it in the product or gateway and explain which work will stop.

How does revenue recognition work for usage-based billing?

Invoicing and revenue recognition answer different questions. Usage events, invoice lines, credits and contract terms give finance the evidence to apply its policy under ASC 606 or IFRS 15. Treatment of prepaid amounts and variable consideration depends on the contract; a billing platform does not set that policy.

What is the best usage-based billing software?

The best fit depends on your event volume, contracts, deployment needs and finance workflow. Replay real data through candidate systems, including duplicates, late events, credits, tier boundaries and plan changes. Ask whether an invoice line can be traced back to the event and price version that produced it.

How do you bill for AI and LLM usage?

Record the customer, model and relevant input, output and cached token quantities for each request. You can charge per token, request, credit or verified task, depending on what buyers understand and what you can measure. Compare the resulting revenue with provider and other delivery costs.

Related resources

• What is metered billing?
• Credit-based pricing
• Hybrid pricing models
• AI pricing models
• Usage-based billing software by Lago
• Lago documentation