The how and why of usage-based billing for SaaS
.webp)
Behind every usage-based pricing plan is a usage-based billing system. Billing systems like Lago are the backend of pricing and monetization. But most people don’t know how they work—and end up with a billing system that makes them do all the work.
That’s because usage-based billing isn’t just a pricing decision. It’s an architecture decision. It requires ingesting raw usage data, applying pricing logic, and generating real-time, accurate invoices. All of them are deeply integrated with your product and infrastructure. This isn’t something you bolt on later.
Platforms like Lago are built for this reality. It’s open-source, event-driven, API-first and designed to handle complex billing use cases in a way that makes both finance and engineering happy.
Of course, usage-based billing isn’t new. Companies like Twilio have charged per API call for a long time. But AI has created marginal costs in software, so billing is getting more and more usage-based.
That’s why choosing the right usage-based billing system is an important decision. It’s a data pipeline, a billing engine, and a product decision.
In this guide, we’ll walk through how usage-based billing actually works — from metering to invoicing — and why open-source platforms like Lago are reshaping how modern SaaS monetizes.
.webp)
Why usage-based billing really matters
In the early days of a SaaS company, you price based on instinct and precedent. $99/month feels right. Maybe you’ve got a Pro plan for power users. Or you add a seat-based charge..
But once you have AI features where your cost scales with usage, static pricing starts to break because one power user can literally bankrupt you. Usage-based billing fixes that.
When done right, it:
- Lowers activation friction (no big upfront commitment)
- Aligns cost to value (no more subsidizing your largest customers)
- Unlocks revenue expansion without a sales call
But when done wrong, it:
- Breaks during audits
- Frustrates customers with inaccurate charges
- Becomes a constant engineering drag
If you’ve been part of any decent-sized company, you know how billing can become a nightmare. The internal team of billing engineers that do nothing but maintain a homegrown system that everyone hates, but is too complex to replace? We’ve been there, done that, hated it and decided to fix it.
Before we dive into the details, let’s define usage-based billing, just so we’re on the same page.
What is usage‑based billing and how does it differ from tiered pricing?
Usage-based billing charges customers based on what they actually use — e.g., $0.01 per API call. Tiered pricing offers fixed plans with more or less unlimited usage. Of course, there are many hybrid models, like plans that include a certain amount of usage before you pay overages or upgrade to a new tier. The key difference: usage-based billing scales continuously with usage, while tiered pricing introduces pricing cliffs and requires upgrades. Many companies use both together.
The real models behind usage-based pricing
There’s no single usage-based pricing model. In reality, only infrastructure companies have pure usage-based pricing, while most companies use some typ of hybrid model.
You’ll often see pay-as-you-go models for elastic workloads (e.g., $0.01 per API call), tiered pricing for predictable growth (e.g., $0.10 per GB for the first 100GB, then discounted tiers), or volume pricing that makes scaling simple.
AI products tend to go hybrid, combining a flat base fee with variable usage (like $99/month for 500 AI credits). Enterprise deals are usually custom, but often include prepaid credits that offer budget control while maintaining usage flexibility.
When you have a billing system that supports all of this. pricing becomes code quickly. When your billing system is a hot mess (most systems are), it might take months to ship a minor pricing change.
How can I simulate invoices with real usage data to validate my pricing?
With Lago, you can run simulations in staging using real usage data. Create pricing plans, load in historical usage, and generate preview invoices. This lets you answer: “What would this customer have paid last month under the new pricing?” It’s the safest way to test new pricing before going live.
How usage-based billing systems actually work
Most SaaS billing systems like Paddle present themselves as a simple alternative. And those are great for simple pricing models like $10/month. But that’s not what Lago does. Because the reality is, usage-based billing touches everything:
- Metering: Capture raw usage events (API calls, compute time)
- Transformation: Normalize and aggregate usage (e.g., per org per hour)
- Pricing: Apply business logic (tiers, discounts, overages)
- Invoicing: Generate itemized, compliant, timezone-aware invoices
- Payments: Handle retries, chargebacks, and dunning
- Visibility: Expose real-time dashboards to customers and support teams
And then we haven’t even talked about dunning campaigns, entitlements, maintaining edge cases and grandfathering in customers when you ship new pricing. This is an infrastructure problem disguised as a billing one.
What are the key components of a real‑time usage‑based billing system?
Mirroring this, a complete usage-based billing system includes:
- Metering: Collect usage data in real time (e.g., API calls, compute minutes)
- Transformation: Normalize and aggregate that data by customer, time period, etc.
- Pricing engine: Apply your pricing rules (tiers, discounts, credits)
- Invoicing: Generate accurate, itemized invoices
- Payments: Integrate with payment gateways for collections
- Dashboards: Give customers real-time visibility into usage and cost
Best practices and common pitfalls
Usage-based billing touches every part of your product and company. You need to get it right.
- Automate invoice generation and payment collection
- Provide customers with real-time access to usage data
- Use flexible, rules-based workflows for pricing
- Integrate billing with your SaaS stack (CRM, support, analytics)
What common pitfalls should engineering teams avoid when implementing usage‑based billing?
- Overengineering early: Start with simple metrics. Don’t model for 50 edge cases up front.
- Batch processing only: Real-time visibility matters — for you and your customers.
- Hidden billing logic: Make billing logic auditable and testable like the rest of your product.
- No staging environment: Always test pricing changes with real data before deploying.
- Bad customer UX: If customers can’t see and trust their usage, you’ll get support tickets — or churn.
Why we built Lago
We built Lago because we saw engineers wasting weeks on Stripe workarounds and brittle internal tools. We saw finance teams copy-pasting CSVs into spreadsheets to calculate overages.
We saw customers getting overbilled — or worse, underbilled — because no one trusted the data pipeline.
.webp)
So we built an open-source billing engine that treats usage-based billing like what it is: a first-class product system. One that supports:
- Real-time metering
- Complex pricing models
- Custom invoice logic
- API-first integrations
- Self-hosting (if you need it)
- Open-source extensibility
We’re building for engineers who care about billing — because billing is product.
Focus on building, not billing
Whether you choose premium or host the open-source version, you'll never worry about billing again.
Lago Premium
The optimal solution for teams with control and flexibility.

Lago Open Source
The optimal solution for small projects.
