Usage-based pricing is hard to bill perfectly, even for finance teams running a well-integrated finance stack.
Metering pipelines stream events in real time, plans change mid-cycle, and contracts get amended more often than anyone updates the billing configuration to match.
That gap, unbilled usage, is where revenue assurance lives. Most finance teams have a rigorous process for revenue they expect to collect. Far fewer have one for revenue they've already delivered but never invoiced, largely because nothing in a standard close process is built to ask that question in the first place.
This post is about closing the usage gap without turning finance into a second engineering team: what makes usage-based billing so easy to get subtly wrong, where unbilled usage actually hides, and how finance can keep a continuous, reliable read on the numbers instead of finding out about a leak nine months later.
What revenue assurance in finance actually means
Revenue assurance originated in telecom, where operators processing billions of call records discovered that a fraction of a percent of mediation errors added up to enormous losses.
The discipline was simple in principle: reconcile what the network delivered against what the billing system charged, and investigate every gap. The telecom industry's standards body, TM Forum, later formalized the practice in its GB941 revenue assurance guidebook, which is still the reference point teams cite today.
Software has now inherited the same problem. When you bill per API call, per GB, per transaction, or per workflow run, your metering pipeline is your network, and the same class of gap opens up between what you delivered and what you charged.
So the revenue assurance definition in a usage-based billing context follows the same concept:
Revenue assurance in finance is the continuous, systematic verification that every unit of value a company delivers is correctly measured, priced, invoiced, and collected, and the recovery process for every unit that wasn't.
We've covered the fundamentals, and the fuller telecom-to-software history, in our guide to what revenue assurance is.
Now, let's talk about why usage-based billing creates challenges for revenue assurance in finance.
Why usage-based billing is so hard to get right
Usage-based billing sounds simple from the outside: meter it, price it, invoice it. In practice, it's one of the hardest things in finance to keep accurate for more than a quarter at a time, because the inputs never sit still.
For a decade, that instability was an engineering concern. Pricing was mostly flat, contracts renewed annually, and the mapping between "customer" and "what they pay" was stable enough that a spreadsheet could hold it.
Three shifts changed that, and moved the problem onto the CFO's desk:
1. Pricing became dynamic
Hybrid models (platform fee plus consumption, prepaid credits with overage, tiered volume pricing, per-outcome fees) mean the amount owed changes daily and depends on data your billing system has to correctly interpret every single cycle.
2. Contracts became mutable
Mid-term upgrades, co-terming, custom terms per subscription version, negotiated rate cards. Every amendment is a chance for the contract and the billing configuration to diverge, and the divergence is silent.
3. Product moved faster than billing
A team ships a new endpoint, meters it, and customers start using it, weeks or months before anyone configures it as a billable product. The usage data exists. The invoice line doesn't.
The problem is that unbilled usage doesn't produce errors. It doesn't show up in the invoice, your CRM, or your revenue report. And of course, your customer has no reason to assume anything is wrong, so they don't get in touch to correct it.
Where unbilled usage hides
Detecting unbilled usage starts with a taxonomy, because "we're probably underbilling somewhere" isn't investigable.
These five patterns account for most of what finance teams find. The first two are the purest form of the problem, usage that happened with literally nothing in the billing system positioned to catch it. The other three are variations on the same theme: value delivered, invoice unchanged.
1. Usage without coverage
A customer is actively metering against a product with no active subscription item covering it. The events are landing in your pipeline. Nothing is billing them. This is the single most common leak in usage-based businesses and usually traces back to a provisioning step that happened in product but not in billing.
2. Expired coverage
A subscription lapsed, wasn't renewed on time, or ended mid-term, and consumption kept flowing. The customer is still getting value. You've stopped charging for it. Every day between lapse and detection is unbilled.
3. Out-of-plan adoption
The customer has a subscription, but they've adopted a product or feature that isn't on their current plan. This one is deceptively expensive because it looks healthy: usage is up, the account is engaged, and the invoice is unchanged.
4. Configuration and pricing drift
The contract says one rate. The billing system applies another. A discount that should have expired at month 12 is still applying in month 30. A negotiated tier was entered against the wrong metric. Drift is the hardest leak to see, because every invoice is internally consistent. It's just consistent with the wrong number.
5. Missed true-ups, overages, and expiring credits
Prepaid commitments that were never trued up. Overage thresholds crossed but not invoiced. Credits that expired without being drawn down or recognized. These have hard deadlines, and once the window closes the revenue is usually unrecoverable.
Why spreadsheets and BI dashboards don't close this
Nearly every finance team's first instinct is to solve this with a query. It's the right instinct and it usually produces a real number, once.
Here's why it doesn't hold:
- It's a point-in-time snapshot. Usage data gets backfilled. Subscriptions change mid-period. A reconciliation run on the 5th is stale by the 12th, and rebuilding it is a full day of analyst time.
- It requires joining systems that weren't designed to join. Metering lives in an events store. Subscriptions live in billing. Contracts live in the CRM or a folder of PDFs. Every join is a place for the analysis to be subtly wrong.
- It's held by one person. The analyst who knows which product IDs are deprecated and which customers are on legacy grandfathered terms is a single point of failure, and that knowledge doesn't survive their next role change.
- It finds the number but not the workflow. A spreadsheet listing $340k of uncovered usage is a finding, not a recovery. Without ownership, status tracking, and a route to sales or CS, most of those rows are still open next quarter.
- BI dashboards show what was billed. They're built on your billing data. Revenue that was never billed doesn't appear in them, which is precisely the blind spot.
The distinction that matters: a query gives you a finding. A revenue assurance program gives you a control.
How finance can stay on top of the numbers
Staying on top of unbilled usage doesn't require finance to read event schemas or debug a metering pipeline.
It requires three things, and none of them depend on engineering time every month:
- A continuous read, not a periodic audit. Usage and subscriptions change daily. A number that's accurate on the 1st and stale by the 15th isn't a control, it's a snapshot. The scan needs to run on a cadence that matches how often the underlying data changes, not how often someone remembers to run a query.
- Dollars, not event counts. "Product X has 40,000 uncovered events" isn't something a finance leader can act on. "Product X has $85,000 of uncovered usage this quarter" is. Translating usage into dollars is what turns a data problem into a finance one.
- A single owner and a paper trail. Someone needs to see every open gap, decide what gets chased and what gets dismissed, and be able to explain that decision a quarter later. Without that, the same unbilled usage gets rediscovered and re-argued every cycle.
Get those three right and "are we billing correctly" stops being a question someone has to go dig for the answer to. It becomes a number on a report.
What a working revenue assurance program looks like
Five stages make up the core of any set of revenue assurance best practices, whether you run them by hand or through software.
Each one has an owner and an output.
Detect
Scan the full customer base on a defined cadence, monthly at minimum, ideally continuously, comparing delivered usage against billing coverage. The critical design choice is that detection must run across all customers, not a sampled subset.
Leakage isn't uniformly distributed; it concentrates in the accounts with the most complex contracts, which are usually your largest.
Quantify
Attach a price to every detected gap. This is what converts an engineering observation into a finance artifact. An unpriced list of anomalies gets deprioritized; "$412,000 of uninvoiced usage in Q2" gets a meeting.
Triage
Not every gap is recoverable, and not every gap should be recovered. Trial usage, goodwill overages, known exceptions during migrations, these get dismissed with a reason, not chased. A defensible program is one where dismissals are recorded, so the same item doesn't get re-investigated every cycle.
Recover
Route each opportunity to whoever can close it: an amendment for sales, an expansion conversation for CS, a retroactive invoice for billing ops. Track each one from open to resolved. The recovery rate is the number that justifies the program's existence.
Prevent
Every recurring leak points at a broken control upstream. A pattern of usage-without-coverage means provisioning and billing aren't linked. A pattern of expired coverage means renewal alerts are failing. Feed findings back into process changes, and the same leak stops appearing.
How Alguna's Revenue Assurance helps finance teams
Alguna's Revenue Assurance workspace exists to collapse the detect-and-quantify stages from a multi-week analyst project into a run you launch in a few minutes, and to give the recovery stage a place to live, without finance needing an engineer to stand up the query each time.
It works on the usage and subscription data already in Alguna. There's no new integration, no data warehouse to stand up, and no migration.
Scan the whole base, not a sample. Create a run against any set of products and any time window. Alguna processes your customers in the background and streams opportunities as it finds them, with live progress, so a scan across thousands of accounts doesn't block anyone's day.
Detect the leaks that actually recur. The current detection scenario covers missing subscription coverage in all three of its forms: usage on products with no active subscription, subscriptions that lapsed while consumption continued, and usage on products outside the customer's current plan.
Get the dollar value without extra work. When a run completes, Alguna automatically applies each product's configured default price and precomputes the opportunity cost per customer and in aggregate. If a product has no default price, or you want to model recovery at a different rate, you can set a price per product and the costs recalculate immediately. The number is on screen when the run finishes.
Work opportunities, don't just list them. Every detected opportunity carries the customer, product, period, and underlying usage, and moves through open, acknowledged, resolved, with dismissed for legitimate exceptions. That's the triage record that keeps the same known exception from being re-litigated every quarter.
Route recovery to the people who close it. Export any run to CSV and hand it to sales for amendments, CS for expansion conversations, or billing ops for retroactive invoicing.
Re-run as the data changes. Usage gets backfilled, subscriptions change, pricing evolves. Duplicate any past run to re-scan the same window against current data and see what moved, which is what makes this a repeatable monthly control rather than a one-time audit.
Scope access properly. Two permissions govern the workspace: View Revenue Assurance for viewing runs, opportunities, and exports, and Manage Revenue Assurance for creating runs and configuring pricing. Analysts can investigate without being able to change the pricing assumptions behind the numbers.
The practical effect for a finance team: the leakage number stops being a project someone has to be assigned to, and becomes a report you can pull before a board meeting, a QBR, or a forecast revision.
Alguna is also extending detection beyond coverage gaps: underutilized prepaid credits, usage patterns that indicate a customer should be on a higher-tier plan, unit-level anomalies that signal pricing drift, and scheduled scans that turn the workspace into an always-on control rather than something you remember to run.
Frequently asked questions
How is revenue assurance different from revenue recognition?
Revenue recognition governs how and when booked revenue is reported under ASC 606 or IFRS 15, it starts from the invoice. Revenue assurance starts from the delivery event and verifies an invoice was generated at all. They're complementary: assurance protects the completeness of the revenue that recognition then reports.
How much revenue do usage-based businesses typically leak?
It varies enormously with pricing complexity and billing maturity, and any universal percentage should be treated skeptically. The only number that matters is your own, which is why the first step of any program is a baseline scan rather than a benchmark.
Who should own revenue assurance in a finance team?
Most commonly RevOps or a billing operations lead, with the CFO or VP Finance owning the leakage metric. What matters more than the title is that detection, triage, and recovery have a single accountable owner. Programs fail when detection sits in finance and recovery sits nowhere.
How often should we run revenue assurance checks?
Monthly at minimum, aligned to your billing cycle so gaps are caught within one period. Continuous or scheduled scanning is better, because recoverability declines sharply with age: a gap found in the current period is a routine true-up, while a gap found nine months later is an awkward conversation.
Can we build this ourselves?
You can build the detection query. Most teams do, and it works once. What's harder to sustain is keeping it current as usage backfills and contracts change, and building the triage and recovery workflow around it, which is the part that determines whether findings turn into collected revenue.
Do I need engineering help to catch unbilled usage?
For the initial setup, usually someone has to make sure usage, subscriptions, and pricing live somewhere queryable together. After that, no. Catching unbilled usage on an ongoing basis should be something finance runs itself, on its own schedule, without filing a ticket and waiting for an analyst or an engineer to rebuild the join every month.
Time to account for unbilled usage
Every pattern in this post produces the same signature: value the customer already received, quietly missing a line item. None of it shows up as an error. None of it gets a support ticket. It just sits there until someone goes looking, and the longer nobody looks, the harder it is to recover.
Getting usage billing exactly right, every cycle, for every customer, isn't realistic, not with pricing this dynamic and contracts this mutable. What's realistic is catching the gap fast: a continuous read on the numbers, priced in dollars, with one owner accountable for closing it. That's the difference between a team that discovers unbilled usage once a year during an audit and a team that never lets it accumulate in the first place.
If you want to see what that looks like against your own usage data, book a demo with Alguna and we'll run a live scan together.
