Cross-System Reconciliation: Why Nobody Is Waiting for You to Finish It

Summary

Cross-system reconciliation is the work of proving that two systems you own are telling the same story about the same trade. It differs from every other reconciliation in the back office in one respect that decides almost everything else about it: there is no external party on the other side of the difference. No counterparty is waiting for an answer, no payment is being held up, and no clock outside the company is running. The difference is between two of your own records, and the only thing that makes it get resolved is that somebody decides to resolve it.

This article sets out why that missing external pressure is the structural cause of an aged break queue rather than a symptom of an under-staffed team, why "which system is the master" is a question asked at the wrong level, why the join that makes the comparison possible lives in neither of the two systems being compared, why most breaks are questions about time rather than about numbers and why that trains a team into the wrong reflex, why two systems can agree on a total while disagreeing on every line beneath it, and why the ordinary act of closing a break can destroy the only evidence that it happened. It is written for the middle and back office that runs these comparisons — operations, settlement, finance, risk reporting — and for the data and IT people who get asked why the two numbers differ when both systems are working correctly.

If you want the mechanism that produces the ageing queue, start with Both records are yours, so nothing forces the difference closed. If your immediate problem is that a comparison is silently missing rows, start with The join lives in neither system.

Both records are yours, so nothing forces the difference closed

Every reconciliation that crosses a company boundary has someone on the other side who wants it finished. An internal one has nobody, and that absence — not workload — is what produces a queue of aged breaks.

Consider what actually drives an external reconciliation to completion. A counterparty who has been short-paid asks. A bank statement that does not agree with the cash ledger blocks a payment run. An exchange or clearer requires a position to be affirmed by a deadline that is not yours to move. In each case the work gets done because a party outside the company is applying pressure, and the pressure arrives on a schedule the company does not set.

Now take the same shape and put both records inside the same building. The trading system says the book is one thing; the general ledger says it is another; a spreadsheet the operations desk maintains says a third. Nobody is inconvenienced today. No payment stops. No external deadline passes. The difference is real, it is known, and it can sit there indefinitely without producing a single consequence that anyone outside the reconciliation team experiences. A control whose only enforcement is the diligence of the person running it is not a weak control; it is a control operating exactly as designed, in an environment that supplies it with no enforcement at all.

Two things follow that are worth separating from the usual conclusion of "we need more people on it".

The first is that this queue is the first thing to give way when a period gets busy, and it gives way invisibly. Every other back-office task announces its own delay — an unpaid invoice, a missed confirmation, a late report. A reconciliation that was not run, or was run and its breaks not worked, produces no signal at all. The next report still comes out. It is simply less true than it was, and nothing about it looks different.

The second is more uncomfortable. Because both records belong to you, you have an option that an external reconciliation never offers: you can close the difference by changing one of the records. That option is legitimate, it is used constantly and correctly, and it is also the single easiest way for a real problem to be made to disappear without anyone deciding to hide it. We return to this at the end.

"Which system is the master" is a question at the wrong level

The system of record is a property of a field, not of a system. A company that answers the question system-wide will be overriding its own answer within a month, informally, without recording that it did.

The question gets asked in a form that sounds decisive — is the trading system or the ledger the source of truth? — and any answer to it in that form is wrong, because no system is authoritative about everything it holds. The trading system holds the price the desk agreed, and it is right about that. It also holds a delivered quantity, which it received from operations, and about which it is a copy. The ledger holds the posted value, and it is authoritative about what was recognised in which period. It also holds a counterparty name that came from a static data process it does not own. Both systems contain fields where they are the origin of the fact and fields where they are merely the most recent place it was written down, and nothing in either system distinguishes the two.

The practical consequence is that a break cannot be adjudicated at all until somebody names the field-level owner. Until then, the argument about a differing quantity is conducted between two teams who each believe their system is the master, and both are partly right. This is why these disputes are unusually stubborn compared with their financial significance: the disagreement is not about the number, it is about a rule of precedence that was never written down.

