Usage-Based Billing for SaaS: How It Works and How to Build It

Usage-based billing charges customers for what they actually consume during a billing period instead of a flat fee alone. Your product records billable events, a meter adds them up per customer, a price plan turns the totals into dollars, and an invoice goes out at the end of the cycle. The hard parts are choosing a metric customers understand and building a metering pipeline you can trust. I'm Hanad, a senior engineer who builds this kind of billing for founders, and this guide covers both.

Hanad Kubat

hanadkubat.com

Build billing your customers can trust

Hanad builds working software for founders, including SaaS products that need reliable usage metering, payment flows, and invoicing.

Explore software builds

Key Takeaways

Usage-based billing is three jobs: metering (counting events), rating (turning counts into money) and invoicing (presenting the bill and collecting payment).
The metric matters more than the rate. Pick one customers can estimate before signing up and verify afterward.
Most B2B SaaS products end up hybrid: a fixed base fee for predictability plus a variable usage component.
Bill shock and revenue variability are the main risks. Spending alerts, caps and prepaid credits are the standard answers.
Build the event pipeline first and keep it boring. Pricing can change later, but lost or duplicated events cannot be repaired cheaply.

What usage-based billing means in SaaS
Usage-based, subscription and hybrid compared
Choosing what to charge for
Pricing models you can build on a metric
How metering, rating and invoicing work
Benefits and risks
When usage-based billing fits your product
A practical order for building it
Perspective
Need usage-based billing built?
FAQ
Sources

What usage-based billing means in SaaS

The definition is simple. Stripe describes usage-based pricing as a model where customers pay based on how much they consume, such as gigabytes of storage or seats, rather than a flat monthly fee. It is common where usage varies widely, such as cloud computing and developer tools. You will also hear it called metered billing, consumption-based billing or pay-as-you-go.

The model works like an electricity bill. Salesforce's overview puts it this way: the system measures customer activity, converts it into charges, and bills at the end of each cycle. The measured thing can be credits, transactions or data volume, and the bill rises or falls with it.

Three familiar examples show the range. Stripe's examples page notes that OpenAI's API bills by tokens, with input and output priced separately by model tier. Twilio can bill per message or per voice minute. Snowflake bills by credits for compute, with storage priced separately per terabyte per month. Each charges for a different unit, which is the whole point: the unit is a product decision, not a billing detail.

Comparison of three SaaS usage billing units

Usage-based, subscription and hybrid compared

Subscription billing charges a fixed recurring fee for access no matter how much the customer uses. TechTarget's explainer frames usage-based billing as the opposite: the invoice varies with measured consumption.

Hybrid sits between them. Stripe describes hybrid pricing as combining a fixed recurring fee with a variable charge based on usage or another value driver. The fixed part gives you predictable revenue, and the variable part scales with the value the customer receives.

	Subscription	Usage-based	Hybrid
Invoice	Same every period	Varies with consumption	Base fee plus variable charge
Revenue predictability	High	Lower	Medium to high
Customer cost predictability	High	Lower without alerts	Medium
Barrier to entry	Plan price	Close to zero	Base fee
Build effort	Low	Highest (metering)	High

If you sell to businesses with a budget cycle, hybrid is usually the practical choice. Finance teams like a known floor, and you like a floor too. Pure pay-as-you-go suits products where usage truly swings, such as infrastructure, messaging and AI APIs.

Choosing what to charge for

This decision shapes everything downstream. Common metrics include API calls, data volume, active users, compute hours and transactions, as Tabs lists in its guide. NetSuite advises picking a value metric that is easy to measure, meaningful to customers and aligned with your cost of delivery.

There is a real trade-off. Thales explains that a metric tracking your infrastructure cost can be hard for customers to understand, while an outcome-based metric is more intuitive but harder to define, attribute and audit. Neither is free.

I use four checks before recommending a metric:

It scales with value. When the customer gets more out of the product, the number goes up.
A prospect can estimate it. If someone cannot guess their bill before signing up, they will hesitate to sign up.
The customer can see and verify the count. A usage dashboard is part of the product, not an extra.
It roughly tracks your costs. If every unit costs you more than it earns, growth will hurt you.

Some examples of what that looks like in practice:

A document-processing tool charges per page processed. It is easy to count and easy to estimate, and your OCR or LLM cost follows it closely.
A scheduling product for clinics charges per active provider per month. That is a seat metric, not usage, and it may be the better fit.
An AI feature charges per generated report instead of per token. Customers understand reports. Tokens are your cost, not their value.

The metric also becomes part of your positioning, so it is worth reading about how SaaS growth and marketing strategies connect to what you put on the pricing page.

Pricing models you can build on a metric

Once you have a metric, you choose how rates apply. Stripe's strategy guide describes three core structures:

Per-unit flat pricing: every unit costs the same.
Volume-tiered pricing: the per-unit price drops once total consumption crosses a threshold, and that lower price applies to all units.
Graduated pricing: each tier's rate applies only to the units inside that tier.

TechTarget adds pay-as-you-go (billed in arrears after counting units), overage (an included package with fees above a threshold) and hybrid, which it says is increasingly popular in SaaS but brings higher billing complexity.

A quick worked example makes the difference between volume and graduated pricing clear. Say the first 1,000 units cost $0.10 each and everything beyond costs $0.07. A customer using 1,500 units pays $100 plus $35, which is $135, under graduated pricing. Under volume pricing, all 1,500 units would bill at the lower rate. Graduated is easier to defend to customers, and volume is easier to explain in one sentence. Pick one and write the example on your pricing page.

How metering, rating and invoicing work

