Summary
A settlement discrepancy is what is left over when the money that arrived and the money that was claimed do not agree. Establishing that a difference exists takes a subtraction. Establishing what produced it is a search — and in a company that settles physical commodity trades, that search is where a settlement team's month actually goes.
This article sets out why settlement differences are usually disagreements between two records that are each internally correct, why the effort of attributing a difference grows much faster than the effort of detecting it, why the input this process depends on most is the one whose format you do not control, why an open difference becomes harder to resolve as it ages on both sides at once, and why a write-off threshold is the most likely place for a systematic loss to be sitting undisturbed. It is written for the people who do this work — settlement, treasury and finance — for the middle office that has to explain a receivable that no longer agrees with the bank, and for anyone who has been asked why last quarter's unallocated cash is still unallocated.
If you want the mechanism, start with Both records are correct, which is why nobody is wrong. If you already accept that and want to know why the work does not get easier with practice, start with Detection is a subtraction; attribution is a search.
Both records are correct, which is why nobody is wrong
A settlement discrepancy is rarely an error. It is two parties applying different conventions to the same event and each arriving, correctly, at a different number.
This is the property that separates settlement reconciliation from ordinary error-checking, and it is the one most process design gets backwards. When your receivable says one thing and the remittance says another, the instinctive move is to look for the mistake. Usually there is no mistake to find. The counterparty applied a deduction their contract copy entitles them to. Their bank took a charge on a cross-border transfer and yours did not. They paid on the value date their terms compute from a document you both hold, and you computed it from a different clause of the same document. They netted a payable of theirs against a receivable of yours because a master agreement says they may. Each of these produces a difference between two records in which neither record is defective.
The consequence is worth stating plainly, because it changes what the work is. "Who made the mistake" has no answer, and asking it produces an argument. "Which convention differs" has an answer, and asking it produces a resolution. A team that treats every difference as a suspected error spends its time proving its own numbers, which were never in doubt, to a counterparty who is doing exactly the same thing on the other side of the same difference.
There is a second consequence that is easier to miss. Because most differences are conventional rather than accidental, they are repeatable. An error is a one-off; a convention difference occurs on every settlement to which that convention applies. A discrepancy investigated and closed without recording why it occurred will present itself again next month, be investigated again from scratch, and be closed again — and the fact that it was the same difference is the piece of information that never gets stored.
Detection is a subtraction; attribution is a search
Finding that a difference exists costs the same whether you settle a few trades or a great many. Finding out what caused it does not — it depends on how far the incoming payment has departed from being one payment for one obligation.
When a counterparty pays one invoice with one transfer for the full amount, there is no search. The payment carries its own identity. Reconciliation is a lookup, and it is genuinely close to free.
That arrangement is not what most physical settlement looks like. A payment arrives covering several cargoes. It is short by an amount that is not itemised. It has had a claim offset against it that was agreed by two people on a call. It has been converted through a currency somewhere along the way. Part of it relates to an invoice you have already credit-noted. Now the question "which obligations does this money discharge, and why is the total not what we asked for" is no longer a lookup. It is a search over combinations — of items, of possible deductions, of plausible reasons — and the number of combinations to consider grows much faster than the number of trades.
This is why settlement reconciliation is the back-office step where adding people helps least and helps last. Two people do not halve a search whose branches depend on one another; they duplicate the early branches and then have to reconcile their reconciliations. The thing that collapses the search is not effort, it is information arriving with the payment: which items it is meant to cover, and what was taken off and why. Where that information is absent, every unit of effort is spent reconstructing something the payer already knew.
It also explains an experience that is otherwise puzzling. Settlement work does not get proportionally easier as a team becomes more experienced, even though almost every individual step in it is routine. The routine part is the arithmetic. The part that consumes the time is the part where somebody has to work out what happened, and that part is new every time even when the answer turns out to be old.
The remittance advice is the only input to your back office whose format is decided by someone else
Every other document in the settlement chain is one you can standardise. The one that determines how much work a payment creates is written by the person paying you.
Consider what a company can actually control. It can fix its invoice template, its approval flow, its file naming, its ledger structure, its close calendar. It can insist that its own operations record laytime in one place and one way. All of that is internal, and all of it responds to internal discipline. Then a payment arrives, and with it — or not with it — an explanation of what it is for, in whatever form the counterparty's own systems happened to emit: a structured file, a spreadsheet attachment, a scanned page, a line of free text in a bank field with a character limit, an email from a person, or nothing at all.
A process whose critical input arrives in a format set by an external party cannot be fixed by tightening the process. This is the structural reason settlement reconciliation resists the improvement methods that work elsewhere in the back office. The step is not badly designed. It is downstream of a boundary the company does not sit on both sides of.
What follows from this is narrower and more useful than "improve the process". Two things are available. The first is to negotiate the input where you have the standing to do so — remittance detail is a commercial term like any other, and a counterparty who is asked for it during contracting will usually provide it, while a counterparty asked for it during a dispute has less reason to. The second is to capture whatever does arrive, in whatever form it arrives, in a place that is not a person's mailbox — because the single most expensive version of this problem is not an unhelpful remittance advice, it is a helpful one that nobody can find later.
An open difference ages on both sides, and you only control one of them
The cost of a discrepancy is set mainly by how long it stays open, and the reason it gets harder is happening at the counterparty as much as at your own desk.
The internal decay is familiar. The person who raised the invoice moves on, the context stops being fresh, the surrounding items settle so the difference no longer has neighbours that explain it. But the decay that decides the outcome is external and invisible from here. On the other side, the person who authorised the deduction changes role. The correspondence that would have explained it sits in an account nobody now opens. The counterparty's own period closes and their view of the item hardens into a written-off or accrued figure that someone would now have to reopen. By the time an aged item is finally worked, you are not asking somebody to look something up. You are asking them to reconstruct it, at a moment when their incentive to do so is at its weakest.
That asymmetry has a practical implication that runs against the usual triage instinct. The natural way to prioritise open items is by size — work the big ones first, because that is where the money is. But the resolvability of an item is falling on a clock you cannot observe, and it falls for small and large items alike. The variable that predicts whether a difference will ever be recovered is how quickly somebody asked about it, not how much it was worth. A queue worked strictly in size order systematically converts small differences into permanent ones, and it does so quietly, because an item that was never going to be chased does not announce that it has expired.
The uncomfortable version of this: an item written off at the year end may have been recoverable at the moment it appeared and not recoverable by the time anyone looked — and nothing in the write-off itself records which of those two it was.
A write-off tolerance is a per-item test applied to a portfolio-level phenomenon
Small differences are waved through one at a time by a rule that never looks at them together — and a difference caused by a convention is small every time, by construction.
Every settlement operation has a threshold below which a difference is not worth pursuing, and having one is correct. The pursuit costs real time; below some level the pursuit costs more than the difference. The problem is not the existence of the threshold. It is that the test is applied to each item in isolation, while the thing it is supposed to protect against does not occur in isolation.
Two kinds of difference sit below any threshold. The first is random: rounding, a small charge, a fractional quantity. Random differences have no sign — some are in your favour, some are not — and over many settlements they largely cancel. The second kind is systematic: a currency conversion convention, a bank charge always borne one way, a deduction one counterparty always takes, a quality adjustment computed to a different decimal by an established habit. A systematic difference has a sign, it recurs on every applicable settlement, and it is sized by a convention rather than by chance — which means it can sit permanently below a threshold that was set to catch mistakes.
The test that separates them is not the size of any single item. It is whether the small differences, added up over a period and grouped by counterparty, sum to something near zero or to something with a direction. If they have a direction, they are not tolerance; they are a price you are paying, and the threshold is the mechanism that keeps you from noticing. A write-off rule that is never audited in aggregate is not a control. It is a channel.
Almost no operation can answer this question quickly, and the reason is a data one rather than an analytical one: differences dismissed below tolerance are frequently not recorded as differences at all. They are absorbed at the point of matching, and what is stored afterwards is a clean match. The information required to detect a systematic leak is destroyed by the step that decides the leak is too small to matter.
"Unreconciled" is four different situations wearing one label
A cash difference and an unidentified receipt are opposite problems, and a queue that calls both of them unreconciled has thrown away the distinction that tells you what to do next.
There is a difference that is understood and disputed: the counterparty short-paid, said why, and you disagree. That is a commercial matter with a named owner on both sides, and it is arguably not a reconciliation problem at all.
There is a difference that is understood and accepted: they short-paid, said why, they were right, and your own records need to be corrected. That is a bookkeeping action, and the only thing that makes it linger is that nobody is quite sure who is allowed to make it.
There is a difference that is not understood: money is short and no reason accompanied it. This one is time-critical, for the aging reasons above, and it is the only one of the four where speed genuinely changes the outcome.
And there is money that arrived and cannot be attached to anything: an unallocated receipt. This is the most dangerous of the four and it is treated as the least urgent, because it does not look like a loss. An unallocated receipt makes two figures wrong at once — the receivable is overstated and the cash is unexplained — and it is the only category of exception that a company has a mild incentive not to chase. It also has a habit of turning out to be a payment for something that was never invoiced.
The failure is not that these are hard to tell apart. It is that most systems record a single state, and it is the state of the arithmetic, not the state of the claim.
What actually produced the difference
| Cause | Which record is right | Where the answer lives | Does it recur |
| An agreed deduction the payer applied without itemising it | Both, on their own terms | The correspondence in which it was agreed | Only if the same claim recurs |
| Bank and intermediary charges | Both | The payment instruction and the terms that allocate charges | Every time, for that route |
| Currency conversion on a differently computed rate or date | Both | The contract's conversion clause, read by two parties | Every time, for that counterparty |
| A payment netted across several obligations | Both | A master agreement, plus the payer's internal allocation | Every time, once netting is in use |
| A payment made against a superseded document | The payer's, at the time they acted | The document trail, in the order it was issued | Whenever a document is revised late |
| A claim offset that was agreed verbally | Neither, until it is written down | A person's memory, until it is not | Until it is recorded |
| A quantity or quality figure resolved differently on each side | Both, from different measurements | The survey or laboratory result each side relied on | Whenever the two sides use different sources |
| An amount paid for something never invoiced | Neither record is complete | Nowhere yet — this is the one to escalate | Symptom of an upstream gap |
Two things are visible in this table and in no individual exception. The first is that the second column almost never contains a single winner, which is why "raise it with them" is not a method. The second is the fourth column: it separates the differences that will keep happening from the ones that will not, and it is the only column that tells you whether the item in front of you is a task or a symptom. Most exception queues do not carry that column at all.
Four states, four different next actions
| Understood and disputed | Understood and accepted | Not understood, money short | Money received, unattached | |
| What it is | A commercial disagreement | A correction owed to your own ledger | An investigation | An identification |
| Who has to act | The commercial owner of the relationship | Whoever may adjust the receivable | Whoever can reach the payer while they still remember | Whoever can match it, and failing that, whoever can ask |
| What time does to it | Little; the positions are on record | Little, apart from the close it delays | Destroys it, on the counterparty's clock as much as yours | Makes it look increasingly like a windfall |
| How it usually ends badly | It quietly becomes an aged item nobody owns | It sits pending a decision nobody realises is theirs | It is written off, correctly, having been recoverable earlier | It is left, because it does not present as a loss |
| What it means if you have many | A contract or a claims process is producing them | Your own conventions differ from the market's | Your remittance information is inadequate | Something is being paid for that you are not billing |
The bottom row is the one worth sitting with. Each of these four, in quantity, is a signal about a different part of the business, and none of the four signals survives being merged into a single count of open exceptions. A company that reports its reconciliation health as one number has arranged not to receive any of them.
Three questions your own settlement file should be able to answer
These are not audit questions. They are questions about whether the facts are stored or reconstructed.
One: for the differences you closed below tolerance in the last period, what do they add up to, and by counterparty, do they have a sign? If the answer cannot be produced because those differences were absorbed rather than recorded, that is the finding. The absence of the data is the same shape as the risk.
Two: for a difference currently open, can you say what it is waiting on and whose desk that is — without opening a mailbox? Not "waiting on the counterparty". Which fact, held by which party, and when it was last asked for. If it takes an email search to answer, the item is not being tracked; it is being remembered, and by one person.
Three: can you list the cash you have received and not yet attached to anything, ordered by how long it has been sitting? If producing that list is a piece of work rather than a query, then between the times you build it the list does not exist — and unallocated cash is precisely the category that nobody complains about while it accumulates.
Questions people ask about this
Why do we still have discrepancies when both sides are working from the same contract?
Because a contract does not fully determine a settlement figure. It leaves conventions to be applied — which rate on which date, which measurement governs, how charges are allocated, how a claim already agreed is presented — and two competent teams applying those conventions from different systems will produce different numbers without either misreading the document. This is why the productive question is which convention differs rather than who is wrong.
Should we chase the biggest differences first?
Size is the obvious priority and it is not the right one on its own. What determines whether a difference is recoverable is largely how quickly you ask about it, because the ability of the counterparty to explain it decays on their side too. A queue ordered purely by value systematically lets small items pass the point of recovery. A more defensible order works anything unexplained quickly regardless of size, and lets the understood items — disputed or accepted — take the time they need.
Is settlement reconciliation the same thing as invoice reconciliation?
They are adjacent and worth separating. Invoice reconciliation asks whether what you asserted matches what your counterparty accepted. Settlement reconciliation asks whether the cash that arrived matches what was owed, which can differ for reasons that have nothing to do with the invoice — netting, charges, conversion, an offset claim, a payment against a superseded document. Conflating the two produces a process that cannot tell you whether the problem is with your claim or with the payment.
How small is too small to chase?
The per-item question is the wrong one to answer first. Set the threshold wherever the economics of pursuit put it, but audit what falls below it in aggregate, by counterparty and by period. Random differences will roughly cancel. Anything with a persistent direction is not a tolerance being used as intended; it is a recurring convention difference, and its size per item is exactly why it has never come up. The threshold is defensible; a threshold nobody looks underneath is not.
Our counterparty pays one amount for several cargoes. How should we handle that?
Treat the allocation as a fact to be obtained rather than derived. Deriving it — working out which combination of open items sums to the amount received — is the search that makes this work expensive, and it produces an answer that is plausible rather than confirmed. Asking for remittance detail is cheap by comparison, and the best moment to ask is while the commercial terms are being agreed, not after a payment has already arrived without it.
We reconcile everything at month end. Is that not enough?
It is enough to produce correct accounts and not enough to recover money. A periodic cycle means an unexplained difference is not looked at until the cycle it arrived in has closed, and that wait is spent on the far side of the decay described above. It also concentrates the work into the days when the team has the least capacity. The accounting outcome and the recovery outcome are being served by one activity, and only the first of them is well served by doing it at the end.
What is the first thing to fix if this runs on spreadsheets and email?
Not the spreadsheet. Start by recording the difference itself as an object with a cause and an owner, including the ones you close below tolerance. Most operations record the match and discard the exception, which makes the two most valuable questions — is this the same difference as last month, and do our small differences have a direction — unanswerable at any level of effort. The tool holding the result can stay where it is while you make that change, and making it will tell you whether the tool was ever the constraint.
Does this improve as we grow?
Not on its own, and one part of it gets worse. Volume increases the number of open items, but the harder effect is that scale usually brings netting, more counterparties with their own remittance habits, and more currencies and payment routes — which is to say, it increases the departure from one payment for one obligation, and that is the variable the attribution work depends on. What does change with scale is that the cost becomes visible enough to act on. The work of fixing it is the same at any size: capture what arrives with the money, and record what the difference was.
Where this lands in a trading system
Nothing above is an argument for buying software. It is an argument about which facts have to be captured, how early, and in what form. But the conclusions do map onto system capabilities, and it is worth being specific about which ones — and about where the mapping stops.
The first conclusion is that a settlement difference can only be attributed when the claim, the underlying trade and the cash position can be seen against one another. That is what a CTRM/ETRM system providing complete trading lifecycle management for commodity traders, integrating physical trade, financial hedging, risk control, and settlement in one platform is for; Time Dynamics' Fusion is one, and the capability that bears on this article is automated financial settlement and payment processing.
The second conclusion is that the input that decides how much work a payment creates does not originate in that system and never will. Remittance advices, bank statements, counterparty portals and the spreadsheets in which a team already tracks its open items all sit outside it. That is a different problem, and it is the one X-Ray addresses: a non-invasive data processing and analysis platform, whose collection toolkit XDK performs non-invasive automated data collection from databases, Excel files, and web interfaces, and which is built to collect data without disrupting existing systems or workflows. The last property is the one that matters here, because the spreadsheet holding your open differences is working, and the plan cannot begin with replacing it.
The third conclusion is that the two questions this article ends on are re-cuts of the same underlying items — by counterparty, by cause, by age, by whether the small ones have a direction — and that they have to be produced often enough to act on rather than assembled once a period. X-Sheet does one-click generation of personalized reports with Excel-like interface.
There is a fourth conclusion, about ageing, where the mapping needs care. X-Eagle is described as real-time risk alerts and monitoring for trade finance field warnings. That is a shape — a watched field, a condition, a warning raised while there is still time to act — and it is a shape that fits an open difference passing an age at which recovery starts to get harder. Whether it is pointed at a settlement exception queue is a configuration question rather than something a platform decides for you, and it is worth saying that the description above is written about trade finance fields, not about this queue.
And here is where it stops. None of this is an accounts receivable or cash application system. It does not decide whether a deduction your counterparty applied was justified, it does not settle a dispute, it will not obtain a remittance advice that was never sent, and it will not make anyone pay. It does not set your write-off policy, and it should not: where the threshold sits is a commercial judgement about the cost of pursuit, and the point made above is only that somebody should be adding up what falls beneath it. It also has no standing to interpret what your contract entitles either party to deduct — that is a document two companies negotiated. What a system can settle is narrower and duller than the problem described here: whether the difference was recorded with a cause, whether the money that arrived can be seen next to the claim it was meant to discharge, and whether anyone has to open a mailbox to find out. That is most of the distance between a reconciliation process and a reconciliation rebuild, but it is not all of it, and it is worth being clear about which part you are buying.
See the products → · Talk to us about settlement data →
A note on the evidence in this article
This article contains no statistics, and that is a decision rather than an omission. The observations behind it — which steps in the trade lifecycle are still run on spreadsheets and email, which of them carry costs that land directly in cash, and how much of a settlement team's time goes into establishing what happened rather than into applying judgement — come from material we are not in a position to publish as a citable figure. A number we cannot source would make this argument look stronger and would make it worth less.
So the argument is structural instead: each claim is made from the mechanism, and each is stated in a form you can test against your own operation rather than take on our authority. The three questions above are the intended way to use it. If your own settlement file contradicts what is written here, your file is the better evidence.