Usage-Based Billing System: Build It or Buy It?

A usage-based billing system can work well with one product and a handful of customers. The harder test comes when pricing changes, usage arrives late, and customers need to understand every invoice line.

The difficult cases are concrete: missing or duplicate events, pricing rules that change, invoice jobs that fail, and customers who cannot see how their charges were calculated. Each creates extra work for engineering, finance and support.

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 often the first hard part of a homegrown billing system.

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 common patterns are:

Pure pay-as-you-go. Charge for a measured unit without a fixed floor. This can make early adoption easier for API products, but both buyer spend and seller revenue vary with consumption.

Hybrid: subscription plus overage. A base fee covers an included allocation. Consumption above that becomes a variable charge. This gives the company a revenue floor while customers can grow beyond their initial allowance.

Prepaid credits. Customers fund a balance upfront and draw it down as they use the product. Define how credits are consumed, expire, roll over, and trigger notifications. If service must stop at zero, the application or gateway needs to enforce that limit; a billing balance or alert is not synchronous authorization.

Committed spend with true-up. A customer agrees to a minimum spend over a contract period. Usage is tracked against that commitment, and the contract defines how any shortfall or overage is settled. Show customers their progress before the period closes.

If you expect to add a recurring minimum or included allowance later, model that path before building an event-only system. Adding a subscription floor after the rating logic is in production can require changes across contracts, usage and invoices.

The Stripe-Metronome acquisition changed the market

On January 14, 2026, Stripe announced that it had completed its acquisition of Metronome. That changes who owns a major usage-based billing platform and makes the integration roadmap relevant to buyers.

Stripe says it plans deeper integration across billing, payments, analytics, revenue recognition and tax. If you already use Stripe, ask which parts are available now, which require separate products, and how your existing contracts and data will move.

Check processor choice, invoice ownership, tax, data export and contract terms against your own stack. An acquisition announcement is not enough to establish how every integration works today.

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.

A production billing system needs more than metering and payment collection. It needs a way to ingest and correct events, rate usage against the right contract, apply credits and discounts, explain invoice lines, collect payment, and keep an audit trail. Decide which layers your team needs to own and which it can operate through a billing platform.

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). This can shorten initial setup when your pricing fits the platform. Test your event volume, rating rules, integrations and total cost in your own configuration.

Stripe + Metronome. Stripe now owns Metronome and plans deeper integration. It may fit teams already using Stripe. Confirm processor, invoicing, data export and contract requirements against current product documentation.

Open-source infrastructure (Lago). You can inspect the billing logic and run it on your own infrastructure. That gives your team control over deployment and integration, along with more responsibility for operations. Test the actual setup and processor integrations you need rather than assuming one deployment path fits every team.

Cerebrium's founder and CEO put a number on what that trade-off actually costs: “I implemented our billing system myself, and I'm the CEO. The fact that I could do that in a week and test it out was a huge win.” His team now bills for GPU type, CPU and memory usage, and storage, metered down to the millisecond, and changes pricing by editing the API instead of shipping code. Read Cerebrium's full story.

A useful build-versus-buy signal is how much engineering time pricing changes consume. If every new model requires custom infrastructure, compare that work with a platform implementation. If a platform requires extensive workarounds, include those in the total cost and control you need.

Before you choose a usage-based billing system, ask six questions: What event becomes billable? How are duplicates and late events corrected? How do included usage, credits and overages interact? When can a customer see their spend? Can finance trace an invoice line back to the underlying usage? Does the system fit your hosting, payment and data stack?

Billing and access control are separate decisions. Lago meters and rates usage, applies credits, and can notify your system when an alert threshold is crossed. Usage alerts run on a default five-minute interval, so your application or gateway must enforce a hard request limit. If you are comparing systems for a live pricing model, we can work through the event flow and invoice with you.

Book a demo

At a glance

What breaks at scale

The failure modes are predictable. In rough order of when they appear:

Metering gaps can leak revenue or create disputes. An event type that was not instrumented, a retry counted twice, or late usage that falls outside the billing window changes the amount on an invoice. Reconcile raw events, rated usage and invoice lines so the gap can be found and corrected.

Rating complexity grows when pricing models change. A system built for one metric may need new rules when rates vary by model, geography or contract. Test whether a price change can be configured, versioned and audited before committing to a platform or an in-house build.

Invoice generation can struggle when billing cycles overlap and volume rises. Test batch jobs, partial failures, retries and customer-visible errors against your own peak invoice load.

Dunning logic handles failed payments. Define when to retry, when to notify the customer, and when to stop collection attempts. A billing system should record each attempt so finance and support can explain the balance.

Finance needs reliable usage and contract records before it can apply revenue recognition policies. Invoice timing alone does not settle when revenue is earned. Keep dated usage, corrections and credit activity available for review.

How is usage-based billing revenue recognized?

