Root Causes of Revenue Leakage in Usage-Based Billing

Revenue leakage in usage-based billing isn't random. It comes from a specific, repeatable set of infrastructure failures: events that never get metered, entitlements nobody enforces, pricing logic that quietly drifts from what actually lands on the invoice. Money owed under contract just never reaches the customer's bill. I've spent enough time in the guts of billing systems to know this isn't churn, and it isn't discounting. The revenue was earned once, then lost somewhere in the plumbing, and most finance teams never go looking for it.

MGI Research put a number on this in 2025: leakage eats 1 to 5% of EBITDA every year, somewhere between $500,000 and $5 million depending on company size. It hides inside revenue that already looks fine on the income statement, which is exactly why nobody catches it in a normal close. MGI's 2024 work broke it down by pricing model: 2 to 4% for flat-rate SaaS, 4 to 9% for usage-based, 5 to 9% for hybrid setups mixing subscription and consumption. The pattern is consistent enough across two years of MGI's research that it stopped looking like noise to me a while ago.

Usage-based billing is harder to get right than flat-rate ever was. Every invoice depends on a chain of real-time decisions: an event comes in, a meter applies, a tier gets checked, an entitlement gets checked, a rate gets calculated, and only then does the invoice go out. Break one link and nothing downstream throws an error. As far as the system's concerned, nothing went wrong, and it billed the wrong number, quietly, and kept going, cycle after cycle, until somebody finally looks.

The valuation math is what turns this into a board-level problem instead of an accounting footnote. At the median 7x SaaS revenue multiple from the Bessemer Cloud Index for Q4 2025, every dollar of annual leakage wipes out seven dollars of enterprise value. I've watched founders spend a full quarter agonizing over a pricing page redesign that might move ARR by a few percent, while six figures of already-earned revenue leaks out through a metering bug nobody's looked at since launch.

How unmetered events become unrecoverable revenue

An event that never gets captured can't be recovered downstream, full stop. No rating engine can rate what it never received, no entitlement check can flag consumption it never saw, no invoice can bill for usage that left no trace. This is the most upstream failure zone, and the hardest one to catch, because it doesn't show up as an error; instead, it shows up as nothing.

Client-side instrumentation gaps are the usual culprit. SDK misconfiguration, version drift across a customer base running five different app releases at once, event logic that only fires on the success path and drops anything that happens mid-retry: all of it quietly starves the metering pipeline. Network loss compounds things from both directions. Non-idempotent retries create duplicate events that inflate usage, while dropped events deflate it, and neither failure announces itself.

Batch pipeline delays add a timing wrinkle I've seen trip up otherwise careful teams. An event landing late near a billing period boundary can slide into the wrong invoicing cycle entirely, and now someone's auditing two invoices instead of one. Scale turns this into a throughput problem too: a popular API can throw off millions of events a second, and ingestion built for a smaller load starts dropping events right when the product is winning the most.

AI products bring a version of this that didn't exist five years ago. A company building on LLM APIs from OpenAI, Anthropic, or Google has to track which customer's usage drove which token consumption, down to the individual model call, not just its own application API. Miss that attribution layer and the cost is real but unbillable; the company pays the LLM provider and has no way to charge the customer who actually generated the spend.

None of this touches top-line revenue. The business keeps growing, new logos keep signing, and nobody's comparing raw usage logs against invoiced amounts on any regular basis, because most teams never run that reconciliation at all, and this leak can run for years. Durable, idempotent event ingestion with replay is the first line of defense here, and it's not a nice-to-have bolted on after the fact.

What gets miscounted once meters are running

Capturing the event is only step one. A meter isn't a counter; it's four components working together, an event filter, an aggregation function, a property being aggregated, and group-by dimensions. Each one is its own place to get it wrong, and I've seen teams get exactly one of the four right and still bill incorrectly for a year.

