Pricing & Monetization
Lago vs Togai: Which Usage-Based Billing Platform Fits Your Stack?
Anh-Tho Chuong•Aug 24•4 min read
For small companies, billing errors are fixable. Amounts are small. Customer count is low. Enterprises don't have that luxury. At scale, billing mistakes compound: revenue leakage, audit exposure, engineering debt, customer trust damage.
RevOps leaders report losing 26% of revenue to systemic breakdowns like this, according to Clari's 2024 Revenue Leak Report, nearly a quarter of what a company could reasonably count on collecting.
The problem usually starts with the right decision made too early. You picked a billing tool that worked at the time. Now you're at a different scale, a different pricing model, a different compliance environment. The tool hasn't kept up.
This guide covers what enterprise billing infrastructure actually needs to do.
The two-tier billing problem
Standard billing tools are built for recurring subscriptions with fixed pricing. They work well for that use case.
They break on three things: usage-based pricing, international expansion, and revenue recognition at scale. Not because they're bad products. Because they weren't designed for those requirements.
Enterprise billing systems are architected differently from the start. Event-based ingestion. API-first design. Built for pricing models that change, markets that expand, and finance teams that need data they can take to an auditor.
The market just consolidated around this exact weakness
Two acquisitions in 2026 make this more than an abstract architecture question. Stripe acquired Metronome for roughly $1B because Stripe Billing's own architecture, built for pre-aggregated subscription data, couldn't handle the real-time event volume usage-based and AI pricing models require. Months later, Adyen acquired Orb for $335M, folding one of the more processor-neutral usage-based billing platforms into a payments company's stack.
Both deals point the same direction: billing platforms are increasingly getting absorbed into payment processors. That's a reasonable bet for those companies, but it's a real question for anyone evaluating a platform today, a billing system now embedded inside a payments company has different incentives than one that stays independent. Open-source, processor-agnostic infrastructure is one way to avoid re-litigating this decision the next time a vendor gets acquired.
What an enterprise billing platform must do
Price anything accurately
Subscriptions are table stakes. The real test is usage-based billing: charging accurately based on API calls, compute hours, data volume, active users, tokens. The metering layer is where hard problems live.
This requires an event ingestion engine that handles millions of events without drift. Aggregation logic that holds up to audit. Hybrid model support: a seat fee plus metered overage, a prepaid credit wallet drawn down by consumption, graduated tiers with volume thresholds.
When evaluating platforms, stress-test the metering layer first. Ask for load test results. Run your actual pricing models through a sandbox.
| Standard subscription tools | Enterprise-grade billing | |
|---|---|---|
| Pricing models | Fixed recurring plans | Usage-based, hybrid, graduated, prepaid, natively |
| Event handling | Not built for high-volume events | Millions of events without drift |
| Revenue recognition | Manual reconciliation | Audit-ready data synced to accounting systems |
| Global operations | Single currency/jurisdiction assumptions | Multi-currency, multi-jurisdiction tax handling |
| Vendor structure | Increasingly owned by payment processors | Open-source options remain processor-independent |
Automate the revenue lifecycle
Billing is not just generating invoices. It's the whole cash-flow loop.
Dunning matters more than most teams expect. Involuntary churn from failed payment retries is recoverable with properly sequenced automated retries. The platform should handle this without manual intervention.
Revenue recognition is the piece most billing tools get wrong. ASC 606 and IFRS 15 are accounting standards, not billing features. A billing platform's job is to produce accurate, audit-ready invoice and subscription data and sync it to your accounting system, NetSuite, Xero, where rev rec workflows actually live. Be skeptical of any vendor claiming "built-in ASC 606 compliance" at the billing layer.
Global tax is a legitimate billing-layer concern. Tax engine integrations (Anrok, Avalara) handle multi-jurisdiction calculation automatically. Data privacy compliance (GDPR, CCPA) is an infrastructure question, not a billing feature.
Connect to the rest of the stack
A billing system is a data source for everything else: CRM, finance, product analytics, data warehouse.
The minimum bar: Salesforce or HubSpot for CRM, NetSuite or Xero for accounting, a well-documented API that engineering can actually work with. Not webhooks that fire and forget, bidirectional, reliable sync.
Data warehouse connectivity (Snowflake, BigQuery, Redshift) is the second tier. It lets finance and analytics teams work with billing data without routing every question through engineering.
Handle security correctly
SOC 2 Type II certification is the baseline. End-to-end encryption for payment and personal data.
On PCI DSS: most enterprise billing platforms don't store card data. They integrate with PCI-compliant payment processors. That's the right architecture, the cardholder data environment is scoped to the processor, not the billing layer. If a vendor claims full PCI DSS certification for the billing platform itself, ask what they actually mean.
Self-service portals, usage dashboards, invoice downloads, payment method management, reduce support load and improve trust. Table stakes for enterprise customers.
How to evaluate
Five questions that matter:
- Pricing model coverage. List your current models and the models you'll need in 18 months. Can the platform handle all of them natively, or does it require workarounds?
- Event volume. Estimate peak events per second. What happens at 10x? Ask for documented load test results.
- Integration depth. "Integrates with Salesforce" could mean a webhook or a native bidirectional sync. Ask to see it working. Review the API docs yourself, the quality of the API is the quality of the platform.
- Security evidence. Ask for the SOC 2 report. Ask how they handle payment data. Ask where billing data lives if data residency matters to your compliance team.
- Ownership structure. Ask who owns the platform, and what happens to your roadmap and pricing if that changes. This isn't hypothetical anymore.
The case for open-source billing infrastructure
For engineering-driven organizations, there's a structural argument for open-source.
Lago is open-source and API-first. Built specifically for usage-based and hybrid billing models. The source code is public, inspect the billing logic, extend it, deploy it yourself.
The core advantages over closed systems:
No vendor lock-in. You own the infrastructure. The billing logic isn't a black box you're dependent on one company to maintain. Engineering teams can build on top of it, not around it.
Lago runs as a fully managed cloud service (Lago Premium), or as a self-hosted deployment for enterprises with data residency or security requirements.
FAQ
What makes billing "enterprise-grade" instead of just a bigger version of standard billing? It's architectural, not just scale. Standard tools are built for fixed recurring subscriptions; enterprise billing needs event-based ingestion, audit-ready revenue data, and multi-jurisdiction tax and currency handling from the start, not bolted on later.
Does the Stripe-Metronome and Adyen-Orb consolidation matter if I'm not currently a customer of either? It matters for anyone evaluating billing platforms right now. It signals that standalone usage-based billing platforms are becoming acquisition targets for payment processors, which changes incentives, roadmaps, and pricing over time for whoever ends up owning them.
Can a billing platform actually guarantee ASC 606 compliance? No single billing tool can honestly claim this. ASC 606 and IFRS 15 are accounting standards applied by your finance team and auditors; the billing platform's job is to produce clean, audit-ready data and sync it to the accounting system where recognition actually happens.
Do I need self-hosted billing if data residency isn't currently a requirement? Not necessarily today, but it's worth choosing a platform that offers it as an option, since compliance requirements for enterprise customers tend to appear later, not earlier.
Ready to evaluate a billing platform built for this? Explore the docs to understand integration requirements, or book a demo to see how Lago handles enterprise-scale usage-based billing.
