Pricing & Monetization
Enterprise SaaS Billing: What You Actually Need (2026)
Anh-Tho Chuong • 3 min read
May 5, 2025
/7 min read
How to Build a Usage-Based Billing System (Without Outgrowing It)
Over 60% of AI and SaaS companies now use some form of usage-based or hybrid pricing. Most of them hit the same wall: the billing system they built for their first 100 customers doesn't work for their first 1,000.
This isn't a scaling problem in the abstract sense. It's a specific set of engineering and operational failures that happen in a predictable sequence. Metering gaps that create revenue leakage. Rating logic that breaks when pricing models change. Invoice generation that can't keep up with event volume. A customer-facing usage dashboard that doesn't exist.
This covers what it actually takes to build a usage-based billing system that scales, the architecture decisions, the operational trade-offs, and what breaks first when you get it wrong.
The metering problem
Metering is where most homegrown billing systems fail first.
The requirement sounds simple: capture every usage event as it happens. Every API call, token generated, compute second consumed, document processed. Record it. Make it auditable.
The complexity is in the edge cases. Events that arrive late because of network delays. Duplicate events from retry logic. Events that need to be attributed to the right customer across multi-tenant infrastructure. Usage that happens during a billing period transition at midnight. None of these are hard problems individually. Together, they're the reason billing engineers have grey hair.
Three properties a metering system needs to get right: completeness (no events dropped under load), accuracy (deduplication, late arrival handling), and auditability (customers can verify their own bill from first principles). Miss any of these and you get revenue leakage, billing disputes, or both.
A concrete example of the architecture that works: events stream into an ingestion layer in real time. The ingestion layer handles deduplication and validates that each event has a customer ID, timestamp, and metric. Events land in a durable store. An aggregation layer rolls them up by billing period — tokens this month, API calls this week, compute hours today. The rating engine applies pricing rules to the aggregated data and produces billable amounts. The invoice engine assembles line items and generates the invoice.
That's five distinct layers before you get to payment collection. Each one has failure modes.
The four consumption-based pricing patterns
Not all usage-based billing is the same. Four patterns cover 90% of what AI and SaaS companies actually ship:
Pure pay-as-you-go. Charge per event, no floor. Customers love it — zero commitment, pay only for what you use. Revenue is hard to predict. Works best for developer tools and APIs where usage is highly variable and customers are evaluating before committing. OpenAI's token pricing is the canonical example.
Hybrid: subscription plus overage. A flat base covers a defined usage allocation. Consumption above that accrues variable charges. This is where most mature AI companies land. The subscription floor gives you predictable ARR. The usage component captures upside when customers grow. The Stripe survey found companies on hybrid models report 21% higher median growth rates than pure-play models.
Prepaid credits. Customers buy credits upfront and draw down over time. Particularly good for AI companies: you get cash upfront, customers get spending certainty. The billing system needs to track credit drawdown in real time, alert the customer at 80% consumed, and auto-renew or block usage at zero. This is harder to implement than it sounds — credit burndown logic has a lot of edge cases around concurrent usage and rollover policies.
Committed spend with true-up. Enterprise customers sign a minimum spend agreement. Usage is tracked across the period. At period end, if usage exceeded the commitment, an overage invoice goes out. This is the contract-led model for large customers. Requires the billing system to project usage mid-period so sales can intervene before a surprise invoice lands.
The pattern to avoid: starting with pure pay-as-you-go, then scrambling to add a subscription floor when the CFO needs predictable ARR. Design for hybrid from day one. Retrofitting a subscription layer onto an event-only system is a significant engineering project.
The Stripe-Metronome acquisition changed the market
In January 2026, Stripe acquired Metronome — the usage-based billing platform used by OpenAI, Fly.io, Confluent, and Anyscale. This is the most significant event in the UBB infrastructure market in years.
What it means in practice: Stripe now owns the highest-profile UBB platform and is building a unified monetization stack (metering, rating, invoicing, payments, revenue recognition, tax) in one system. For companies already on Stripe for payments, this is a compelling consolidation play.
The trade-off is full ecosystem lock-in. Metronome routes all payments through Stripe. If you want multi-processor strategy — Stripe for consumer, Adyen for enterprise, Braintree for specific geographies — you're working against the architecture.
For companies that need payment-processor agnosticism, or that have compliance requirements that make closed-source billing infrastructure a non-starter, this is relevant context. Lago is open-source and payment-processor agnostic. That's an architectural difference, not a feature marketing claim.
Build vs. buy: the real calculation
Most teams underestimate what a usage-based billing system actually requires to be production-ready.
It's not metering plus Stripe. It's event ingestion, deduplication, aggregation, a rating engine, invoice generation, tax calculation, payment collection, dunning (for failed payments), revenue recognition, and a customer-facing usage dashboard. Building all of that in-house typically takes 6–9 months and a dedicated engineer to maintain. Every pricing change requires an engineering sprint.
Companies that build it themselves are usually trying to solve a real problem: billing logic is deeply product-specific, and generic platforms don't always fit. That's legitimate. But control doesn't require building every layer. The question is which layers you actually need to own.
Three paths:
Buy a SaaS billing platform (Chargebee, Maxio). Fast to deploy, well-documented, good for subscription-heavy models. Usage-based complexity hits limits at scale with multidimensional pricing — you'll find yourself writing workarounds in the integration layer. Chargebee's pricing gets expensive as you scale event volume.
Stripe + Metronome. The most well-funded option now that Stripe owns Metronome. OpenAI and Fly.io ran on Metronome for good reason — it handles complex rate cards and credit-burndown well. Full Stripe ecosystem lock-in. If that's where you already live, this is the path of least resistance.
Open-source infrastructure (Lago). Deploy in days, not months. Full code visibility — you can read the rating logic, audit the metering, customize the aggregation. Runs on your own infrastructure for compliance or data residency requirements. Payment-processor agnostic. The trade-off: you own more of the operational surface. That's a feature for the right team, a burden for the wrong one.
The honest build vs. buy signal: if billing is a constant engineering bottleneck — pricing changes take weeks, new models require new infrastructure — you're building when you should be buying. If you've already bought a platform and you're writing more code to work around it than you'd write to replace it, you're buying when you should be building on something more flexible.
What breaks at scale
The failure modes are predictable. In rough order of when they appear:
Metering gaps are the first revenue leak. An event type that wasn't instrumented. A retry that created a duplicate. A late-arriving event that fell outside the billing window. Individually minor. Compounding over time, companies on usage-based models lose 2–5% of ARR to metering errors. At $10M ARR, that's $200K–$500K a year disappearing silently.
Rating complexity breaks when pricing models change. The rating engine that handled one metric cleanly starts to crack when you add dimensional pricing (different rates for different models, geographies, customer tiers). Homegrown engines are rarely designed for this. The fix is usually a rewrite.
Invoice generation stops scaling when customer counts grow and billing cycles overlap. Generating 10,000 invoices simultaneously on a batch job that wasn't designed for it creates timeouts, partial failures, and customer-visible errors.
Dunning logic — the automated process for recovering failed payments — is almost always an afterthought in homegrown systems. It's critical. Industry data shows 5–9% of subscription payment attempts fail in any given billing cycle. Without a proper retry sequence, that's involuntary churn.
Revenue recognition becomes a finance problem at Series B and beyond. Usage-based revenue recognized at the wrong time distorts ARR, MRR, and churn calculations. ASC 606 and IFRS 15 have specific requirements for variable consideration. Most billing engineers don't think about this until the auditors ask.
The implementation architecture
A production-ready usage-based billing system has these layers working in sequence:
Event ingestion. Accept usage events via API or event stream. Validate, deduplicate, timestamp. Store durably before any processing. This layer needs to handle your peak event volume without dropping events , design for 10x your expected load.
Aggregation. Roll up raw events into billable units by customer, billing period, and metric. This is where late-arriving events need to be handled , a 24-hour grace window is standard before a period is considered closed.
Rating engine. Apply pricing rules to aggregated usage. This is the heart of the system. It needs to handle tiered pricing (first 1M tokens at $0.002, next 10M at $0.001), volume discounts, multi-dimensional rates, and currency conversion. Changes to this layer need to be version-controlled , a pricing change that applies retroactively is a support disaster.
Invoice assembly. Generate line items from rated usage. Apply credits, discounts, and manual adjustments. Produce an invoice that a customer can read and verify. Customer-facing usage breakdowns are not optional, opaque invoices create disputes.
Payment collection. Charge the customer. Handle failures with a retry sequence. Log every attempt. Trigger dunning workflows for persistent failures.
Revenue recognition. Recognize revenue when earned, not when invoiced. For usage-based models, this typically means recognizing daily or weekly as usage is consumed, with a true-up at invoice close.
Each layer needs to be independently testable. Billing bugs discovered in production are expensive, in engineering time, customer trust, and sometimes refunds.
Getting started
Lago is open-source billing infrastructure built for usage-based and hybrid pricing. The rating engine handles tiered pricing, prepaid credits, and multi-dimensional models. It deploys on your own infrastructure, connects to any payment processor, and gives you full code visibility into the billing logic.
Mistral, Groq, and Together.ai use it. Deploy the open-source version to test it against your own data. Book a demo to talk through your specific pricing model and event volume.
If you're evaluating whether to build or buy, the Lago documentation is the fastest way to understand what the platform covers and what you'd still need to build on top of it.
