Interchange reconciliation, down to the transaction
Recivr parses and consolidates Mastercard's IP755120 and the Visa interchange reports, resolves every row back to your transactions, and reconciles them against what the engine calculated.
- Both schemes and all your BINs and ICAs in one consolidated view
- Per-transaction interchange with the rate and designator that set it
- A daily deviation in basis points, and a per-transaction match rate
Settlement check
shaded days the files do not cover end to end — shown, but not compared and not in the totals.
In the documents
€18,869.98
42,395 records
We calculated
€18,862.44
6 covered days
Deviation
0.4 bps
−€7.54 · 99.0% identified
Resolution
Thousands of cryptic rows become an attribute of a payment
Interchange is technically per-transaction and practically unusable: scheme-specific formats, keyed on identifiers that mean nothing to your merchant records. Recivr resolves those rows back to your transactions, so interchange stops being a file on a server.
- Row-level parsing across both schemes' formats
- Identifiers reconciled to your merchants, BINs and ICAs
- The interchange designator and rate carried onto the transaction
Per-transaction match
| Txn | IRD | Document | Calculated | Δ |
|---|---|---|---|---|
| …631109 | EW1.150000% | €0.230000 | €0.230000 | — |
| …774218 | CI1.450000% | €1.716800 | €1.716800 | — |
| …903472 | 751.150000% | €0.529700 | €0.529700 | — |
| …118840 | A10.200000% | €0.084200 | €0.084712 | +0.0005 |
Where the two disagree, the difference points at a specific transaction, rule and rate — not at a total.
Clearing timing
Compare only the days the files actually cover
A transaction usually clears the day after it happens, so a day is only whole once the following day's report has arrived. Comparing part of a day's documents against all of your transactions reads as an overcharge that is really an absence.
- Fully covered days compared; partial days shown but excluded
- Coverage stated explicitly rather than buried in a footnote
- Deviation measured on a like-for-like basis, in basis points
Settlement check
shaded days the files do not cover end to end — shown, but not compared and not in the totals.
In the documents
€18,869.98
42,395 records
We calculated
€18,862.44
6 covered days
Deviation
0.4 bps
−€7.54 · 99.0% identified
What you get
From raw clearing files to a defensible position
Ingestion
IP755120 and Visa interchange reports collected, parsed and version-tracked.
Consolidation
Both schemes, every BIN and ICA, normalised into one interchange view.
Attribution
Every row resolved to a transaction, a merchant and an interchange designator.
Reconciliation
Calculated against documented, per day and per scheme, with a bps deviation.
Coverage control
Partial clearing days identified and excluded from comparison automatically.
Evidence
A trace from any aggregate down to the source row that produced it.
Why it matters
Pass-through you can prove is pass-through you can price
IC++ only means something if the IC part is right. A merchant being billed interchange as a pass-through is entitled to assume the number came from the scheme, and you are exposed if it did not.
Reconciling calculated interchange against the schemes' own documents turns that assumption into evidence — per day, per scheme, and per transaction.
It also means a difference is a finding rather than a mystery: every remaining gap names the transaction, the rule and the rate behind it.
FAQ
Interchange reconciliation questions
Which clearing reports does Recivr parse?
Mastercard's IP755120 interchange reports and the Visa interchange reports, ingested, normalised and consolidated into a single transaction-level view across both schemes and all your BINs and ICAs.
Why is per-transaction interchange so hard without this?
It is technically present in the raw clearing files and practically unusable — thousands of cryptic rows per file, scheme-specific formats, keyed on identifiers that mean nothing to your merchant records. Recivr resolves those rows back to your transactions so interchange becomes an attribute of a payment rather than a file on a server.
How do you handle clearing timing?
A transaction usually clears the day after it happens, so a day is only whole once the following day's report has arrived. Recivr compares only fully covered days and marks partial ones explicitly — otherwise part of a day's documents against all of your transactions reads as an overcharge that is really an absence.
What does a match look like?
Per transaction: the interchange the scheme charged, the rate and interchange designator behind it, what Recivr calculated, and the difference. Aggregated up, a daily and per-scheme position with a deviation in basis points and a per-transaction identification rate.
The rest of the platform
One engine, several surfaces.
Every product below runs off the same priced transaction events.
Real-time cost engine
Interchange and every scheme fee calculated in under 50 ms, at authorization, capture, refund and chargeback.
Pricing management
Set how each merchant is priced by region, card type, amount and currency, and see the margin on every transaction.
Merchant analytics
Scheme cost in basis points by merchant, MCC, card product and region, so under-priced merchants stand out.
Invoice reconciliation
Visa and Mastercard invoices matched line by line against calculated fees, with every difference traced to its rule.
Rule change monitoring
Visa and Mastercard releases and bulletins mapped in with effective dates, so you see what each change costs before it is billed.
Send us a clearing file
Give us an IP755120 or a Visa interchange report and a matching day of traffic. We will return the reconciled position, per transaction.