What Is Revenue Leakage, and Where Does It Actually Hide?
Revenue leakage is not fraud and it is not theft. It is the money that quietly falls out of the gap between what your contracts say and what your systems actually do.
Revenue leakage is the money a business has legitimately earned but never collects, plus the money it pays out that it never owed. It is rarely one dramatic event. It is a slow bleed made of small, individually forgivable errors: a subscription that kept billing after cancellation, an invoice paid twice because it arrived through two channels, a contracted discount that was never applied, a credit memo that sat unused until it expired.
The reason leakage survives is structural. Every one of those errors is below the threshold that triggers a human review, and the systems that would catch them do not talk to each other. Your contract lives in a PDF, your rate card lives in a spreadsheet, and your ledger lives in QuickBooks or Xero. Nothing continuously compares the three.
The two directions leakage runs
People use the phrase loosely, but it is worth separating the two flows, because they are found in completely different places.
Outbound: money you paid and should not have
- Duplicate payments, where the same invoice is settled twice under slightly different references.
- Vendor overcharges, where the rate billed does not match the rate contracted.
- Payments against cancelled or superseded purchase orders.
- Continued billing on services that were terminated, downgraded, or never provisioned.
- Tax and freight applied to line items that were exempt.
Inbound: money you earned and never collected
- Usage delivered above a contracted tier that was never invoiced.
- Renewal price escalators written into a contract but never applied at renewal.
- Discounts that were meant to be promotional but became permanent because nobody removed them.
- Invoices issued but never chased past the first automated reminder.
Why quarterly review does not catch it
The default control most finance teams rely on is a periodic review: a sample of transactions pulled at quarter end and checked by hand. That approach was designed for a world where transaction volume was low enough to sample meaningfully. It has two failure modes that leakage exploits directly.
- Sampling misses the long tail. Leakage is made of many small items, and a sample sized to catch material misstatement is not sized to catch a hundred charges of a few hundred dollars each.
- Latency compounds the loss. A recurring overcharge found in month nine has been charged nine times. Found in week one, it has been charged once. The same detection logic is worth an order of magnitude more when it runs continuously.
A worked example
Take a mid-sized company paying 400 vendor invoices a month. Suppose one in every 250 payments is a duplicate, which is a rate low enough that no individual approver would ever notice, and suppose the average invoice is 2,400 dollars. That is roughly 1.6 duplicates a month, or about 46,000 dollars a year leaving the business for nothing.
Nobody in that company is negligent. Every single payment was approved by somebody who had a good reason to approve it. The failure is that no process ever asked whether this specific invoice had already been settled under a different reference two weeks earlier.
What actually finds it
Detecting leakage well takes three things that are hard to do with rules alone.
- Fuzzy matching, not exact matching. Real duplicates rarely match on invoice number. They match on vendor, approximate amount, and a date window, with a reference that differs by a prefix or a rounding difference.
- A per-vendor baseline. A 12,000 dollar invoice is unremarkable from one supplier and a glaring outlier from another. Anomaly detection only means something relative to that vendor's own history.
- Continuous coverage of the whole population. Not a sample. Every transaction, every time the ledger changes.
This is what Leaki was built to do. It connects read-only to QuickBooks, Xero, or Zoho Books, runs the full payment history through both deterministic audit patterns and AI analysis, ranks what it finds by severity, and drafts the dispute letter for anything worth recovering. It never writes to your books.
Where to start if you are doing this manually
If you want to size the problem before changing anything, export twelve months of payments and sort by vendor, then by amount. Look for pairs from the same vendor within thirty days of each other whose amounts match within one percent. That single query surfaces the most common duplicate pattern, and it is usually enough to tell you whether the rest of the exercise is worth doing.