There is a further effect that shows up later. When precedence is declared at the system level, exceptions get handled by individuals — the operations lead knows that for delivered quantity you always take the survey figure regardless of what the trading system says, and everyone on that desk knows it too. That knowledge is correct, it is load-bearing, and it exists in nobody's documentation. The reconciliation is not being run by the procedure; it is being run by the person, and the procedure is what remains when the person is not there.

Which record should govern which field

The last row is the one most often mishandled. A derived figure has no owner in the sense the other rows do; two systems computing it differently are not in conflict about data at all. Reconciling it as though it were a stored value produces an argument that cannot end, because neither side has the thing the other is asking for.

The join lives in neither system

Comparing two systems requires a key that maps one system's identifiers onto the other's. That key is almost never inside either system, and its most damaging failure does not appear on the break report.

Every cross-system comparison depends on an artifact that decides what corresponds to what: this book here is that cost centre there, this product code is that commodity, this counterparty short name is that legal entity, this instrument identifier is that contract. The artifact is usually a spreadsheet or a small table maintained by a person, sitting to the side of both systems, referenced by the reconciliation and owned by neither team. It is the most load-bearing component of the entire process and it is the only one with no owner, no test, no change control and no release notes.

Its ordinary failure is bad. Its characteristic failure is worse, because it is not a break at all — it is an absence. When a mapping row is wrong, two things get compared that should not be, and a break appears; somebody investigates and finds it. When a mapping row is missing — a new product, a new book, a newly onboarded entity, an instrument type traded for the first time — the item is simply not compared. It does not appear as a difference. It appears nowhere. The reconciliation runs clean, the report says the systems agree, and the statement is true about everything the mapping knew to look at.

This is the property that makes the artifact worth singling out. A reconciliation reports differences between the things both sides know about; it is structurally incapable of reporting the thing it was never told to look at. Every other break in the queue is a question the process asked and got two answers to. This one is a question the process did not ask, and no amount of working the queue will surface it.

What follows is narrow and worth doing. The reconciliation should reconcile its own coverage before it reconciles anything else: count what each side holds, count what was compared, and make the difference between those a visible output rather than an internal detail. An item present in one system and absent from the comparison entirely is a different category of finding from a difference in value, and it deserves to be reported as one. This costs very little to build and it is the only check that catches the failure the rest of the process cannot see.

Most breaks are questions about time, and that trains the wrong reflex

A large share of what appears on a break report is not a disagreement about a fact. It is two systems being asked what they think at moments they define differently — and the reflex that fits those breaks is exactly the wrong one for the breaks that matter.

Systems disagree about time in several independent ways at once. They have different ideas of when a day ends, which matters for anything traded near the boundary. They record a trade date, a value date and a posting date, and a comparison that assumes any two of those are the same will produce differences that are not differences. They are snapshotted at different moments, so a booking made between the two snapshots is present in one and absent from the other. They handle late entries and corrections differently: one restates the period, the other posts into the current one. None of these is an error, and all of them look identical on a break report to the ones that are.

The reflex this produces is predictable and rational in the short run. If most breaks resolve themselves when the comparison is re-run, then re-running is the cheapest first move, and a team learns quickly that investigation is usually wasted effort. The habit is well-calibrated to the population of breaks. It is also precisely wrong for the minority of breaks that will never clear, because it delays the investigation of exactly those items until they have aged past the point where anyone remembers the context — and, per the section above, nothing external is applying pressure in the meantime.

There is a second effect that is easier to miss and harder to fix. A period with a lot of timing noise is a period in which a genuine error is camouflaged. The error is not hidden by anyone; it is sitting in a list of items that all look like each other, in a list the team has learned to clear by waiting. The cost of timing breaks is not the time spent on them. It is the cover they provide.

