A provider bills one corridor at a rate slightly above the tier your contract specifies. The difference is a few basis points. It appears on no exception report, breaches no threshold, and reconciles cleanly, because the settlement file and the invoice agree with each other. They just do not agree with the contract.
That is revenue leakage. Money left the business, or never arrived, because a price nobody verified was applied to activity nobody re-priced. Nobody wrote it down as a loss, because on every system that touched it, it was never a loss at all.
TL;DR
- Revenue leakage in payment operations runs in two directions: fees a provider charged above the contracted rate, and revenue under-invoiced to your own clients.
- The cost side is the half nobody inspects, because a provider invoice is read as fact rather than as a claim to check against the agreement.
- No standards body or accounting framework defines revenue leakage, and the only measured figures with a disclosed method come from telecoms in 2017/18, eight years old and no payments benchmark.
- The remedy is a comparison you can compute: the contracted price applied to actual activity, measured per transaction against what was settled or billed.
Short answer
Revenue leakage in fintech payments is revenue lost to billing that nobody verified. It runs in two directions: fees a provider charged above your contracted rate, and revenue you earned but under-invoiced to a client. Both are the same defect with the ledger reversed, and both survive reconciliation, because a settlement file and an invoice can agree with each other while neither agrees with the contract. No standards body defines the term, and the percentage figures in circulation trace to no published method, so the useful question is not how large leakage is in general. It is what your own contracts say each transaction should have cost.
What is revenue leakage?
Revenue leakage is revenue lost to billing nobody verified: fees a provider overcharged, or revenue you under-invoiced.
No standards body, professional body or accounting framework defines it. The most recent systematic review of the academic literature says revenue leakage "remains inconsistently defined, leading to varying interpretations and a lack of standardised prevention strategies," and that "the absence of an overarching conceptual foundation complicates efforts to measure, detect, and mitigate" it. (That paper is a preprint and has not been peer reviewed.)
The working definition in circulation, which the review attributes to five prior sources, is "an organisation's unintended loss of revenue due to inefficiencies, errors, or fraudulent activities." Applied to a subscription business it points outward, at revenue you failed to collect from customers. Applied to a payment business it has to point in two directions at once.
The two-sided definition, for payment operations
A payment business sits between two sets of contracted prices, what providers charge it and what it charges its clients. Both live in agreements, and both are applied by systems that never read them.
| Side of the ledger | What leaks | Where it hides |
|---|---|---|
| Cost side, what you pay providers | A charge above the contracted rate | Blended statement lines |
| Cost side | Pass-through fees carrying an undisclosed spread | Line items marked as pass-through |
| Cost side | A contracted volume tier or reduction never applied | Rate card against actual settlement |
| Receivables side, what you bill clients | A client invoiced below the contracted rate | The gap between contract and invoice |
| Receivables side | Contracted minimums or floors never billed | Terms that require an action to trigger |
| Receivables side | Rate amendments never reaching the billing system | The amendment backlog |
The two halves are the same defect with the ledger reversed: pricing logic sits in a contract, activity sits in a transaction system, and nothing joins them.
Revenue assurance, owned by TM Forum in telecoms, measures a KPI it labels "% of revenue losses and/or overcharging." Overcharging is named in the measure itself. Payments did not inherit that framing.
What causes revenue leakage in payment operations?
Revenue leakage in payment operations is caused by four mechanisms: contract terms no billing system can read, transactions that fail to qualify for the rate you expected, a cost base that is not the published rate card, and currency conversion applied at a markup nobody checked. All four are usually examined on the sale. The same mechanisms priced on a refund or a dispute are set out in refunds, chargebacks and the fees that never come back.
Contract terms that no system can read
A rate card is a document. A settlement file is data. Between them sits a translation nobody audits: tier boundaries, effective dates, corridor exceptions, amendment history.
In the systematic review above, contract-driven leakage is the least studied cause, appearing in one paper out of the eighty-nine reviewed, described as "contract breaches, ambiguous terms, missed payments, and non-fulfilment of obligations." Fraudulent practices account for thirty-four percent of the same literature. Those percentages count published papers. They say nothing about where the money actually goes.
Rates that fail to qualify for the price you expected
Rate downgrades are documented publicly, by the card networks themselves, and they are routinely described as industry folklore. They are not.
Visa's published US interchange schedule, as of its 18 April 2026 edition, contains a fee program named Downgrade. In the interregional table covering cards issued outside the US and used at a US merchant, the Downgrade rate is priced above both the base and the alternative rate. A transaction that misses the criteria for its expected program lands on a named, published, higher rate.
Visa's schedule publishes the rates but not the criteria: it refers the reader to a separate "U.S. Interchange Reimbursement Fee Rate Qualification Guide." The rate card is public. The rulebook that selects which rate applies is not.
So the published documentation cannot tell a business whether a transaction should have qualified for a better rate. The contract does not answer that question either. It answers a different one: what you agreed to pay. That is a structural verification gap.
A cost that is not the number on the rate card
The distinction that separates a generalist from a payments operator is who pays interchange. Visa states it directly: "Merchants do not pay interchange reimbursement fees." Interchange is described as "transfer fees between acquiring banks and issuing banks for each Visa card transaction." What a merchant pays is a merchant discount, owed "to their financial institution that is typically calculated as a percentage per transaction."
You cannot check your bill against the public schedule and be finished: your cost is a negotiated bundle and the schedule is one input to it. The only document that says what you should have been charged is your own contract.
Currency conversion, the one vector with a legal reference point
FX is the exception that proves how unusual the rest is. EU Regulation 2019/518, Article 3a(1), requires that currency conversion charges be expressed "as a percentage mark-up over the latest available euro foreign exchange reference rates issued by the European Central Bank," which is why FX markup can be measured precisely while other fee categories cannot. The mechanics are covered in FX spread vs FX markup.
The cost-side categories this produces, rate deviation, fee overcharge, missing fee, duplicate fee, FX markup and timing violation, are set out in the taxonomy of PSP discrepancy types. The receivables side is covered in why fintech client billing breaks at scale.
Why does revenue leakage stay invisible?
Revenue leakage stays invisible because reviews cover a sample of transactions and leakage lives in the population. Effort has very little to do with it.
Sampling covers less than the whole population
PCAOB AS 2315 describes audit sampling as "the application of an audit procedure to less than 100 percent of the items within an account balance or class of transactions," and warns that when a test is restricted to a sample, "the auditor's conclusions may be different from the conclusions he would reach if the test were applied in the same way to all items."
Fee leakage is a very large population of individually trivial errors. A two-basis-point deviation on every transaction in one corridor is invisible in any sample small enough to review by hand. Sampling is not merely imperfect against that shape. It is close to blind to it.
Full coverage is the profession's own correction
The internal-audit profession framed the correction as coverage rather than tooling. The IIA's guidance on continuous auditing describes a shift "from periodic evaluations of risks and controls based on a sample of transactions, to ongoing evaluations based on a larger proportion of transactions." What each review cadence recovers is worked through in continuous audit vs quarterly audit, and why latency is expensive in the clause that caps how long a charge stays queryable.
Late detection is a control-design problem
PCAOB AS 2201 defines a control deficiency as existing where "the design or operation of a control does not allow management or employees, in the normal course of performing their assigned functions, to prevent or detect misstatements on a timely basis." A review that surfaces an overcharge after it has stopped being collectible did not detect it on a timely basis. That is a control-design observation. It is not a claim that fee leakage constitutes a material weakness: most fee leakage is immaterial at the financial-statement level, which is why the close never catches it.
How do you measure revenue leakage?
You measure revenue leakage per transaction, with arithmetic rather than judgment: the contracted price applied to actual activity, minus what was actually settled or billed.
Every term has to be reconstructable from a source: the agreement and its amendments, the transaction record, the settlement file. A number that cannot be traced back to those three is an estimate wearing a decimal point. The comparison is set out in expected vs actual in fintech fee management.
What the credible numbers actually say
There is no credible published figure for revenue leakage in payments. A figure of one to five percent of revenue circulates widely. It is not traceable to any published source. Every reachable instance is a vendor page or glossary with no linked document, so no argument on this page rests on it.
The only measured figures with a disclosed method come from telecoms. TM Forum's Revenue Assurance Survey for 2017/18 reports average revenue leakage before recovery of just under one percent of revenue as measured, and roughly two percent as estimated. It records 114 valid responses and discloses its calculation method. The data is from 2017/18, so roughly eight years old, and it describes telecoms rather than payments. It is a precedent, never a payments benchmark.
MGI Research defines revenue leakage as "the variance between contractually obligated revenue and actual recognized revenue," a contract-anchored definition close to the one above, and puts the figure at three to five percent of revenue with no disclosed sample, year or methodology. The measured number and the asserted number therefore disagree by roughly a factor of four. One is a KPI measured against a published definition. The other is an assertion. What leakage costs a cross-border book is examined in what fee leakage actually costs.
What is another word for revenue leakage?
In payments, the term with independent standing of its own is payment leakage. Three other terms get used interchangeably with revenue leakage, and each belongs to a different discipline: revenue assurance, revenue integrity and revenue recognition.
Revenue assurance is the mature one, owned by TM Forum and practised in telecoms, with KPI definitions that sit behind membership. If revenue leakage is the condition, revenue assurance is the function that measures it.
Revenue integrity is a healthcare term rather than a general finance one. HFMA material describes it as an enterprise function evolving into a broader concept: charge capture, acuity documentation and quality achievement, all culminating in reimbursement performance. Borrowing it for payments imports the wrong reference points.
Revenue recognition is a different question entirely. IFRS 15 requires an entity to recognise revenue reflecting "the consideration to which the entity expects to be entitled," and ASC 606 is its US counterpart. Recognition governs how you account for revenue you are entitled to. Leakage is failing to identify that entitlement at all, which is why under-billing never surfaces in the close.
Revenue leakage and fee leakage are not the same size
Bluefyn uses fee leakage for a narrower thing: the cost-side subset, where a provider charged more than the contract entitled it to. It is not an established industry term of art. Revenue leakage is the parent, covering both sides of the ledger. Fee leakage is one half of it. The cost-side discipline is described in provider economics.
What is revenue leakage in a bank?
In a bank or a licensed payment business, revenue leakage runs on both sides of the ledger at once: the institution is both a buyer of infrastructure and a seller of services. It pays for scheme access, correspondent relationships, processing and settlement, and charges its clients programme fees, transaction fees, monthly minimums and FX. Every one of those prices is negotiated and amended, and billed by a system holding a copy of the price rather than the contract.
Two features make the banking case worse. Volume, because a small per-unit deviation compounds across a very large population. And provability, because a regulated institution must be able to demonstrate that what it charged and paid match the agreements. That exposure surfaces in diligence and audit, as covered in how cross-border fintech billing generates audit risk; why the invoice itself is a weak control is set out in PSP invoice errors.
How do you stop revenue leakage?
You stop revenue leakage by verifying every transaction against the contract that priced it, rather than inspecting a sample of the invoices that report it. Five steps:
- Reconstruct the contracted price from the agreement and its amendments.
- Compute what each transaction should have cost under that price.
- Compare it against what was actually settled or billed.
- Keep the difference traceable to its source, so the finding is evidence.
- Run it across the whole population, while the charge is still queryable.
How do you know if a payment provider overcharged you?
You know a payment provider overcharged you when the contracted price for a transaction is below the amount actually settled for it, and the difference traces back to the agreement. The invoice cannot tell you on its own: a settlement file and an invoice can agree while both apply a price the contract never authorised. Published network schedules cannot tell you either: they publish rates without the criteria that decide which rate qualifies. Your own contract, read against your transaction data, answers it.
Where the calculation has to stay deterministic
This leakage is also the hidden cost most attempts to reduce reconciliation team cost miss.
Revenue leakage is a data and contract problem before it is a software problem. The core calculation has to be deterministic and auditable, because a number that cannot be reproduced cannot be disputed. Agents can assist with the workflow around it: triage, routing, drafting. They do not belong inside the maths. Bluefyn never moves, holds, or custodies funds. It analyses transaction and provider data, and it identifies and recovers money lost to incorrect fees, pricing errors, or hidden spreads. That activity is described in what is a fintech fee audit, the wider category in the verification discipline it belongs to, and the tooling landscape in the best tools for auditing payment provider fees.
The bottom line
Revenue leakage in fintech payments is two-sided, and the industry has only ever discussed one side of it. The subscription-billing literature points the leak outward, at revenue uncollected from customers. For a payment business, the other half sits on the cost side, where a provider charged above the contracted rate and the invoice agreed with itself all the way down.
Nobody authoritative defines the term, the credible numbers belong to another industry and are eight years old, and the number everyone quotes traces to nothing. What is left is not an estimate. It is a comparison you can compute, per transaction, against a contract you already signed.
Trust is not verification.
The practical follow-on is the audit itself: how to run a continuous revenue leakage audit on your payment stack, across the whole population rather than a sample.
Frequently asked questions
What do you mean by revenue leakage?
Revenue lost to billing nobody verified. In payment operations it runs in two directions: fees a provider charged above the contracted rate, and revenue under-invoiced to your own clients. Both come from the same defect, which is that pricing logic lives in a contract and activity lives in a transaction system, with nothing joining them.
Is revenue leakage the same as fraud?
No, and the distinction matters for where you look. Fraud is deliberate. Most payment leakage is a translation failure between a contract and a system: a tier boundary applied to the wrong volume band, an amendment that never reached billing, a rate that quietly failed to qualify. The academic literature concentrates heavily on fraud, while contract-driven causes appear in a single paper out of eighty-nine reviewed.
How much revenue does leakage typically represent?
There is no trustworthy industry figure for payments. The widely quoted one-to-five-percent range is not traceable to any published source. The only measured figures with a disclosed method come from telecoms, where TM Forum's 2017/18 survey put average measured leakage just under one percent of revenue, before recovery, across 114 responses. That is eight-year-old data from another industry. Measure your own against your own contracts.
Why doesn't reconciliation catch revenue leakage?
Because reconciliation asks whether records agree with each other, and leakage is a disagreement between records and a contract. A settlement file and an invoice can match perfectly while both apply a price the agreement never authorised. Catching that requires the contract to be part of the comparison, which is the difference between reconciling records and verifying prices.
What is a revenue leakage in a bank?
Revenue leakage in a bank is money lost on both sides of the ledger: charges above the contracted rate on the infrastructure the bank buys, and fees under-billed on the services it sells. A bank pays for scheme access, correspondent relationships and processing, and charges programme, transaction and conversion fees to its clients. Every one of those prices is negotiated and amended, and billed by a system holding a copy rather than the contract. Volume compounds small deviations, and regulatory expectations mean the institution has to be able to demonstrate the match rather than assert it.
Can you verify interchange from published rates?
Not on its own. The card networks publish rate schedules. They do not publish the criteria that decide which rate a transaction qualifies for. Visa's public schedule refers the reader to a separate rate qualification guide. What a merchant pays is also not interchange: Visa states that merchants pay a merchant discount to their financial institution, and that interchange is a transfer between acquiring and issuing banks. The document that says what you should have been charged is your own contract.
