Building a Usage-Based Billing System for SaaS

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. A quiet month costs less and a busy month costs more. This is the model behind most modern infrastructure, API, and data products. 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 and pay only for value received. They 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. Build only the thin product-specific glue that emits events. Here is how the common options compare.

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. You can see the full scope of what we deliver on our services overview.