The remedy is not to eliminate timing differences, which is usually impossible and sometimes wrong. It is to make the as-of definition an explicit input to the comparison rather than an assumption inside it, so that a break can be labelled by the process — this one is expected to clear on the next run, this one is not — before anybody looks at it. That single distinction changes the queue from a list of items to be triaged by hand into two lists with different handling, and it can be made from the definitions alone, without reference to the amounts.

Agreement at the total is not agreement underneath it

Two systems that match at the level you report can disagree on every line beneath it, and the netting that makes the total agree is not a coincidence — several common causes produce paired differences of opposite sign.

The comparison is usually built at the level the number is used: a book total, a period total, a position by commodity. That level is the one people care about, and matching it feels like the whole job. But the errors that reconciliation exists to catch happen at the level the fact is created — a trade, a delivery, a line on an invoice — and two of them with opposite signs disappear when summed.

Nor is this rare in the way random chance would make it rare. A quantity booked against the wrong contract removes it from one and adds it to another; the two contracts are usually in the same book. A trade booked in the wrong period is missing from one period and duplicated in the next; the year total is fine. A trade attributed to the wrong counterparty, entity or desk is a matched pair of errors by construction. The mechanisms that most often produce a misstatement are mechanisms that move something from one place to another, and a total that spans both places nets them out. A reconciliation performed only at that level is not merely insensitive to those errors; it systematically reports the ones it cannot see as agreement.

The opposite failure is real too, and it is why "reconcile everything at the finest level" is not the answer. A comparison at trade level across systems whose timing and identifiers do not align perfectly produces a break list nobody has the capacity to work, and an unworked list is worse than a coarser one, because it converts a known gap into a false sense of coverage. The defensible position between them is a rule rather than a level: reconcile at least as finely as the level at which a decision gets made from the number. If limits are monitored by book and counterparty, agreement at portfolio level is not enough. If the number is only ever consumed as a total, the total may genuinely be sufficient — but the company should know that this is the choice it has made, rather than discovering it when a compensating pair is found by someone else.

Closing a break can destroy the evidence that it happened

An adjustment that makes one record match the other is the correct action in many cases and it is also indistinguishable, afterwards, from the case where it was the wrong one.

This is the internal reconciliation's characteristic hazard, and it exists precisely because there is no external party. Nobody outside can be adjusted. Inside, the difference can be resolved by moving one of the two records, and once it is moved, the next run is clean. What survives is a corrected figure and a journal entry that looks like ordinary bookkeeping. What does not survive is the fact that the two systems disagreed, what the disagreement was, which side was changed, and why.

The consequences compound rather than cancel. A recurring cause — a mapping that is wrong for one product, a rate convention that differs, a feed that drops a field — produces the same break every period, is closed every period by the same adjustment, and is recorded nowhere as recurring. The team's memory is the only place the pattern exists, and the adjustment is quick enough that nobody experiences it as a problem. The work is being done permanently instead of once, and the artifact that would prove it is generated and discarded on every cycle.

There is also a control dimension, though it is not the main point here. A process in which differences are resolved by adjusting the record and no durable record of the difference is kept has no way to distinguish routine housekeeping from a material correction after the fact — not because anyone concealed anything, but because the distinction was never written down at the moment when it was still obvious.

The fix is small and it is not a system change. Record the break, not just the resolution. A break is an object: what differed, between which systems and which fields, what the cause was, which side was changed and by whom. Keeping that object costs a line per item. Not keeping it makes two questions unanswerable at any level of effort — is this the same break as last month, and how many of last period's breaks were closed by understanding them rather than by overwriting one side.

Six kinds of break, and what each is telling you

Only the first row is a reconciliation problem in the ordinary sense. The other five are questions about time, calendars, granularity, coverage and definitions, and each of them is answered somewhere other than in the numbers. A queue that records only amounts and ages cannot tell these apart, which is why the same list gets worked from scratch every period.

What to check in your own reconciliation

These are not audit questions. They are questions about whether something is written down or held in a person's head.

