RECONCILIATION · TWO OF FOUR
One payment, taken in two pieces, and neither comparison agrees
A €150 order, captured as €100 and €50. A partial capture, or a retry after a decline, or a split across two payment methods. Compare totals and it reads as a €50 shortfall. Compare the transactions one by one and it reads as an extra payment nobody ordered.
What is actually happening
Both readings can be wrong when a comparison assumes one payment per order.
Comparing totals, the first capture is all you see against the order, so €50 appears to be missing. Comparing line by line, the second capture has no order of its own to belong to, so it looks like money that arrived for nothing. The same event, read two ways, produces two different false findings.
Split captures are normal operation. Partial shipment, an authorisation that could only be taken in part, a second card after the first declined, an instalment. None of these is an error, and all of them break a comparison built on one payment per order.
How to tell it is this one
The captures against one order sum to the order total. That is the whole test, and it is arithmetic, not judgement.
If they sum to the total, the amounts are arithmetically consistent. Still confirm operation identifiers, status, currency and the relevant order revision. If they sum to less, you have a genuine shortfall and it is a different problem. If they sum to more, look for the same capture reported by two sources before you conclude anything.
What to do
Again, nothing to the money.
But notice the more damaging consequence: a comparison that works on totals reports this as a discrepancy every single time it happens. That is how teams learn to ignore the report — not because it is wrong once, but because it is wrong routinely and predictably, until the real finding buried in it goes unread.
A comparison has to group captures by the order before it compares anything. If yours cannot, its output is noise with the occasional signal in it, and nobody can tell which is which.
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.