Building a Usage-Based Billing System for SaaS
Last updated:
What usage-based billing is, why it is growing fast, and how to architect the metering, aggregation, rating and invoicing pipeline behind it — plus build vs buy and the pitfalls to avoid.
TL;DR
- Usage-based billing charges customers for what they consume — it aligns cost with value and lowers the barrier to entry
- The system has four layers: metering, aggregation, rating, and invoicing
- For most teams the smart move is to buy invoicing and payments and build only the product-specific metering
- The hard problems are real-time accuracy, idempotency, proration, and dispute resolution
- Make every charge traceable back to raw events or you will lose disputes and trust
What Usage-Based Billing Is — and Why It Is Growing
Usage-based billing charges customers in proportion to what they actually consume: API calls, messages, compute minutes, gigabytes stored, rows synced, or workflows run. Instead of a fixed monthly fee, the bill reflects real activity, so a quiet month costs less and a busy month costs more. This is the model behind most modern infrastructure, API, and data products, and it is spreading into application SaaS because it removes the awkward conversation where customers pay for capacity they never use.
The growth is driven by buyer psychology and competitive pressure. Across the USA, UK, Canada and Europe, buyers increasingly expect to start small, pay only for value received, and scale spend as they grow. That low-friction entry improves conversion, while expansion revenue compounds as customers consume more. The catch is that the elegance of the pricing hides real engineering complexity — you are now responsible for measuring, pricing, and invoicing activity accurately and in near real time.
The Architecture: Four Layers
Every usage-based billing system, regardless of stack, is built from the same four layers. Get the boundaries between them right and the system stays maintainable; blur them and every pricing change becomes a migration.
Metering — Capture Raw Events
- Emit a usage event for every billable action, with a customer ID, timestamp, quantity, and a unique idempotency key
- Push events through a durable queue or stream so nothing is lost if a downstream service is down
- Deduplicate on the idempotency key — events will arrive more than once
- Store the raw event log immutably; it is your source of truth for every dispute
Aggregation — Roll Events Into Counters
- Collapse raw events into usage counters per customer, per metric, per billing period
- Support sum, max, unique-count and last-value aggregations — different metrics need different math
- Handle late-arriving events by re-aggregating the affected window, not by ignoring them
- Expose current-period usage to customers in-app so the invoice is never a surprise
Rating — Apply the Price Book
- Convert aggregated usage into charges using your pricing rules: flat, per-unit, tiered, or volume
- Apply included allowances, free quotas, minimums, and caps before producing the charge
- Keep the price book versioned and decoupled from code so pricing changes don't require a deploy
- Make rating deterministic — the same usage must always produce the same charge
Invoicing — Combine, Tax, and Collect
- Combine usage charges with any base subscription fees into a single invoice
- Apply tax — VAT in the UK and Europe, sales tax in the USA, GST/HST in Canada
- Collect payment, then run dunning and retries on failures
- Generate an itemised, auditable invoice the customer can reconcile against their own data
Build vs Buy
You almost never want to build all four layers yourself. The pragmatic split is to buy the invoicing, tax and payments layer, use or buy a metering tool if your volume is high, and build only the thin product-specific glue that emits events. Here is how the common options compare.
| Approach | Good For | Watch Out For |
|---|---|---|
| Stripe Billing (metered) | Teams already on Stripe; standard metrics | Complex tiered rating gets awkward |
| Dedicated metering platform | High event volume; flexible rating | Another vendor and integration to own |
| Build metering, buy invoicing | Most scaling SaaS — the sweet spot | You own correctness of the event pipeline |
| Build everything | Unusual rating needs at large scale | Tax, dunning and compliance burden |
The Pitfalls That Bite Teams
Real-time metering pressure
Customers expect their in-app usage counter to be accurate to the minute, but exact real-time aggregation at scale is expensive. Decouple a fast approximate counter for display from the authoritative end-of-period aggregation used for billing.
Disputes and missing audit trails
If a customer questions a charge and you cannot trace it back to specific events, you lose the dispute and the relationship. Keep the raw event log immutable and let support drill from invoice line to underlying events.
Proration on mid-cycle changes
Upgrades, downgrades and cancellations mid-period mix subscription proration with metered usage, and getting the boundary wrong over- or under-charges. Define the proration rules explicitly and test every transition with fixtures.
Duplicate and late events
Networks retry and queues replay, so the same event arrives twice and some arrive after the window closes. Without idempotency keys and a re-aggregation strategy, you silently over-bill or under-bill.
Implementation Steps
If you are weighing how this fits your roadmap and pricing model, our SaaS development team builds metering and billing pipelines for products across the USA, UK, Canada and Europe, and you can see the full scope of what we deliver on our services overview.
Frequently Asked Questions
What are the core components of a usage-based billing system?
A usage-based billing system has four layers: metering, which captures raw usage events; aggregation, which rolls those events into counters per customer and period; rating, which applies your price book to produce charges; and invoicing, which combines charges into an invoice and collects payment. A reliable event pipeline and an idempotent ingestion path tie them together.
Should I build usage-based billing or use Stripe Billing?
For most teams, buy the invoicing and payments layer with Stripe Billing or a dedicated metering platform, and build only the part that is specific to your product — the event capture and aggregation. Building the full stack from scratch, including tax, dunning and compliance across the USA, UK, Canada and Europe, is rarely worth it until you have unusual rating needs at scale.
What is the hardest part of usage-based billing?
Accuracy under real-world conditions. Events arrive late or duplicated, customers dispute charges, and proration on mid-cycle plan changes is easy to get wrong. The hardest engineering problem is making metering idempotent and auditable so that the number on the invoice can always be traced back to the underlying events.
Need a Usage-Based Billing System Built Right?
We design and build metering, rating and invoicing pipelines for SaaS companies across the USA, UK, Canada and Europe — accurate, auditable, and ready to scale. Book a free strategy call and we will sketch your architecture.
Book a Free Strategy CallPrefer to chat? Message us on WhatsApp