One: pick a field that has broken more than once — a quantity, a rate, a fee — and ask who owns it. Not which system displays it, and not which team runs the reconciliation: which process is the origin of that fact, such that if the two systems disagree, that one wins by rule and not by argument. If the answer arrives as a system name, the question has not been answered yet. If the answer is a person's judgement, it is being answered correctly and informally, which is the state described above.

Two: find the mapping file the comparison depends on, and ask when it last changed and who changed it. Then ask a harder version: when your firm last traded a new product or onboarded a new entity, what made sure that thing entered the comparison at all? If the answer is that somebody remembered, that is the honest answer, and it identifies the point where a clean report and a complete report stop being the same thing.

Three: of last period's breaks, how many were closed by finding the cause and how many by adjusting one side to agree with the other? Most operations cannot produce this ratio, and the reason they cannot is itself the finding — the second kind is typically not recorded as a break at all. The number is not important. Whether it can be produced is.

Questions people ask about this

Why do our systems disagree at all if they are fed from the same source?

Being fed from one source guarantees a common origin, not a common representation. Each system applies its own rounding, its own conventions for dates and periods, its own treatment of amendments and cancellations, and its own idea of when a day ends. It may also receive the feed at a different moment, or fail to receive part of it without saying so. A shared source removes a whole family of causes — genuinely, and it is worth doing — but the remaining differences are the ones that were always going to be about interpretation rather than about data, and those are the ones that take the time.

Isn't the answer simply to declare one system the golden source?

It is the right instinct at the wrong granularity. No system is the origin of every fact it holds: a trading system is authoritative about the price the desk agreed and a copyholder of the delivered quantity it was told; a ledger is authoritative about what was recognised in which period and a copyholder of the counterparty identity it was given. Declaring one of them master resolves arguments in the direction of whichever system was declared, including the ones where it was wrong. What works is naming the origin per field, and accepting that the list will be untidy.

How often should cross-system reconciliation run?

More often than the reporting cycle, and the reason is not accuracy. A monthly cycle means an unexplained difference is first looked at when the context is weeks old, and — because nothing external is chasing it — that is also the point where it is most likely to be adjusted away rather than understood. Running the comparison more frequently does not increase the total work; it changes the composition of it, because a break found within a day or two is usually still traceable to a specific action somebody remembers taking.

Should we reconcile at trade level or at summary level?

Ask what the number is used for. Reconcile at least as finely as the level at which somebody makes a decision from it: if limits are watched by book and counterparty, agreement at portfolio level does not tell you anything about whether those limits are being applied to correct numbers. Going finer than that has a real cost — a break list too large to work is a false sense of coverage rather than a stronger control — so the point is not that finer is always better. The point is that a level chosen for convenience is a decision about what class of error you have agreed not to detect, and it is worth making that decision on purpose.

Our reconciliation has been clean for months. Is that good news?

It is good news only if you also know what it covered. A comparison reports differences among the items it was told to compare; anything absent from its mapping is absent from its output as well, and a clean report and an empty comparison look identical from the outside. Before treating a run of clean periods as evidence, check the count on each side against the count that was actually matched. If those three numbers are not on the report, the report is not yet in a position to be reassuring.

Most of our breaks disappear when we run it again. Doesn't that mean they were never real?

It means the comparison asked two systems what they thought at moments they define differently, which is a real property of your setup even though it is not an error in either system. The risk is not in those items. It is that a team surrounded by self-clearing breaks develops the entirely reasonable habit of waiting, and that habit is applied to the items that will not clear — which are the only ones that were ever going to matter. Labelling the expected-to-clear items from the as-of definitions, before anyone looks at the amounts, is what keeps the habit from being applied to the wrong list.

Who should own this — operations, finance, or IT?

The comparison can be owned anywhere; the precedence rules cannot. The recurring failure is a reconciliation owned by a team with no authority to decide which side is right, which turns every break into a negotiation between two other teams and is the main reason items age. Whoever runs it needs either the authority to adjudicate by field, or a written set of rules made by people who have it. That is a smaller thing to obtain than a reorganisation, and it is usually the actual constraint.