Stripe splits the mechanism into metering (counting at event level), rating (converting raw usage into a dollar amount) and invoicing (presenting the bill and collecting payment). In my builds I think of it as a six-step pipeline:

Emit. The product fires an event for every billable action, with a customer ID, a timestamp and a unique event ID.
Meter. Events are deduplicated and aggregated per customer and period.
Rate. The price plan is applied: tiers, included amounts, minimums.
Invoice. An itemized invoice shows consumption and rates.
Collect. Payment is taken, and failed payments are retried.
Reconcile. Finance records the revenue under its accounting policy.

NetSuite's walkthrough covers the same flow and adds a step I consider essential: validating charges for anomalies before invoices go out. Tabs notes that the product must emit usage events in real time, and that events are captured, deduplicated and stored before any billing logic runs.

Where these builds go wrong

The failures are rarely in the math. They are in the plumbing:

Duplicate events. A retry fires twice and the customer is billed twice. Every event needs an idempotency key.
Lost events. A queue drops a message during a deploy. Store events durably before you aggregate them.
Wrong aggregation. Monthly active users are a unique count, storage is usually the latest value at period end, and peak connections are a max. Using a plain count for all of them produces wrong invoices.
No audit trail. When a customer disputes a bill, you need to show the raw events behind the number.

Accounting matters too. Under ASC 606 and IFRS 15, usage-based revenue can be recognized in the period consumption occurs or ratably across an annual contract term, so talk to your accountant before you design annual commitments with usage components.

Benefits and risks

The upside is real. Stripe's pay-per-use guide lists a lower barrier to entry, faster time to first value, built-in expansion and reduced forced churn as typical benefits. Customers who start small can grow without hitting an artificial plan wall, and your revenue follows their success.

The same guide is clear about the other side: revenue variability, customer bill shock, metering-accuracy risk, technical and financial overhead, and customer cost anxiety. Stripe's billing models guide also notes that revenue can be unpredictable and customers may need more education.

These are design problems with known answers:

Bill shock: usage dashboards, threshold alerts and optional spending caps.
Revenue variability: a hybrid base fee, prepaid credits or committed-use discounts.
Metering accuracy: idempotent events, durable storage and a reconciliation job that compares totals.
Customer anxiety: a pricing calculator on the pricing page and plain-language invoices.

Stripe's guidance on customer planning recommends spending caps, prepaid credits and discounts so customers can start small and scale. I treat those as launch requirements, not later improvements.

When usage-based billing fits your product

It fits when usage varies a lot between customers, when your marginal cost per unit is meaningful (as with LLM calls, SMS or compute), and when customers can see and verify the unit. It is a weaker fit when the product delivers value through a fixed workflow used by a fixed team. A seat-based plan is simpler there, and I will say so if that is what your product needs.

For AI features in particular, usage pricing is close to unavoidable, because every request costs you real money. If you add an LLM feature to a flat-fee plan without limits, one heavy customer can turn a plan unprofitable. Included allowances plus overage, or credits, are the common solutions.

If you are still working out the broader model, my guide to revenue model examples for B2B SaaS compares the options, and the metrics worth tracking at each stage will tell you whether usage data supports the model you chose.

A practical order for building it

If you are starting from nothing, this is the sequence I follow:

Define the metric and write down the price plan in plain language, including one worked invoice example.
Build the event pipeline first. Emit events, deduplicate, store durably, and expose a per-customer usage view.
Connect rating and invoicing through your payment provider's metered billing features, rather than writing invoice logic by hand.
Add guardrails: alerts, caps, and a way to void or adjust an invoice.
Run a shadow period. Compute invoices without charging and compare against your expectations before turning real billing on.
Document it, so the next developer understands how an event becomes a line on an invoice.

I keep the stack deliberately common: TypeScript, Node, SQL and Stripe, so anyone can pick it up later. If you want the payments foundation first, see how to set up SaaS payments and my approach to Stripe billing for SaaS.

Perspective

Most founders ask me which pricing model to pick. I think the better question is whether they can count the thing they want to charge for, and whether a customer can check my count.

I have spent ten years in engineering, including systems work for Deutsche Bahn, BMW and the Bundesrechenzentrum. The lesson from that work is the same one billing teaches: the unglamorous layer decides everything. A beautiful pricing page on top of an unreliable event pipeline produces disputes, not revenue.

That is why I build billing as a small, readable system: events in, an aggregated meter, a rated invoice, and a clear audit trail. It is written in common technology, you own the code from the first commit, and a fixed scope means you know the price before I start. I would rather hand you something a future developer can read in an afternoon than something clever.

If an off-the-shelf billing tool already covers your case, I will tell you that too.

Hanad Kubat

Need usage-based billing built?

I build the first real version of SaaS products, including payments and metered billing, as a fixed-price engagement. Builds start from €12,000, take two to four weeks, and you own the code from the first commit. I work as a single engineer, so the person you talk to is the person who writes the code. See what I build and how to start.

FAQ

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

They are the same thing under different names. Both charge customers for measured consumption in each billing cycle, and you will also see consumption-based billing and pay-as-you-go used for the same model.

Is usage-based billing better than a subscription?

Not automatically. It suits products where consumption varies widely and costs you money per unit, while subscriptions suit predictable use. Many B2B products combine the two with a base fee plus usage, which gives both sides a predictable floor.

How do I stop customers from getting surprise bills?

Show them their usage in real time, send alerts at spending thresholds, and offer optional caps or prepaid credits. A pricing calculator before signup also helps, because customers can estimate their cost before committing.

What should I build first?

Build the event pipeline: unique event IDs, deduplication and durable storage. Pricing rules can change in a week, but billing errors from lost or duplicated events are hard to correct after customers have been invoiced.