Short answer
You detect fee leakage by comparing what each transaction should have cost, under your contract, against what the provider actually charged, and then reading the gap. That comparison is the whole method. The rest is detail: which signals the gap can take, what each one looks like in the data, and the order to check them so you catch the expensive ones first. It assumes you already know what leakage is and what the error types are. The part nobody writes down is the read itself: how you actually notice an error while looking at your own transaction records.
What detecting fee leakage actually means
Three related jobs get called the same thing, and separating them makes the work clearer.
Detection is the single act of comparing one charge against its expected cost and deciding whether the difference is an error.
An audit is the program that runs detection on a schedule: who owns it, how often it runs, and how sampling lets errors slip through when it runs too rarely. That is a cadence question, covered elsewhere.
The taxonomy is the catalog of what the errors are: rate deviation, duplicate fee, timing violation, markup drift, and the rest. Their definitions live in that post.
So detection sits in the middle. It assumes you know what an error is, and it feeds the audit that decides how often you look.
The one comparison it all reduces to
Every detection method, however it is dressed up, reduces to expected versus actual on a single transaction. The expected charge is what the transaction should have cost under the contract. The actual charge is what the provider billed. The difference is the discrepancy you are hunting.
That comparison has one prerequisite, and it is the part people underestimate. You need a resolved expected cost for every transaction before you can compare anything to it. A contract prices conditions, not transactions, so turning it into a per-transaction number is its own task, covered in how a contract becomes a per-transaction check. Once you have that expected number beside the actual charge, detection is reading the gap. Reading it well is the rest of the work.
The four signals, and the order to check them
A discrepancy is not one thing. It shows up in the data in a handful of distinct shapes, and each shape has a tell. Learn the tells and detection stops being a vague hunt and becomes a checklist. The figures in these examples are illustrative, meant to show the shape of each signal rather than to state a real rate.
Check them in this order, because it puts the errors that are easy to see and expensive to miss first.
1. Rate deviation
This is the common one, so start here. A rate deviation is a charge computed at a rate that does not match the contract. The tell is a percentage that is close to correct but not exact, applied consistently across many transactions. Suppose your contract says a card type is priced at a set rate, and the actual charges resolve to a slightly higher one on every transaction of that type. Each single overcharge looks trivial. The signal is the consistency: the same wrong rate repeating is a pricing setup that does not match your agreement rather than a random blip. Group your charges by the pricing condition the contract defines, compute the effective rate for each group, and compare it to the contracted rate. A group whose effective rate sits off the contract is a rate deviation.
2. Duplicate fee
Check this second, because it is easy to spot once you look and it is pure loss. A duplicate fee is the same charge applied twice to one event. The tell is two fee lines with the same amount, the same type, and the same or near-identical timestamp, tied to a single transaction. These do not average out or hide in a rate. They are a clean match against themselves. Sort fees by transaction identifier and look for a type that appears more than once when the contract says it should appear once. A fixed per-transaction fee billed twice on the same transaction is the clearest example.
3. Timing violation
Check this third, because it needs the calendar rather than just the amount. A timing violation is a charge that is correct in size but applied in the wrong window: a fee outside the contracted schedule, a rate applied before its effective date, or a charge that lands after the terms that priced it expired. The tell is not in the amount at all. It is in the date. A charge can be the right number and still be wrong because of when it was applied. Compare each charge's date against the effective dates in the contract, and against the settlement date of the transaction it attaches to. A fee that is right in size but sits outside its valid window is a timing violation, and it is the one a purely amount-based check will miss.
4. Markup drift
Check this last, because it is the slowest to appear and the hardest to see. Markup drift is a margin that widens over time, a small added percentage that grows across months while every single charge still looks defensible. The tell is a trend, not a transaction. No individual charge is obviously wrong. The effective cost of a fixed activity simply creeps upward when you plot it over a long enough window. Track the effective rate for a stable, unchanging type of transaction month over month. If it rises while nothing in your contract or mix changed, that upward line is drift. When that drift arrives as a step rather than a slow creep, it usually means the provider changed your fee schedule.
Manual detection, and detection at volume
You can run every one of these checks by hand, and for a small book you should, because doing it once by hand teaches you the signals. Pull a period of charges, resolve the expected cost for each, and walk the four signals in order.
That approach has a ceiling. Past a few thousand transactions a month, a spreadsheet check can only sample, and sampling is exactly how leakage survives: the errors you did not draw into the sample stay uncaught, settle, and age out of the window to dispute them. The signals do not change at volume. What changes is that every transaction has to be checked rather than sampled, which is a job for an automated comparison rather than a person. The path from the manual read to a system that runs it on every transaction is covered in how to automate provider invoice reconciliation.
The detection-signals table
| Signal | What breaks | What it looks like in the data | How fast you need to catch it |
|---|---|---|---|
| Rate deviation | A rate that does not match the contract | A near-correct percentage applied consistently across many transactions of one type | Medium. It repeats, so it compounds every day it runs |
| Duplicate fee | One event charged twice | Two identical fee lines, same type and timestamp, on one transaction | High. Pure loss, and clean to dispute if caught early |
| Timing violation | A correct amount in the wrong window | A charge whose date sits outside its contracted or effective window | High. The dispute window can close before an amount-only check ever flags it |
| Markup drift | A margin that widens over time | A rising effective rate on a stable transaction type across months | Low per month, large over a year. Only a trend view catches it |
The point
Detecting fee leakage is not a matter of vigilance or better spreadsheets. It is a structured read of one comparison, expected against actual, per transaction, with four known signals and an order that catches the expensive ones first. Once the read is defined this way, it can be run continuously instead of sampled quarterly, which is the difference between catching an error inside the window to recover it and finding it after the money is gone.
That is the job Bluefyn is built for. Bluefyn reconstructs the contract into an expected charge for every transaction, compares it to what was actually charged, and flags each of these signals for you to act on. It analyzes transaction and provider data. It never moves, holds, or custodies funds.
Frequently asked questions
What is the best way to detect fee leakage?
Compare what each transaction should have cost, under your contract, against what the provider actually charged, on every transaction rather than a sample. That single comparison surfaces the discrepancy. Read the gap for four signals: a rate deviation, a duplicate fee, a timing violation, and markup drift. Check them in that order, because it puts the errors that are easy to see and expensive to miss first. The method does not depend on tooling, but at volume it depends on checking every transaction rather than a sample.
Can you detect fee leakage manually, or do you need automation?
You can detect it manually, and for a small volume of transactions doing it by hand is the best way to learn the signals. The limit is volume. Past a few thousand transactions a month, a manual or spreadsheet check can only sample, and the errors outside the sample stay uncaught and age out of the window to dispute them. The signals are the same at any scale. What changes is that every transaction has to be checked, which is where an automated comparison replaces the manual one.
How is detecting fee leakage different from auditing for it?
Detection is the single act of comparing one charge against its expected cost and reading the gap. An audit is the program that runs detection on a schedule: how often it runs, who owns it, and how it samples. Detection is the mechanic; the audit is the routine that applies it. A common failure is running a thorough audit too rarely, so real errors are found only after they have settled and passed the window to recover them.
What data do you need before you can detect fee leakage?
Two things, lined up per transaction. First, the actual charges the provider billed, at the level of the individual transaction rather than a monthly total. Second, the expected cost for each of those transactions, computed from the contract. The second is the harder one, because a contract prices conditions rather than transactions, so resolving it into a per-transaction number is a task in itself. Once each transaction has an expected figure beside its actual charge, detection is reading the difference.