We are moving to a single platform. Does this go away?

The reconciliations between the parts you consolidate go away, and that is a genuine reduction. What remains is everything you did not consolidate — the ledger, the banks, the exchanges and clearers, the schedules your counterparties send, and the spreadsheets that will be rebuilt around whatever you install. Consolidation also has an in-between period, which is the highest-risk state this article describes: two systems holding the same trades, both live, with a mapping between them maintained by someone who is also busy implementing. The number of boundaries falls; the discipline is the same one, applied to fewer places.

What should we do first if this currently runs on spreadsheets?

Not replace the spreadsheet. Two things come before that, and both are cheap. First, make coverage a reported output: how many items each side holds and how many were compared, so that a clean result stops being ambiguous. Second, record the break itself as an object with a cause and a resolution type, including the ones you close by adjusting a record. Do those two and the spreadsheet will tell you whether it was ever the constraint — and if you later replace it, you will be able to tell whether the new thing is better, which today you could not.

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 written down — field-level precedence, mapping coverage, the break and its cause — and none of those is a product. But the conclusions do touch system capabilities, and it is worth being specific about which ones and where the mapping stops.

The first conclusion is that a difference can only be adjudicated when the trade, the physical movement, the hedge and the settled figure can be seen against one another rather than in separate places. That is the shape of a CTRM/ETRM system providing complete trading lifecycle management for commodity traders, integrating physical trade, financial hedging, risk control, and settlement in one platform; Time Dynamics' Fusion is one, and the capability that bears on this article most directly is complete physical trade lifecycle management and execution, alongside automated financial settlement and payment processing. What that does is remove some of the boundaries described above. Which ones, and how many are left, depends entirely on what else you run — and as the question above notes, every company runs something else.

The second conclusion is that the systems on the other side of the remaining boundaries are not going to be replaced, and the comparison has to reach them as they are. That is a different problem, and it is the one X-Ray addresses: a non-invasive data processing and analysis platform designed specifically for enterprise clients, whose collection toolkit XDK performs non-invasive automated data collection from databases, Excel files, and web interfaces, built to collect data without disrupting existing systems or workflows. The last property is the load-bearing one here, because the ledger is not yours to change, the mapping file is in use today, and any plan that begins by replacing a working thing will not begin.

The third conclusion is that the outputs this article asks for — coverage counts beside break counts, breaks grouped by cause and by resolution type, the same items re-cut by field and by age — have to be produced often enough to act on rather than assembled once a period by hand. 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 threshold, a warning raised while there is still time to act — and an unexplained break passing an age at which its context stops being recoverable is an ordinary instance of that shape rather than an exotic one. Whether it is pointed at a break queue is a configuration question rather than something a platform decides for you, and it is worth saying plainly that the description above is written about trade finance fields, not about this queue.

And here is where it stops. None of this decides which of your two systems is right. Precedence by field is a rule your company writes, and no platform can derive it, because the answer depends on how your processes actually work rather than on what the data looks like. None of this owns your mapping table or knows that a product you traded for the first time last week should have been in it — that gap is closed by measuring coverage, which is a thing to build rather than a thing to buy. It does not set materiality, it does not decide which breaks are worth working, and it will not stop anyone from resolving a difference by adjusting one side, which is frequently the correct action anyway. What a system can settle is narrower and duller than the problem described here: whether the comparison can reach the systems it needs to reach without disturbing them, whether its output can be produced often and cheaply enough to act on, and whether the break was written down with a cause instead of being erased by its own resolution. That is a real part of the distance, and it is not the whole of it.

See the products → · Talk to us about reconciliation 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 carried on spreadsheets and email, which of them run across system boundaries by their nature, and where the manual effort in the back office is actually concentrated — 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 checks above are the intended way to use it. If your own reconciliation contradicts what is written here, your reconciliation is the better evidence.