RECONCILIATION · THREE OF FOUR
The same payment reported twice, and the refund that follows
Your provider reports a capture. Your ledger reports the same capture. If a comparison adds both, the order appears overpaid by exactly its own value — and somebody goes looking for a refund to issue.
Why this one is dangerous
The other mismatches produce a number nobody trusts. This one produces a number that looks completely plausible, together with an obvious action, and the action is wrong.
An order of €120 that appears to have received €240 does not look like a data problem. It looks like a customer who was charged twice, which is the kind of finding an operations team treats as urgent and acts on quickly. The refund goes out, and now the order really is underpaid — by a payment that never existed.
The tell-tale detail is that the apparent overpayment is exactly the order total, to the cent. A genuine duplicate charge can have exactly the same amount. Compare provider operation identifiers and source records; the amount alone cannot distinguish the two cases.
How to tell it is this one
Two records referring to the same operation identifier, from two different sources.
Not two payments of the same amount — two records of the same operation. Provider reference, transaction id, authorisation code: whichever your two systems both carry. If that identifier appears twice, you are looking at one event described twice, not two events.
What to do
Decide, once, which source is authoritative for each kind of record, and write it down.
This is the part that cannot be automated away, and it is worth being blunt about it: nothing that compares records can work this out for you. There is no fact in the data that says which system to believe. Two records agree; the question of which one counts is a decision your organisation makes, not one the data contains.
Write it down because the person who reconciles next month is not the person reading this, and the decision has to survive them.
This is one of four
A mismatch between an order system and a payment provider takes four shapes. Each needs to be checked against the source records and may need a different response — which is why the week gets spent arguing about which system is wrong.
IF YOU WANT THIS DONE FOR YOU
I build software that does this,
and I take engagements on it.
You send anonymised order, capture and refund records. I return the findings with evidence your engineers can recompute offline, without the tool that produced them.