Usage-based billing means customers pay for what they actually consume — API calls made, seats active, gigabytes stored, messages sent — rather than a flat monthly fee regardless of use. It has been standard in infrastructure products for years (AWS charges by the second, Twilio charges per message), and it is now spreading fast into application-layer SaaS products. The reason is straightforward: it aligns your pricing with the value customers receive, which lowers the friction to get started and rewards you as customers grow. The implementation, however, is substantially more complex than flipping a switch in Stripe.
Why Usage-Based Billing Is Harder Than It Looks
Flat subscription billing is simple: customer is on a plan, you charge monthly, done. Usage-based billing introduces three problems flat billing does not have. First, you need to meter consumption accurately in real time — every API call, every file processed, every active seat attributed to the correct customer account even at high volumes across multiple backend instances. Getting this wrong compounds into billing disputes. Second, you need to aggregate and rate those meters: raw event counts bucketed by period, potentially across multiple dimensions (seats × storage × API calls), priced against rules with free tiers, volume discounts, and overages. Third, revenue recognition becomes materially more complex — usage-based revenue recognizes only when consumption occurs, not when you invoice, and your finance team and auditors will have pointed opinions about how you track it.
The Metering Layer: What You Absolutely Must Build Yourself
No billing vendor can tell you what constitutes a billable event in your product. That logic lives in your application, and you need to instrument it correctly before any billing engine can help you. The instrumentation layer is the one thing you cannot outsource.
A metering event is a structured record emitted whenever something billable happens:
- customer_id — which tenant or billing account
- event_type — what happened (api_call, document_processed, active_user, etc.)
- quantity — how much (1 call, 2.4 MB, 3 users)
- timestamp — when it happened, in UTC
- idempotency_key — a unique identifier that prevents double-counting if the event is delivered more than once
These events need to be emitted to a durable queue (Kafka, SQS, Redis Streams) rather than written directly to a billing database. Direct writes fail silently under load; a queue gives you retry guarantees and lets you process events asynchronously without slowing down the user-facing code path. The idempotency key is non-negotiable — in any distributed system, events will occasionally be delivered more than once, and double-billing a customer is worse than under-billing them.
What the Billing Engine Needs to Do
Once events are flowing reliably, a billing engine consumes them and handles:
- Aggregation of raw events into billable quantities per billing period per customer
- Application of pricing rules (flat rate per unit, volume tiers, committed minimums, credits)
- Invoice generation at period end (or in real time for pay-as-you-go models)
- Charge collection via payment processor (Stripe, Braintree, Adyen)
- Failed payment handling and dunning sequences
- Customer-facing usage dashboards so customers can predict their own bills
Building all of this from scratch is a significant engineering commitment — typically three to six months for a team that has done it before. This is why the vendor landscape for usage-based billing infrastructure has grown substantially.
The Vendor Landscape: What Each One Actually Does
| Vendor | Best For | Pricing Model | Key Limitation |
|---|---|---|---|
| Stripe Billing (Meters) | Teams already on Stripe, simpler metering | 0.5–0.8% of billing volume | Less flexible for complex tier logic |
| Orb | Product teams needing flexible pricing models | Percentage of billing volume | Newer; smaller ecosystem |
| Metronome | Developer tools / infrastructure companies | Percentage of billing volume | Higher minimum commitment |
| Lago (open source) | Teams wanting self-hosted billing engine | Free (self-hosted) or SaaS tier | Requires operational maintenance if self-hosted |
| Stigg | Entitlement and feature flag layer | Per-customer pricing | Not a full billing engine; pairs with Stripe |
For most SaaS teams at the MVP-to-early-growth stage, the pragmatic choice is Stripe Billing with its native Meters feature for simpler use cases, or Lago (self-hosted or cloud) for teams that need more pricing flexibility without percentage-of-revenue fees. Orb and Metronome make sense once you are processing significant billing volume where a custom contract with negotiated rates is available.
Revenue Recognition Pitfalls You Need to Anticipate
This is the area most engineering teams do not think about until the finance team or an auditor raises it. Under ASC 606 (US GAAP) and IFRS 15, revenue is recognized when the performance obligation is satisfied — which for usage-based billing means when the customer consumes the service, not when you invoice them.
The practical implications:
- If you collect a minimum commitment upfront and customers draw it down over the year, you cannot recognize all of it on day one
- Credits issued to customers (for outages, goodwill, referrals) reduce recognized revenue in the period they are used, not issued
- Annual prepaid usage contracts require careful deferred revenue tracking
- Refunds and reversals need to be reflected in the same period as the original recognition if material
None of this requires an accounting degree to implement — but it does require that your billing system tracks consumption by period with sufficient granularity that your accounting software or ERP can produce correct revenue numbers. Build the reporting hooks into your billing pipeline from the start; retrofitting them after the fact when a Series A investor wants clean financials is painful.
Customer-Facing Usage Dashboards: Often Neglected, Always Needed
Usage-based billing creates billing anxiety for customers who cannot predict their next invoice. The antidote is a clear, accessible usage dashboard that shows current period consumption, projected end-of-period cost based on current trajectory, and historical usage by period. This is not a nice-to-have — it is a retention feature. Customers who understand their usage patterns churn significantly less than those who receive a surprise invoice each month.
A basic usage dashboard needs: current period usage vs. any included allowances, a running estimated charge for the period, a simple chart of usage over the last 6-12 billing periods, and a way to set usage alerts so customers get an email when they hit 80% of an allowance or budget threshold.
Migrating Existing Customers From Flat to Usage-Based
Springing usage-based billing on existing customers without notice destroys trust. The standard approach: announce 60–90 days in advance, offer a grandfather period (6–12 months on flat pricing), provide 90 days of historical usage data so customers can estimate their new bill, and make the opt-in fully self-service. No forced migrations.
Frequently Asked Questions
Should every SaaS product move to usage-based billing?
No. Usage-based billing works best when there is a clear, measurable unit of value that customers recognize and that correlates with the benefit they receive. It works poorly when usage is highly variable and customers cannot predict their bills, when the consumption unit is invisible to the customer (they cannot influence or understand it), or when your customer base consists primarily of budget-constrained buyers who need predictable monthly costs. Per-seat pricing remains the right model for many collaboration and productivity tools where the value scales with team size rather than raw consumption.
How do you prevent customers from gaming usage-based billing?
Gaming is a real concern — customers will optimize their behavior to minimize usage if the usage metric does not closely match the value they receive. The best defense is choosing a billing metric that is genuinely hard to separate from value. API calls are easy to minimize artificially; "documents processed and acted upon" is harder to game. Also, rate limiting and quotas at the infrastructure level prevent individual tenants from running up charges accidentally or maliciously, and automated anomaly detection on per-customer usage patterns catches unusual spikes worth investigating before they become disputes.
What is the difference between a usage meter and an entitlement?
A usage meter counts consumption — it increments each time a billable event occurs. An entitlement is a rule that governs what a customer is allowed to do — they are on a plan that includes 10,000 API calls per month, after which calls are blocked or charged at an overage rate. Meters and entitlements work together: the meter tracks raw consumption, the entitlement system compares it against the customer's plan and decides whether to allow or throttle the action. Tools like Stigg and LaunchDarkly specialize in the entitlement layer on top of whatever billing system you use for the meter.
How long does it take to implement usage-based billing on an existing SaaS product?
A straightforward implementation — adding metering to one or two billing dimensions, integrating with Stripe Meters or a vendor like Lago, building a basic usage dashboard — takes four to eight weeks for an experienced team. Complex implementations with multiple pricing dimensions, committed minimums, enterprise contract structures, and deep ERP integration for revenue recognition can take three to six months. The audit of what needs to be metered (the event taxonomy) is consistently the step teams underestimate; plan at least a week of careful analysis there before writing any code.
Need a partner for this? Mexilet offers SaaS development services and product engineering team.
If usage-based billing is on your roadmap and you are not sure whether to build it in-house or integrate a vendor, have a conversation with the Mexilet Technologies team. As an offshore software development partner with experience across SaaS billing architectures, we can help you choose the right approach for your stage, build the metering layer, and integrate whatever billing engine fits your pricing model — so your team stays focused on the product, not the plumbing.