Usage-based fees can involve variable consideration under ASC 606 or IFRS 15. The accounting treatment depends on the contract, performance obligations and timing of the service, not simply the date an invoice is issued.

The standards contain specific guidance for sales- or usage-based royalties tied to qualifying intellectual-property licenses. That exception should not be assumed for every metered software contract. Finance and auditors should decide which guidance applies.

The billing system should preserve dated usage, corrections, credits and invoice detail so finance can apply and audit its accounting policy.

The implementation architecture

A production-ready usage-based billing system has these layers working in sequence:

Event ingestion. Accept usage events with a customer identifier, timestamp, metric code and unique transaction ID. Plan for retries, duplicates, late arrivals and your actual peak volume. Test replay and correction before relying on the event stream for invoicing.

Aggregation. Roll up events into billable units by customer, metric and billing period. Define a cutoff and correction policy for late events so finance can explain what changed after an invoice was generated.

Rating engine. Apply the contracted price to aggregated usage, including any tiers, volume discounts, dimensions or currencies your model actually uses. Version pricing changes and test their effective dates before issuing invoices.

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. Preserve dated usage, corrections, credits and contract terms so finance can apply the appropriate accounting policy. Invoice timing alone does not settle the answer.

Each layer needs to be independently testable. Billing bugs discovered in production are expensive, in engineering time, customer trust, and sometimes refunds.

Where does entitlement management fit?

Entitlement management decides what a customer can access. Usage-based billing decides what they pay for accessing it. They're adjacent, not the same system, and conflating them is a common design mistake.

A customer's plan might entitle them to advanced analytics regardless of usage. Their bill is calculated from a separate metric: API calls, seats, GB stored. The billing system needs to know the entitlement to apply the right rate (a customer without analytics access shouldn't be metered for it), but the entitlement check and the usage rating are two different code paths. Conflating them is exactly the kind of design mistake that turns the rating complexity described above into a rewrite instead of a config change. See how entitlements are managed alongside billing.

Key Takeaways

• Start with complete, accurate and auditable usage events before refining pricing rules.
• Find the cost of metering errors in your own data by reconciling raw events, rated usage and invoice lines.
• Build-versus-buy depends on which billing layers your team needs to control and operate.
• Check current integrations and contract terms when comparing Stripe, Metronome, Lago or any other platform.
• Keep dated usage and invoice records so finance can apply its revenue recognition policy.

Usage-based billing questions answered

What is usage-based billing?

The system that meters customer consumption (API calls, tokens, compute time), applies pricing rules to it, and generates an invoice, as opposed to billing a flat recurring fee regardless of usage.

Should I build or buy a usage-based billing system?

If pricing changes take weeks and every new model needs new infrastructure, you're building when you should be buying. If you've already bought a platform and you're writing more integration code to work around it than you'd write to replace it, the reverse is true.

How is usage-based billing revenue recognized?

It depends on the contract and performance obligations. Usage-based fees can involve variable consideration under ASC 606 or IFRS 15; finance determines the policy. The billing system should retain dated usage, adjustments and invoice detail to support that decision.

What's the best usage-based billing software?

Compare the system against your pricing rules, event volume, hosting needs, payment integrations and operational ownership. Stripe owns Metronome; Lago provides open-source infrastructure that can be self-hosted. Verify the current capabilities of each against a real invoice flow.

How does entitlement management relate to usage-based billing?

They're adjacent systems, not the same one. Entitlements decide what a customer can access; usage-based billing decides what they pay for using it. Conflating the two is a common source of bugs when plans change.

How much does metering error actually cost?

The amount depends on your own event volume, prices and controls. Compare raw events with rated usage and invoices, then investigate dropped events, duplicates and late corrections.

What are the four main usage-based pricing patterns?

Pure pay-as-you-go, hybrid subscription plus overage, prepaid credits, and committed spend with true-up. Hybrid can combine a recurring floor with charges that grow as usage grows.

How did the Stripe-Metronome acquisition change the market?

Stripe completed its acquisition of Metronome in January 2026 and plans deeper integration across billing, payments, analytics, tax and revenue recognition. Check which integrations are available now and whether they fit your processor, data and contract requirements.

Getting started

Lago is open-source billing infrastructure for usage-based and hybrid pricing. It supports tiered and multidimensional rates, prepaid credits, and self-hosted deployment. Check the current payment integrations and hosting options against your own requirements.

Mistral, Groq, and Together.ai use it, alongside 1NCE, which automated per-GB, per-country pricing and tax across 200+ countries after struggling to scale a manual, prepaid-only model. 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.

Related reading

• AI Billing Infrastructure: What's Required and How to Build It
• How to Set Pricing Metrics for Usage-Based and AI SaaS
• Revenue Leakage in SaaS: How Billing Gaps Cost 1–5% of ARR
• Usage-Based Pricing: The Implementation Playbook
• 7 AI Pricing Models: What Works, What Breaks