The aggregation function hides the worst errors. SUM and COUNT tend to fail loudly enough that someone notices fast, while COUNT UNIQUE is different. Exact unique counting at scale is usually impractical, so systems fall back on probabilistic structures like HyperLogLog, which carries roughly a 1% error margin baked in by design. That sounds small for one event, but across billions of events it's a systematic bias sitting inside every invoice that touches that meter, quietly, forever, unless someone goes and checks.

MAX has its own failure mode. Billing on peak concurrency needs correctly defined windows; get the window wrong and peaks either vanish or get double-counted across overlapping periods. LATEST might be the most misread of the four, because it's a snapshot of state, not a running total. Treat it like an additive meter and the billing engine over- or under-bills every customer on that structure, the same way, every single cycle, until someone notices the pattern.

Timezone and period-boundary bugs deserve their own callout. They're easy to introduce and brutal to spot. An event near midnight, or near a billing rollover, lands in the wrong bucket, and because it happens the same way every cycle, the result is a consistent pattern of underbilling rather than noise you'd catch by accident. Group-by errors stack on top of that: bill at the account level when the contract says workspace or user, and usage gets summed across the wrong population before any pricing rule even touches it.

What makes this zone dangerous is that it still produces a number, and nothing alerts, because operationally everything worked. The meter counted something, just the wrong thing, and that error compounds silently until someone sits down with raw event logs and checks them line by line against invoices. Almost nobody does that as a matter of routine.

Entitlement enforcement gaps that let usage run unbilled

Entitlements mark the contract's edge, what a customer is allowed to consume under their plan. When enforcement is missing, delayed, or working off stale data, customers consume past that edge and the company eats the difference. Nobody decides to eat it; it just happens, invoice after invoice, until someone adds up the gap.

The most common mistake is treating a soft limit like a hard one. A plan cap gets checked at invoice time, well after the fact, instead of at the moment of the request, so overages pile up for the entire billing period before anyone notices. Stale entitlement state is the close cousin: a customer changes plans, and that change doesn't hit the enforcement layer in real time, leaving a window, sometimes hours, sometimes longer, where a downgraded customer keeps using features they're no longer paying for.

Feature flags and billing state living in two unsynced systems is another repeat offender. A customer gets toggled off a feature in the product but stays on the billing plan tied to it, or the reverse happens. Trial and grace-period logic leaks the same way when nothing actually expires: trials that were supposed to end and didn't, grandfathered plans that outlived whatever reason they existed for in the first place.

The Cursor incident from July 2025 shows what this looks like once it hits production. One developer on an annual plan ran up a $7,225 invoice, the direct result of uncapped usage with no spend cap, no threshold alert, no check at the request level. The incident reached roughly 797,000 views on X within a week, and that number alone tells you how fast this kind of failure turns from an internal bug ticket into a public trust problem.

Enforcement leakage cuts both ways, and the two directions don't cancel out. Under-enforcement lets customers overconsume for free; over-enforcement, blocking a paying customer from something they're entitled to, drives them to churn instead. Same architecture gap, different failure direction. AI products raise the stakes further, because credit checks on LLM-backed features need to resolve fast enough not to introduce perceptible latency, or the enforcement layer becomes a latency problem, and an engineering team under deadline pressure will route around a bottleneck before they fix it. I don't blame them for that instinct, though I do think it's the wrong one.

Where pricing logic diverges from what actually gets invoiced

Cledara's 2024 analysis found 42% of SaaS companies have at least one live subscription where the billed rate doesn't match the current list price or the actual contract. Nearly half of software companies are billing somewhere in their customer base against numbers that stopped being true a while ago, and most of them don't know it until finance goes digging.

Tiered pricing is a structural source of this. Graduated tiers need the billing engine to apply different rates to different volume bands on a single invoice, and one rounding error or off-by-one boundary compounds across every invoice using that model, not just the one where it started. Volume tiers fail worse in a different way, since one rate covers the whole quantity: a single misclassified boundary flips the entire invoice to the wrong rate, not just the marginal units. Timezone misalignment shows up here too, and usage crossing a tier threshold right at period end can land in the wrong tier for the whole next cycle.

