What revenue leakage detection is
Revenue leakage is money you are owed and have earned, but that never fully reaches the bank. It is not fraud and it is rarely one big event. It is the steady drip of small gaps between what a business earned, what it invoiced, and what it actually collected: a price that never moved on renewal, a direct debit that bounced and was forgotten, the same customer credited twice, a payment received but never matched to an invoice.
Detection is the systematic side of that problem. Rather than relying on someone noticing, detection reconciles the record of what was earned against the record of what was billed and paid, then flags every discrepancy that does not reconcile. The output is a prioritised list of specific, verifiable findings, each one a concrete sum attached to a real customer and a real transaction, not a vague estimate of exposure.
It matters because the numbers are not trivial. A commonly cited industry estimate puts undetected revenue leakage at 1 to 3 percent of revenue for many businesses. That is an estimate rather than a single published figure, but on a large contract book it is the difference between a comfortable year and a stressed one, and almost none of it shows up on a standard aged debtors report.
Why mid-market finance teams need it specifically
Enterprises have revenue-assurance teams and bespoke controls. The smallest businesses have few enough transactions to eyeball. Mid-market finance teams sit in the hardest middle: high enough volume that nobody can check every line, but lean enough that there is no dedicated person watching for leakage. The work that surfaces leaks, reconciling billing against payments against the ledger, is precisely the work that gets deferred when month-end is due.
The systems make it worse. A contract-heavy business in facilities, waste, builders merchants, managed IT or logistics typically runs billing in one place, direct debits or card payments in another, and the accounts in a third. Each system is honest on its own, but the leaks live in the seams between them: the failed collection that the billing system still shows as raised, the uplift clause that lives in a contract nobody re-read, the credit note in the ledger that the payments system never knew about. No single screen shows the whole picture, so no single person can be responsible for it.
Failed collections are the clearest example, and they are not rare. GoCardless, reporting across 55,000 businesses and 52 million transactions, found that 2.9% of UK Direct Debit payments fail, and that around 30% of customer churn is involuntary, meaning the customer did not choose to leave, a payment simply failed and was never recovered. For a business billing recurring contracts by direct debit, that is real revenue walking out of a supposedly loyal customer base, invisible unless something is deliberately looking for it.
The categories of leakage detection covers
Leakage is not one problem, it is a family of them. Comprehensive detection watches for each of these patterns, so a leak in one system is caught even when every system looks correct on its own.
- Overdue and ageing receivables: invoices past their due date that were never chased, part-paid invoices with an unchased shortfall, and aged unpaid invoices with no due date recorded against them.
- Failed collections: failed card payments and failed direct debits that were never retried. Later-successful retries are suppressed automatically, so only genuinely uncollected money surfaces. This is the involuntary-churn and failed direct debit leak.
- Disputes and chargebacks: money taken and then contested or clawed back, flagged as time-critical against its response deadline so nothing lapses by default.
- Under-billed and unbilled recurring revenue: a contract price that never moved across renewal anniversaries (a missed RPI, CPI or fixed uplift), a discount that stepped down and never recovered, and draft or awaiting-approval invoices that sat unsent and were never issued. Uplift and discount amounts are labelled explicitly as estimates, because the contract clause is not visible in accounting data.
- At-risk renewals and silent churn: a customer billed on an established regular cadence that has gone quiet, where the next expected invoice never appeared, sized on annualised recurring exposure.
- Duplicate charges and duplicate invoices: the same customer charged the same amount twice in a tight window, billed the same amount twice, or two invoices sharing one document number for different amounts. Framed as possible, confirm before refunding or crediting.
- Unapplied cash and overpayments: a customer who has paid more than they were invoiced, pointing to cash on account, an overpayment, or a payment made against a deleted or duplicated invoice.
- Unused and refund-due credit notes: a customer holding a credit balance while also carrying open invoices it could clear, or a credit with no invoice to absorb it, which is effectively refund-due.
- Stalled deals and forecast leakage: a sales opportunity past its expected close date but still open, so the forecast no longer reflects reality.
How deterministic, read-only detection works
Good detection is not a black box and does not need to be. There is no machine learning model guessing at your revenue and no opaque score you have to take on trust. Detection runs on rules: each category above is a deterministic detector that reconciles a specific pattern in the data, for example an invoice whose amount collected is less than its amount due, or two payments of the same value to the same customer within a tight window. If the rule matches, it is a finding. If it does not, it is not. The same inputs always produce the same result, which is exactly what a finance team needs to be able to defend a number.
It reads the actual money, not manual notes. Detection connects to the billing, payment and accounting systems a business already runs and reconciles what was earned against what was invoiced and collected. It does not depend on someone having flagged a problem, written a note, or kept a spreadsheet current. Where the underlying contract clause is not visible in accounting data, such as an uplift percentage or a temporary discount, the amount is labelled as an estimate rather than presented as fact, so nobody acts on a number the data cannot support.
Every finding traces to a source record. Each leak is attached to the specific transaction or invoice behind it, so the finance team can open its own ledger and verify the finding line by line before anyone does anything with it. Detection is deliberately conservative: retries that later succeeded are suppressed so only genuinely uncollected money surfaces, and duplicates are framed as possible and to be confirmed before any refund or credit.
Detection is read-only by design. LeakIQ connects with read-only access and never writes back to any system, never moves money, never retries a payment, never re-presents a direct debit, and never contacts a customer. It produces the finding and a recommended action, then routes each verified leak to an owner. Your own team decides what to do and acts. That boundary is what makes it safe to connect a live billing system to it.
Detection is upstream of chasing, not a competitor to it
It is easy to confuse leakage detection with collections, but they solve different halves of the problem. Chasing, or accounts-receivable automation, works a list you already have: it sends reminders, escalates and helps you collect the invoices your ledger already knows are outstanding. That is valuable, but it can only chase what is already on the aged debtors report. Most leakage is not on that report at all. A missed uplift, a failed direct debit that still shows as raised, unapplied cash, an unused credit note, a customer who simply went quiet: none of these appear as an overdue invoice waiting to be chased.
Detection sits upstream. It finds and confirms the leakage the aging report cannot show. The leaks it confirms as genuinely owed and chaseable, overdue invoices and uncollected balances, are exactly the list your own team, or a collections tool you already run, then works. So detection and chasing are complementary rather than overlapping: detection owns finding and verifying the leak, chasing owns collecting it.
In practice that means LeakIQ runs alongside a chasing tool such as Chaser, Kolleno, Upflow or Quadient rather than replacing it. LeakIQ owns the detection layer; your collections tool owns the chase. Detection first, chasing second. If you already run a collections tool, detection makes it more effective by widening the list of real money it has to work with, and by keeping the leaks that are not chaseable at all, duplicates, overpayments, credit notes, out of the chase queue and in front of the person who can actually resolve them.
How to start: a free revenue leakage report
The lowest-risk way to see whether this applies to your business is to run detection once and look at the result. A free revenue leakage report does exactly that: sign a short mutual NDA, connect a system read-only or send a CSV export, and receive back a prioritised list of exactly what is leaking, with the source record behind every finding so you can reconcile each one to your own ledger.
There is no obligation attached to it. The report is yours to keep whether or not you go any further, the connection is read-only and can be removed at any time, and nothing is ever written back to your systems and no money is ever moved. You see the specific sums, verify them against your ledger, and then decide what, if anything, to do next. Most teams are surprised less by the total than by how ordinary each individual leak turns out to be once it is finally visible.