Usage Billing Errors: Finding Revenue SaaS Teams Miss

Most B2B software companies with usage-based pricing have the same quiet problem. The product records usage in its own database. The billing tool, such as Stripe Billing or Chargebee, sends invoices based on a copy of that usage. Somewhere between the two, things go missing. Nobody notices, because each system looks healthy on its own.

How common is this?

The most relevant recent survey we found is a March 2026 study by m3ter and PwC UK. It covered 350 software executives in the UK. Almost two-thirds said they did not have full confidence that their finance and business systems capture usage and invoice it correctly. CFOtech reports the figure as 63%. Forty-four percent said they had trouble measuring consumption in usage-based software.

The same study estimates that 4 to 7% of annual recurring revenue is potentially at risk, according to m3ter's reporting. A secondary summary also says 87% of the UK executives had no integration between billing and their ERP or general ledger. Keep the limits in mind. The sample is UK-only, and the study was published by a billing vendor.

Where the money leaks

• Dropped events. A webhook times out, a batch fails halfway, or a queue backs up on a busy day. The product shows the usage, but billing never receives it.
• Late plan changes. A customer upgrades in the middle of the month. One system applies the new price from the upgrade date, and the other applies it from the next billing cycle.
• Credits and caps that do not match. A negotiated rollover or volume cap lives in a spreadsheet or a custom field, and the billing logic was never updated to honor it.
• Currency drift. A customer pays in euros or pounds, but the exchange rate and the date used in the product differ from the ones on the invoice.

Any one of these is small. Together they can add up to a meaningful amount each quarter, and the first person to spot them is often an enterprise customer who is already unhappy.

How to measure your own gap in one week

Survey numbers tell you the problem is widespread. Your own numbers tell you whether it is yours. Here is a practical way to check:

• Pick last month and your 20 largest customers by revenue.
• For each customer, add up the usage units in your product database for the month.
• Add up the usage units that were invoiced to that customer for the same month.
• Flag any customer where the two numbers differ by more than a small tolerance, such as 1%. Multiply the difference by the unit price to estimate the value at stake.

If every customer matches, check again for a month with a high-traffic day. Errors often appear only on busy days, when queues back up.

Best practice: reconcile, do not just monitor

Monitoring tells you the service is up. Reconciliation tells you the numbers are right. You need both, but reconciliation is the one that protects revenue.

• Give every usage event a stable ID. When the same event is sent twice, or sent again after a timeout, billing should count it once. Without IDs, you cannot tell a retry from real usage.
• Compare totals per customer per day. Add up the usage in your product database and the usage billing received. Flag any customer where the two disagree beyond a small tolerance.
• Check for gaps, not only totals. A customer with no events for six hours on a day they normally generate thousands is a warning sign, even if the monthly total looks right.
• Write your pricing rules as tests. Mid-cycle tier changes, credit rollovers and caps should each have example accounts with the invoice amount you expect. Run them every time the pricing logic changes.
• Agree on one currency rule. Decide which exchange rate source and which date apply, write it down, and make sure both the product and the billing system use it.

A billing error caught in a daily check costs a few minutes. The same error caught by a customer can cost a renewal.

How Asauvia helps

We build usage audit pipelines for SaaS teams. The usual setup pulls usage counts from your production data, pulls the matching usage from your billing system, and compares the two per customer and per day. It flags gaps, mismatched totals and invoices that do not follow your pricing rules. The results go to a shared view that finance and engineering both use, so the two teams are looking at the same numbers.

A first engagement usually starts with the one-week check above, run on your own data. From there we agree the tolerance and pricing tests, then set up daily reconciliation. We do not replace Stripe Billing or Chargebee. Those tools handle invoicing well. The audit sits next to them and checks that what they invoice matches what the product delivered.

If you are not sure where to start, begin with one question: for last month, does the usage in our product match the usage on our invoices for every customer? If you cannot answer that quickly, that is the first thing to fix.