Your agreement with your payment service provider (PSP) sets out the pricing. The invoice sets out the charges. Checking one against the other sounds like a comparison, and every finance team describes it that way.
It is not a comparison, and that is why it keeps failing.
The contract does not contain the price of your transaction. It contains the rules that produce that price once somebody supplies the transaction. Until those rules are evaluated, there is no expected number, and there is nothing to compare the invoice against.
TL;DR
- A provider contract prices conditions, not transactions. It says what the rate is when certain things are true. What any given payment costs is a separate calculation.
- Six inputs have to resolve before an expected cost exists: the applicable rate rule, volume tier position, minimum-fee status, true-up applicability, the contract version in force on that date, and any externally set pass-through.
- Tier and minimum resolution are order-dependent, so the same contract prices the 90th transaction of a period differently from the 900th.
- Part of the price is not in the contract at all. Interchange is set by a schedule the provider does not write and you never signed.
- Federal Reserve data shows one interchange rule resolving to 1.50 percent of value or 0.44 percent depending only on the issuing bank, so the rule and the number are not the same object.
- This means reconstructing pricing rules and evaluating them. Interpreting a contract is a different job, and ambiguity belongs to a human.
Short answer
A signed provider contract becomes a per-transaction check when its pricing rules are reconstructed as conditions, bound to the attributes of each transaction, and evaluated to produce an expected cost that can be compared against what was actually charged. Six inputs have to resolve first: the rate rule that applies to that card type, corridor and transaction type; the cumulative volume tier position at that moment; minimum-fee status for the period; whether a true-up applies; the contract version in force on the transaction date rather than today; and any charge the contract passes through at cost, which is priced by an external schedule. Two of those, tier position and minimum status, are order-dependent, so evaluating at transaction time and recomputing at period end give different answers. The output is evidence only if it is deterministic, traceable to a clause, and aware of which contract version governed the day.
Why "does it match the contract" is the wrong question
Ask a finance team to verify a provider charge and they will open the agreement, find the rate, and compare it to the invoice line. On a simple contract that works. On a payment contract it usually cannot.
Take a single line: 0.35 percent plus 15 cents. That is not the price of a transaction. It is the price of a transaction that is a particular card type, in a particular region, of a particular kind, falling in a particular volume band, in a period where the minimum has already been met, under the amendment that was in force that week. Change any one of those and the same contract produces a different number.
So the reference point a comparison needs does not exist yet. It has to be built, per transaction, before the comparison can happen at all. The contract is the source of truth and it is not a price list.
What has to resolve before an expected cost exists
Six inputs. Each one is a place the check silently produces the wrong answer if it is skipped.
| Input | Where it comes from | What happens when it is missing |
|---|---|---|
| Applicable rate rule | The contract's pricing schedule, selected by card type, region or corridor, and transaction type | No rule resolves, so the line has no expected cost and is unverifiable rather than correct |
| Volume tier position | Cumulative qualifying volume at the moment of the transaction | The tier gets resolved from period totals, so early transactions are priced at rates they had not yet earned |
| Minimum-fee status | Period-to-date charges measured against the contracted minimum | A minimum is charged in a period that already exceeded it, or omitted in one that did not reach it |
| True-up applicability | The contract's reconciliation or adjustment clause | The period closes without an adjustment the agreement requires |
| Contract version in force | The amendment set effective on the transaction date | Transactions are priced against current terms rather than the terms that actually governed them |
| Externally set pass-through | A schedule referenced by the contract but published elsewhere | Expected cost is anchored to a stale schedule and every line inherits the error |
Read that list as a dependency chain rather than a checklist. An expected cost is the output of all six resolving correctly. Five out of six does not give you a slightly less accurate number. It gives you a number that looks precise and is wrong in a direction nobody can predict.
The part of the price the contract does not contain
The last row is different in kind from the other five, and it is the one most verification work quietly ignores.
When a contract passes a charge through at cost, it is not setting that price. It is pointing at a schedule somebody else maintains, on somebody else's revision calendar. Interchange is the clearest case: set by the card network, paid to the card-issuing bank, and passed through by your provider.
How much that shifts the arithmetic is measurable, because the regulator publishes its own collection. Under Regulation II, a covered issuer "may not receive, for any electronic debit transaction, an interchange fee that exceeds $0.21 plus 0.05 percent multiplied by the value of the transaction, plus a $0.01 fraud-prevention adjustment, if eligible." The regulation text fixes the ceiling as the sum of "21 cents" and "5 basis points multiplied by the value of the transaction." Issuers outside that standard are exempt, and exempt interchange is uncapped.
In the Federal Reserve's 2024 figures, average interchange on Visa dual-message debit ran at 1.50 percent of transaction value from exempt issuers and 0.44 percent from covered issuers. Mastercard ran 1.30 percent against 0.49 percent.
One contractual rule, "interchange at cost", resolving to numbers roughly three times apart depending on which bank issued the card. The rule did not change. The rule was never the number.
Any check that treats "matches the contract" as static will mark a legitimate pass-through as a discrepancy, or miss a real one, depending on which way the mix moved. The related failure, where a blended rate hides all of this, is covered in why an effective rate is not evidence.
Order matters, and that is what makes this hard
Two of the six inputs depend on what already happened in the period, which gives the whole exercise a property most reconciliation work does not have to deal with.
Volume tiers resolve against cumulative volume. Minimums resolve against period-to-date charges. Both mean a transaction's correct price depends on its position in the sequence as well as on its own attributes. Under one unchanged contract, the 90th transaction of a month and the 900th can carry different rates, correctly.
The practical consequence is that evaluating at transaction time and recomputing at period end are different operations that produce different answers, and both can be defended. A verification that does not state which one it performed has not produced a checkable result. Doing this by hand, one period at a time, is the true cost per transaction exercise; the difficulty is that it has to hold for every transaction rather than a sample.
What turns the output into evidence
A number that disagrees with an invoice is not yet a finding. It becomes one when three things are true of how it was produced.
It is deterministic. The same transaction, the same contract version and the same schedules produce the same expected cost every time it is run. A figure that cannot be reproduced cannot be defended in the conversation it exists for.
It is traceable to a clause. Every expected cost points at the specific contract provision that priced it and the transaction attributes that selected that provision. "Our system says 0.32 percent" is an assertion. "Section 4.2, tier two, card-not-present, under the amendment effective 1 March" is evidence.
It is version-aware. The comparison uses the terms that governed the transaction on its own date. Pricing an eleven-month-old transaction against today's amendment produces a discrepancy that is entirely your own creation.
The same per-transaction check is what lets a team lower its reconciliation cost without losing rigour.
Those three properties are also what make the result survive being shown to the counterparty, which is the only test that matters. Bluefyn reconstructs contract pricing and checks fees transaction by transaction against it, on a canonical event ledger of what actually happened. Bluefyn never moves, holds, or custodies funds; it only analyses transaction and provider data.
What this is not
Precision about the claim matters here, because the adjacent claim is much larger and much less defensible.
This is not automated interpretation of a legal agreement. The pricing terms of a provider contract are a set of conditional rules, and reconstructing those rules as conditions is a bounded, mechanical job. Interpreting what an ambiguous clause means is not, and it does not become mechanical because it would be convenient.
So the honest division is that structure is machine work and ambiguity is human work. A clause that can be read two ways should be surfaced as a question, with both readings and the money each one implies, rather than resolved quietly by whichever reading the software happened to encode. The verification logic stays deterministic. The judgment stays with the person who is accountable for it.
The bottom line
Verifying a provider charge is not comparing two numbers. It is computing the number the contract requires, then comparing.
That computation needs six inputs to resolve, two of them order-dependent, and one of them defined by a schedule the contract only points at. Skip any of them and you get a figure with the appearance of precision and no defensibility, which is worse than knowing you have not checked.
What makes the result usable is not accuracy claimed for it. It is that the same inputs reproduce it, every line traces to a clause, and the terms used are the ones that governed the day.
A contract you cannot evaluate per transaction is not a control. It is a document.
Frequently asked questions
How do I know if my payment service provider fees match my contract terms?
Not by comparing the invoice to the rate card, because the rate card does not contain the price of any particular transaction. You reconstruct the contract's pricing rules, resolve them against each transaction's attributes, including its position in the period for tiers and minimums, and use the contract version that was in force on that date. That produces an expected cost per transaction. Comparing that against what was charged is the only comparison that means anything, and any difference should point back at a specific clause.
What software can reconcile provider invoices with contract pricing?
The capability to look for is contract reconstruction rather than invoice matching. Tools that reconcile an invoice against a settlement file confirm two records agree with each other, which they can do while both apply a price the agreement never authorised. What is needed is a system that evaluates the contract's pricing rules per transaction, resolves tier and minimum position in sequence, tracks which amendment governed each date, and outputs a variance traceable to a clause. Bluefyn does this for provider charges: it verifies that providers charge exactly what they agreed to charge.
Why can I not just compare the invoice to the rate card?
Because the rate card prices conditions rather than transactions. A single rate applies only when a set of things is true about the transaction and about the period around it. Two transactions of identical value can carry different correct prices under the same contract, so a rate-card comparison either flags legitimate variation as error or accepts real error as legitimate.
What is the contract version in force, and why does it matter?
It is the amendment set that was effective on the date of the transaction, rather than the current one. Provider agreements get amended, and amendments carry effective dates. Pricing historical transactions against today's terms manufactures discrepancies that are artefacts of the method. Any verification covering more than one amendment period has to resolve version per transaction.
Can pass-through charges be verified at all?
Yes, but as a different question. A pass-through is not disputable with your provider, because your provider does not set it. What is verifiable is whether the amount passed through matches the external schedule that applied to that card, corridor and transaction type on that date. Misapplied pass-through is a common and recoverable finding, and it is invisible unless the check resolves the external schedule as of the transaction rather than as of now.
What happens when a contract clause is ambiguous?
It gets surfaced, not resolved. A clause that supports two readings should be presented with both readings and the amount at stake under each, so the person accountable for the relationship decides. Encoding one reading silently turns a judgment call into a number nobody knows is contested, which is the failure mode that makes a verification result impossible to defend later.
Does this need to run on every transaction, or is a sample enough?
Every transaction, because the errors this catches are individually small and structurally repeated. A sample sized to catch large one-off errors is the wrong instrument for a population of tiny recurring ones. It is also the case that tier and minimum resolution depend on the full sequence, so a sample cannot reconstruct the position of the transactions it contains.