Mid-cycle plan changes bring proration into it, and proration doesn't forgive shortcuts. Partial charges need calculation against the exact timestamp of the change; a billing system that rounds to the nearest day, or leans on calendar-month approximations to keep things simple, over- or under-bills as a direct result of that shortcut.

The most structural problem might be pricing version drift. When pricing logic lives scattered across application code instead of a dedicated rating layer, every pricing change becomes a new code path instead of a new configuration value. Old customers sit on stale logic indefinitely, billed at rates that no longer match their contract, sometimes in the company's favor, sometimes the customer's, never on purpose either way. OpenView's 2025 SaaS Benchmarks report found 55% of SaaS companies say they can't efficiently handle pricing changes with their current billing stack. That's exactly where this drift piles up, one change at a time, until it's load-bearing.

Why these failures cluster in the same companies and compound over time

The first billing system almost always works. It's simple, built for whatever the pricing model looked like on day one. Leakage tends to start with the second and third versions, the ones built later under deadline pressure to bolt on pricing models the original system was never designed to hold.

Across 500 SaaS companies, more than 1,800 pricing and packaging changes were tracked in a single year, averaging 3.6 per company. Each change is a fresh chance for pricing intent and billing reality to drift apart, and usage-based, credit-based, and hybrid pricing raise the degree of difficulty considerably, because metering, rating, entitlement, and invoicing all have to stay in sync continuously rather than just at launch. A billing system built for flat-rate subscriptions accumulates debt with every usage-based feature bolted on afterward, and that debt doesn't announce itself either.

There's a visibility problem baked into how these systems get built. The real cost of a homegrown billing stack scatters across cloud spend, engineering headcount, incident response, and whatever feature got pushed to next quarter to fight the latest billing fire, and it hides until it's too big to ignore. Purpose-built metering and billing platforms like Flexprice exist precisely because that hidden cost compounds faster than most teams expect. Stripe's internal analysis found companies using a dedicated pricing catalog cut pricing-related engineering work by 67%, which tells you roughly where the remaining third of that effort goes in stacks that never got that structure in the first place.

OpenView's 2025 research found 98% of SaaS companies change their pricing at least once a year. On a system never built for rapid change, each of those changes widens the gap between what the pricing team meant to do and what the billing system actually does. This isn't a story about sloppy engineering, and I want to be clear about that. It's a story about complexity outrunning infrastructure that was never asked to handle this much change in the first place.

The infrastructure properties that close each failure zone

None of the fixes here are exotic. For metering, that means durable, idempotent event ingestion with replay, paired with a clean split between measurement code and pricing logic, so aggregation functions can be audited and fixed without touching the instrumentation underneath them.

Aggregation correctness comes down to picking the right function for the job and documenting the error tolerance that comes with it, whether that's COUNT UNIQUE, SUM, MAX, or LATEST, and then testing period-boundary handling against timezone edge cases on purpose, instead of hoping they never come up in production.

Entitlement enforcement needs checks running at request time, in real time, not in a batch job the night before invoicing. Entitlement state has to propagate the moment a plan changes, and spend caps with threshold alerts belong in the initial build, not added after the first bill-shock story goes viral on X.

Pricing-logic divergence gets fixed with a dedicated rating layer acting as the single source of truth for every pricing rule, versioned and auditable, so application code never carries billing logic buried somewhere inside it. Automated reconciliation that checks raw events against invoiced amounts on a fixed schedule closes the loop before a customer finds the gap first, and in my experience, customers find these gaps faster than internal audits ever do.

AI products need one more layer on top of all this: per-customer attribution down to the individual LLM call, entitlement checks under 50 milliseconds so enforcement never becomes the reason a team disables it, and credit balance tracking that runs continuously rather than once at the end of a billing cycle. Metering, rating, entitlement, and invoicing have to work as one system, designed together from the start. Four tools stitched together over years of patching whatever broke most recently will keep leaking, no matter how good each individual tool is on its own.