Your quarterly fee review opens in October and covers July, August and September. It samples the largest charges, finds three rate deviations, and writes them up properly. Two of the three sit on July invoices. By the time the claim reaches the provider, the clause that decides whether you can recover has already run out on them.
Nothing in that sequence was done badly. The evidence was sound, the arithmetic was right, and all three findings were real. The audit design was the problem. It tested a sample of a population, and it tested it late.
TL;DR
- A revenue leakage audit recomputes what every transaction should have cost, and what every client should have been billed, from the contract. Continuous means it runs on the cadence of the data rather than the calendar.
- Continuous does not mean real-time. The IIA’s own guidance states that ongoing control assessments "need not run in real-time" and that frequency follows risk and the business process cycle.
- Sampling is the part that has to go. PCAOB AS 2315 defines audit sampling as testing "less than 100 percent" of a population, which is sound for an opinion on a balance and useless for a population of small, individually trivial fee errors.
- Six steps: defend the data source, normalise the files, reconstruct the contracted price, build the tests, set the cadence from risk, and route each finding into a dispute while it is still disputable.
Short answer
You run a continuous revenue leakage audit by recomputing the contracted price for every transaction and every client invoice, then comparing it against what was actually settled and billed. Two design rules make it work: test the whole population rather than a sample, and run often enough that a finding still lands inside the provider’s dispute window. Six steps get you there — establish a data source you can defend, normalise every provider into one shape, reconstruct the contracted price as your baseline, build the discrepancy tests, set the run frequency from risk rather than the calendar, and route each finding into a dispute with its evidence attached.
What is a revenue leakage audit?
A revenue leakage audit is a test of prices, not of records. It takes the price your contracts set, recomputes what each transaction should have cost or earned, and compares that against what a provider actually charged and what you actually invoiced a client. Anything that differs is a finding.
That makes it two-sided, because revenue leakage in payment operations runs in two directions: a provider charging above your contracted rate, and your own business under-invoicing a client. Both are the same defect with the ledger reversed. An audit that only looks at what you pay covers half the exposure.
It is also not reconciliation, and the difference decides what you will find. Reconciliation asks whether records agree with each other. A settlement file and an invoice can agree perfectly and both be wrong, because neither of them contains the contract. Reconciliation closes cleanly on an overcharge. A leakage audit does not, because it is the only test that reads the agreement.
Why does a periodic revenue leakage audit miss most of it?
A periodic audit misses leakage for two independent reasons. It tests a sample of the population, so most errors are never looked at. And it tests late, so the errors it does find can be past the point of recovery. Fixing one without the other leaves the programme broken.
Sampling tests less than the whole population, by definition
The auditing profession is explicit about what sampling is. PCAOB AS 2315 defines 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 for the purpose of evaluating some characteristic of the balance or class."
That is a reasonable design when you want an opinion about whether a balance is materially correct. It is the wrong design for fee leakage, because fee leakage is a very large population of individually trivial errors. A few basis points on one corridor breaches no materiality threshold and appears on no exception report. Sample the largest charges and you will systematically select against exactly the population where the money is.
The same problem shows up in what published rates can and cannot tell you. Visa publishes its US interchange schedule, but a schedule of rates is not a set of qualification criteria, so a business cannot check its own bill against the public document and be finished. The true cost per transaction has to be reconstructed rather than looked up.
The finding can expire before it is written up
Recovery is decided by a clause, not by evidence. A provider agreement sets a period inside which a charge can be queried, and outside that period a fully sourced discrepancy stops being a claim. A quarterly cycle means the oldest charges in every cycle are already the age of the cycle before anyone reads them.
This is why cadence is an audit-design decision rather than an operational preference, and it is the whole of the argument for running the audit continuously instead of quarterly. The same finding is worth money or nothing depending only on when it surfaced.
What does "continuous" actually mean here?
Continuous does not mean instant, and the profession that coined the term says so. The IIA’s GTAG 3: Continuous Auditing defines continuous auditing as something "achieved through ongoing risk and control assessments enabled by technology-based audit techniques" — a method, not a clock speed.
The same guidance is direct about frequency: "Ongoing control assessments need not run in real-time. The frequency of analysis should be determined by the level of risk, the business process cycle, and the degree to which management is monitoring the controls." Applied to payments, the business process cycle is the settlement and invoicing cycle, and the risk clock is the dispute window.
So the useful target is not real-time reconciliation. It is a cycle that closes faster than the shortest dispute window across your provider set, running against every record rather than a sample. If your provider files land daily and your tightest window is measured in weeks, a daily or weekly run is continuous in every sense that affects recovery.
Continuous auditing and continuous monitoring are different jobs
GTAG 3 draws a line that is worth keeping. Continuous monitoring is defined as "a management process that monitors on an ongoing basis whether internal controls are operating effectively", and the guidance is unambiguous about ownership: "Management should own and perform continuous monitoring." Continuous auditing is the independent assessment sitting over it.
For a payment business the practical consequence is a split of duties. Payment operations owns the daily monitoring of exceptions. Finance or internal audit owns the independent recomputation from the contract. Where one team does both, the recomputation is the part that quietly gets dropped when volumes rise, because it is the part nobody is chasing.
How do you run a continuous revenue leakage audit?
Six steps, in order. The first three build the thing that makes a finding possible. The last three turn findings into recovered money.
- Establish a data source you can defend.
- Normalise every provider into one shape.
- Reconstruct the contracted price as your baseline.
- Build the discrepancy tests.
- Set the cadence from risk, not the calendar.
- Route every finding into a dispute with its evidence attached.
1. Establish a data source you can defend
GTAG 3 puts data reliability first, and ranks sources: "Data sourced from a production environment subject to IT general controls is more reliable than data sourced from end-user developed applications." It also says reliability "should be assessed during a baseline audit" rather than assumed.
In a payment stack that ranking is concrete. The settlement file and the provider invoice are the records that carry contractual weight. A dashboard export or a hand-built spreadsheet is a derived artefact, and a derived artefact cannot support a claim. Start by reading the invoice for what it actually asserts, then confirm you can obtain the same data on a schedule rather than on request.
The test for this step is simple. For any charge in the last month, can you produce the source record, unedited, with the date it arrived? If the answer involves a person exporting something, the audit is not yet continuous.
2. Normalise every provider into one shape
Every provider names, groups and times its fees differently, so comparison across a multi-provider stack is impossible until the files share a structure. GTAG 3 states the requirement plainly: "Combining data from disparate systems requires data validation to remove unreliable transactions and prepare the data in a standard audit format."
The pay-off is cadence, not tidiness. In the same guidance: "Automated data feeds can reduce validation time and increase the frequency of analysis." Manual normalisation is the single reason most fee audits stay quarterly — the preparation, not the analysis, is what takes the weeks. A canonical event ledger is what this step produces.
3. Reconstruct the contracted price as your baseline
GTAG 3 describes ongoing control assessment as evaluation "against a baseline condition and subsequent changes to control configurations". In a fee audit the baseline is not a system setting. It is the price your agreement sets.
That means the contract is the source of truth, including its amendments, its volume tiers, its pass-through definitions and its effective dates. A rate card that lives in a PDF and a price that lives in a settlement file are not comparable until someone turns the first into data. This is the step that gets skipped, and skipping it is what leaves a team reconciling records against each other instead of against the agreement.
Two details decide whether this holds up later. Every term has to be traceable to a clause, so a finding cites the contract rather than an assumption. And amendments need effective dates, because the correct price for a transaction is the price that applied on the day it settled, not the price in force today.
4. Build the discrepancy tests
GTAG 3 calls this constructing continuous auditing indicators, and advises you "build a road map that is integrated with the audit plan" using what previous conventional audits taught you. In practice: start with the discrepancy types you have already found by hand, because those are the ones you can prove.
The taxonomy of discrepancy types is the test list. Each test is a comparison with a defined input, a defined expectation, and an output that names the money.
| Test | What it compares | What it catches |
|---|---|---|
| Rate deviation | Contracted rate against the rate actually applied | A charge above the tier your agreement specifies |
| Tier application | Achieved volume against the tier in force | A negotiated reduction that was never switched on |
| Pass-through integrity | Stated pass-through against the underlying scheme cost | An undisclosed spread on a fee sold as at-cost |
| Duplicate charge | Each fee against every other fee on the same event | The same transaction billed twice |
| Timing violation | Settlement date against the contractual timing terms | Fees applied outside the agreed cycle |
| FX markup | Applied rate against the reference rate plus contracted margin | Conversion margin above the agreed spread |
| Client under-billing | Client contract against the invoice you issued | Revenue you earned and never charged for |
5. Set the cadence from risk, not the calendar
GTAG 3 gives the rule and its examples: frequency follows "the level of risk, the business process cycle, and the degree to which management is monitoring the controls". Purchase card analytics monthly, payroll every pay period, and so on. The cadence tracks the data, not the reporting calendar.
For fee leakage there is a hard constraint on top of that rule. The cycle has to close inside the shortest dispute window across your providers, with enough margin left to raise a claim. Work backwards from that number: window length, minus the days you need to review and file, gives the maximum run interval. If a provider ships files daily, run daily. Nothing about a quarter-end has any bearing on it.
6. Route every finding into a dispute with its evidence attached
An unrouted finding is not recovery. Each one needs the source record, the contract clause it breaches, the computed expected amount, the actual amount, and the difference — assembled at the moment of detection rather than reconstructed weeks later. That is the difference between a spreadsheet row and a dispute a provider will act on.
GTAG 3 closes its own cycle the same way, with follow-up: monitor remediation, and check whether the fix reduced the risk. For a fee audit that means tracking which findings were credited, which were rejected, and which recurred. A discrepancy type that keeps coming back is a contract or configuration problem, not an accident.
How do you detect revenue leakage without a large team?
Revenue leakage detection is arithmetic run at volume, so the constraint is coverage rather than headcount. A test that runs on every record finds a class of error once and then finds every instance of it, which is the opposite of how manual review scales.
This is where spreadsheet-based review stops working. Not because the arithmetic is hard, but because the preparation consumes the time the analysis needed, and because a spreadsheet is the end-user application GTAG 3 explicitly ranks as the least reliable source. The real cost of a reconciliation team is mostly spent on step two of the six above.
What about the billing side of the ledger?
The receivables half uses the same six steps with the inputs swapped: your client agreement replaces the provider contract, and your issued invoice replaces the settlement file. The failure mode is under-billing, and it is where billing breaks as a payment business scales — bespoke pricing, mid-term amendments and minimums that nobody re-priced.
It is also the half with no dispute window, which cuts both ways. Nothing expires, so old under-billing stays theoretically recoverable. But invoicing a client eight months late for revenue you failed to charge is a commercial conversation rather than a claim, which is why an audit-traceable invoice is worth more than a retrospective correction.
How do you know the audit is working?
Four measures tell you whether the programme is real, and none of them is the total recovered. Recovery is an outcome that depends on how much leakage existed, so a low number can mean a clean provider set or a broken audit.
- Coverage. The share of transactions tested against a reconstructed contract price. Anything below the whole population is a sampling decision, and worth stating as one.
- Latency. Days from a charge settling to a finding existing. This is the number that decides whether recovery is available at all.
- Claims filed inside the window. Findings raised while still disputable, as a share of all findings. A high figure here with low recovery is a provider problem. A low figure is a cadence problem.
- Recurrence by provider and test. The same discrepancy type reappearing after remediation points at the contract or the configuration, not at bad luck.
The bottom line
A continuous revenue leakage audit is not a faster version of the quarterly one. It is a different design: full population instead of a sample, contract instead of record-to-record agreement, and a cycle set by the dispute window instead of the reporting calendar.
The six steps are ordered deliberately. Most programmes stall on step two, because normalising provider files by hand costs the weeks that force the audit back onto a quarterly rhythm, and a quarterly rhythm is what lets findings expire. Fix the preparation and the cadence follows.
A finding that arrives after the window closed is not a finding. It is a record of money you no longer have.
Frequently asked questions
How often should a revenue leakage audit run?
Often enough that a finding still falls inside the shortest dispute window across your providers, with time left to file. GTAG 3 sets frequency by "the level of risk, the business process cycle, and the degree to which management is monitoring the controls", which for payments means the settlement and invoicing cycle. If provider files arrive daily, run daily or weekly. A quarterly cycle guarantees that the oldest charges in every cycle are already a quarter old before anyone reads them.
Is a revenue leakage audit the same as reconciliation?
No. Reconciliation asks whether two records agree with each other. A leakage audit asks whether the charge matches the contract. A settlement file and an invoice can reconcile perfectly and both be wrong, because neither document contains the agreed price. Reconciliation closes cleanly on an overcharge; that is precisely its limitation.
Does continuous auditing mean real-time reconciliation?
No, and the IIA says so directly: "Ongoing control assessments need not run in real-time." Continuous refers to the method, ongoing assessment enabled by technology-based audit techniques, not to latency. The target is a cycle shorter than the dispute window against the full population, which is a much lower bar than real-time and a far more useful one.
Can you run a continuous revenue leakage audit in spreadsheets?
You can run the arithmetic in a spreadsheet. You cannot run it continuously, for two reasons. Manual normalisation of multi-provider files consumes the time the cadence needs, and GTAG 3 ranks end-user developed applications as less reliable than production data subject to IT general controls, so the working file weakens the evidence it produces.
Who owns a continuous revenue leakage audit?
Split it. GTAG 3 assigns continuous monitoring to management: "Management should own and perform continuous monitoring." Payment operations owns the daily exception handling. Finance or internal audit owns the independent recomputation from the contract, which is the part that establishes what a charge should have been rather than whether it looked unusual.
What data do you need before you start?
Three things per provider: the settlement or transaction file at line-item granularity, the invoice or statement, and the executed agreement with every amendment and its effective date. Missing the third is the common case, and it is disqualifying, because without the contracted price there is no expectation to compare anything against.
What is the difference between revenue leakage and fee leakage?
Fee leakage is the cost-side subset: money overpaid to providers. Revenue leakage covers both sides, adding revenue you failed to invoice a client. A programme that only audits provider fees is auditing half the ledger, and usually the half with a deadline attached.
