)
)
A payment gateway settlement will often arrive in Finance as a single net figure. The gateway reports sitting behind it can show what went into that number, from fees and reserve movements to currency conversion and settled refunds, but that detail usually lives in operational systems in formats your team didn't build and can't pull directly into your accounting records with the lineage attached.
So your team has little choice but to go and get it. They cross-reference the reports, match to internal records, trace the differences, and when the next settlement cycle arrives, they have to do it all over again.
That's the reconciliation burden in payments finance and it doesn't ease as you grow. Because the architecture is generating reconstruction work faster than any process change can absorb it; the burden accumulates.
Reconciliation becomes reconstruction
Processor fees, reserve movements, and refund charges typically come netted into the cash settlement. The breakdown is somewhere, maybe in a gateway report, a fee schedule, or an operational log, just not in the same place as the ledger entry it relates to. So when a variance shows up in the bank statement, your controller has to go and find that breakdown, reconcile it manually, and work out what actually happened.
FX costs sit in a similar blind spot. When your team records the amount that landed in the account, the gateway’s charge on the conversion – the spread between the rate you were quoted and the rate you got – often doesn't make it into your accounting system as a separate line. It gets absorbed into an "exchange differences" total, which means Finance can see the outcome but can't tell you what drove it or which transactions it came from.
Returns and reversals make the picture more fragmented still. The original payment, the refund, the settlement reversal, any associated fees, can all move through different systems on different timetables. By the time it all reaches the ledger, your team is often looking at a net refund value with no clear view of the cost chain that produced it.
The underlying detail exists somewhere in the operational stack. What's missing is a governed path from the number in your ledger back to the events and transactions that created it.
Why the gaps keep coming back
Chasing down a small settlement difference costs time, and at high volumes, the cost of investigating it can exceed the amount itself. So your team makes a call, accepts it within tolerance, and moves on, only for the same type of gap to turn up in next month's settlement.
That's the immediate cost: Finance effort spent on work that doesn't move anything forward.
The harder cost is less visible. When your fee deductions, FX spreads, and reversal economics aren't accessible in a controlled record, you can't easily tell which transaction costs are unavoidable and which aren't. You can't isolate where gateway fees are running higher than expected, or whether the spread on a particular currency pair is eroding margins in a specific market. The aggregates are there. The explanation isn't. And without event-level visibility, you can't even be certain how large the opportunity to improve things actually is.
Financial truth, in this context, means being able to move from the number in the ledger back to the underlying events and the accounting treatment applied to them. The data exists in the operational stack. The accounting record reflects what happened without explaining it.
)
)
