Processor report, settlement file or bank statement? The source of truth for each field.

The short answer

There is no single source of truth for a payment. Each field has its own authoritative source, and reconciliation is the work of checking the others against it. Your own ledger is authoritative for what you asked for. The processor is authoritative for its own identifiers and what it says it did. The settlement file is authoritative for what the provider paid you and what it deducted. The bank statement is authoritative for whether cash moved, and when.

Trouble starts when a team picks one record as “the truth” for everything. Pick the processor report, and you will believe payments that never settled. Pick the bank, and you won’t know which payments a batch credit contains.

Four records of one payment

The field map

Use this as a starting point, and agree it with finance before you build matching rules on it.

The keys that connect the records

A field map only helps if you can tell which records belong to the same payment. That depends on identifiers, and each record carries different ones:

Store every identifier you receive against the payment, as it arrives. The processor id links your ledger to the settlement file; the batch id links the settlement file to the bank. If any link in that chain is missing, matching falls back to amounts and dates, which is where false matches come from.

A second example: whose fee is right?

Say your contract with a provider sets a 1.2% fee. The processor’s report shows the fee per payment rounded to two decimal places, the settlement file shows one fee line per batch, and the two differ by 0.84 across a batch of 700 payments.

The map says the settlement file is authoritative for the fee charged, because that is what was actually deducted. Your contract is what you check it against. The 0.84 is rounding: the processor rounds per payment, the settlement file rounds once per batch. Record the tolerance that accepts it, with the reason, and it is explained. Had the difference been 1% of the batch, the same check would have found a fee applied at the wrong rate.

Why the three records disagree

• Timing. The processor reports in real time, the settlement file the next morning, the bank after its own cut-off. The same payment belongs to different days in each.
• Gross and net. The processor shows the payment amount; the settlement file and bank show amounts after fees, refunds and reserves.
• Batching. The bank shows one credit for many payments, so it cannot confirm any single payment on its own.
• Time zones. A provider working in UTC and a bank working in local time will disagree about which day a late-evening payment belongs to.
• Corrections. Processors revise statuses, and providers send corrected files, after the original records were read.
• Rounding. FX and percentage fees round differently at different stages.

Rules for resolving a disagreement

1. Never overwrite. Keep every record as it arrived. A later record adds evidence; it doesn’t replace the earlier one.
2. Rank by question. Ask which field is in dispute, then look up its authoritative source in the map.
3. Log tolerances. If you accept a rounding or timing difference, record the rule that allowed it, every time it is used.
4. Set expectations. For each source, know what should arrive and by when, so a missing record is noticed.
5. Leave it open until proven. A payment with a claim but no settlement or cash evidence is open, however confident the processor sounds.

A worked example

Say your processor’s report shows 1,000 payments paid on 30 September. The next morning’s settlement file lists 998 of them in the 1 October batch, net of fees, and the bank shows one credit for that batch net on 1 October. Two payments are missing from the file.

For those two, the processor’s paid status is only a claim. Checking the provider’s cut-off shows both were captured at 23:40 UTC, after the batch closed, and they appear in the 2 October file. They were never missing: they belonged to another batch. Without the cut-off rule, they would have been two false breaks. Without the settlement file, they would have been counted as cash a day early.

Balances held at a provider

Some providers hold money for you: a payout float you prefund, a reserve they keep, or collections waiting to settle. For those balances, the provider’s own balance statement is the authoritative record of what it says it holds, and your ledger is what you check it against.

Reconcile the balance, not only the payments. Your opening balance, plus money you sent in, minus payouts made, minus fees and reserves, should equal the provider’s closing balance. When it doesn’t, and no single payment explains the gap, you have an unexplained position: often a fee or adjustment the provider booked without telling you, or a payout it made that you have no record of. Those are the breaks that stay hidden longest when only individual payments are matched.

With more than one provider

The map stays the same when you add providers, but each provider needs its own row of details: which report is its settlement file, which identifiers it echoes back, its time zone and cut-off, and how it reports fees, refunds and reserves. Write these down per provider before the second one goes live. The most common mistake is assuming the second provider behaves like the first because its report has similar column names.

Setting it up: a checklist

1. List every record you receive for a payment, by provider, with when it arrives.
2. Agree the authoritative source for each field with finance, and write it down.
3. Store every identifier each record carries, as it arrives.
4. Record each source’s time zone and cut-off as configuration, not as knowledge in someone’s head.
5. Set an expectation for each source: what should arrive, and by when.
6. Decide which tolerances you accept, who owns them, and log every use.
7. Treat every disagreement as an exception with evidence, never as an overwrite.

How Flominzo records it

Flominzo Recon keeps each record as evidence with a grade, INTERNAL, CLAIM, SETTLEMENT or CASH, and with its source and time of arrival. Matching rules, tolerances and expectations are versioned configuration, including each source’s time zone and cut-off. When sources disagree, the difference becomes an exception with the evidence attached, and no record is overwritten.

Questions

Related guides