Operations
Where Breaks Actually Come From in Trade Reconciliation
By Better Software · Sat Sep 12 2026 · 9 min read
Every morning in a trading business starts the same way: statements from brokers, custodians, clearers, and venues; an export from the OMS or portfolio system; and two or three people who know, from memory, which differences are “normal.” That is not a reconciliation process. It is a break log held together by institutional knowledge.
And under T+1, that old arrangement gets less forgiving every quarter. The window to find a mismatch, understand it, and fix it before it turns into a settlement problem has shrunk. If your control environment depends on one senior operator remembering how a venue behaves on a good day, the risk is no longer theoretical.
What trade reconciliation actually is
Trade reconciliation is the process of matching the firm’s own record of a trade — and the position and cash it produces — against the independent records of brokers, custodians, clearers, counterparties, and administrators, then explaining every difference.
That definition matters because many pages on the web reduce the term to a glossary entry or fold it into generic balance-sheet reconciliation. For operators, the real question is not “what is it?” The question is: where did the difference come from, who owns it, and how quickly does it have to be resolved?
Trade vs. position vs. cash reconciliation
| Type | What it asks | Typical break |
|---|---|---|
| Trade reconciliation | Did we book the transaction correctly? | Wrong quantity, price, side, instrument, or allocation |
| Position reconciliation | Do we hold what we think we hold? | Missing trade, corporate action, cancel/correct, stale static data |
| Cash reconciliation | Do we have the money we think we have? | Fees, commissions, FX legs, value-date timing, settlement amounts |
The common mistake is treating a trade break as if it were a position break. If a booking error is actually a cash timing issue, the team can spend an hour “fixing” the wrong thing and still fail settlement.
Where post-trade reconciliation sits in the lifecycle
Breaks can be introduced at execution, allocation, confirmation and affirmation, clearing, settlement, or in books-and-records after the fact. The later the mismatch survives, the more expensive it becomes. A discrepancy caught in allocation is paperwork. The same discrepancy found after settlement can become a fail, a fee, a client question, and an audit trail problem.
The eight places breaks actually come from
Most firms do not have one reconciliation problem. They have eight recurring sources of noise, each with a different fix.
1) Timing and value-date differences
This is the biggest source of false breaks. One system books on trade date, another on settle date; one counterparty updates intraday, another posts after close. The process fix is to define which fields are compared at which stage. The software fix is to support date-aware rules and tolerances, not a single rigid match.
2) Fees, commissions, taxes, and rebates
One side books gross, the other net. Sometimes the amount is right but the fee is posted separately. The process fix is a clear booking convention for each asset class and venue. The software fix is rule-based treatment for fee lines and derived cash amounts.
3) Corporate actions and their timing
Splits, dividends, mergers, and redemptions create breaks that are often “correct” on one side and incomplete on the other. The process fix is timely event sourcing from the reference-data team or administrator. The software fix is a model that can reconcile against expected event effects, not just raw trade rows.
4) FX and multi-currency cash legs
Cross-border trades introduce one more place to drift: the executed trade, the base currency conversion, and the cash settlement can each be recorded differently. The process fix is explicit ownership of FX rates and booking timing. The software fix is support for linked legs and currency-aware matching.
5) Partial fills, average pricing, and allocation logic
A parent order may fill in ten pieces and allocate across several books or accounts. If the platform cannot net the execution correctly, every downstream report looks broken. The process fix is a consistent allocation policy. The software fix is hierarchical matching that understands parent-child relationships.
6) Cancels and corrects arriving after the file
By the time the cancel shows up, yesterday’s report is already stale. The process fix is a cut-off rule and an exception queue for late-arriving corrections. The software fix is replayable event history, not overwriting rows.
7) Stale or divergent static data
Instruments, counterparties, account IDs, settlement instructions, and venue identifiers go stale more often than owners think. The process fix is a single owner for golden-source data. The software fix is normalization before matching, not after break creation.
8) File and identifier format drift
Broker changes a feed. Venue changes a field. Custodian renames a column. Suddenly a whole class of trades no longer matches. The process fix is vendor-change management and test files before cutover. The software fix is schema mapping, versioned parsers, and feed observability.
What T+1 changed
T+1 did not make reconciliation conceptually harder. It made late reconciliation less tolerable.
In a T+2 world, a firm could often discover a break at the end of the day and still have time to untangle it before settlement pressure peaked. In a T+1 world, end-of-day-only matching is already behind the curve. What used to be “we will clear this tomorrow” is now “we may already be in a fail window.”
So when people say they need “intraday reconciliation,” they usually do not mean running the same report more often. They mean a process that can ingest new events, re-run matches, surface exceptions, and route them to the right person before the trade lifecycle closes around the error.
What a break costs you
Do not start with a vendor quote. Start with your own numbers.
Cost model:
- Analyst hours per day spent finding, classifying, and clearing breaks × fully loaded hourly cost
- Failed-settlement, funding, overdraft, or interest charges
- Counterparty, custodian, or administrator fees tied to fails and manual handling
- Delayed close, delayed NAV, delayed reporting, or late audit support
- Tail risk of a real error hiding inside routine noise
The biggest line item is usually not on the P&L: key-person concentration. If three people know how to interpret the break log and two of them leave, you have lost a control. That cost shows up only when the business is stressed.
Your four options, honestly compared
| Option | Good for | What you still hold | Cost shape |
|---|---|---|---|
| Spreadsheets + institutional memory | Low volume, simple instruments, one venue, one account structure | Everything: logic, evidence, version control, continuity risk | Cheap to start; expensive in people time |
| Administrator / prime / broker recon reporting | Standard flows where the counterparty already reports cleanly | Data gaps, timing differences, and anything outside their template | Included or low fee; limited control |
| Commercial reconciliation platform | Multi-source matching across standard trades, positions, and cash | Configuration, exception handling, feed mapping, and governance | License + implementation + ongoing rule tuning |
| Owned matching and exception layer | Idiosyncratic products, complex venues, heavy audit needs, reusable operational data | Engineering ownership, maintenance, and change management | Build cost up front; lower dependency later |
For standard equities and cash flows, a vendor platform is often the right answer. There is no prize for building recon if your real need is better controls on ordinary flows.
When building actually makes sense
Owning the matching layer becomes rational when several of these are true:
- Your instruments, venues, or booking rules are idiosyncratic enough that a generic engine needs heavy custom configuration anyway
- Break volume is driven by your product design, not by one noisy counterparty
- The hours are going into exception workflow, evidence collection, and escalation, not the match itself
- You need an audit trail and data model you control for regulators, investors, or diligence
- The same recon data has second uses in P&L attribution, funding, client reporting, or control analytics
Two non-reasons do not count: “the vendor is expensive” and “our developer says it looks easy.” Most recon projects fail not in matching, but in exception handling, replay, evidence, and feed onboarding.
What an owned recon layer has to get right
Any team proposing a build should be able to explain these points without hand-waving:
- An immutable event log, not mutable rows that get overwritten
- Normalization before matching so identifiers, currencies, and dates are comparable
- Deterministic matching rules with versioning and sign-off
- Tolerances as data, not code
- Exception workflow with owner, ageing, assignment, and evidence attachment
- Full audit trail and replay for the exact state of a close or investigation
- A way to onboard a new broker or venue feed without a fresh engineering project every time
This is where product engineering matters. At Better, the useful pattern is not “AI magic”; it is event-sourced records, explicit exception workflows, and auditability by design. That is the same shape of problem we have seen in financial-operations systems like UTR8 and AllOptions, and in financial-services operations work with Valon: keep the underlying facts stable, and make the exception layer legible.
Questions to ask before you approve a build
- What exact breaks are we trying to reduce: timing, static data, allocation, corporate actions, or feed drift?
- What percentage of current effort is match logic versus exception investigation?
- Which systems are the sources of truth for trade, position, cash, and reference data?
- How will we replay yesterday’s state when an auditor or regulator asks?
- How many new feeds or counterparties do we add in a typical quarter?
- What happens when a rule changes: who approves it, and how is the old version retained?
- If this stays in a vendor tool, what data do we lose access to for other workflows?
- What is the failure mode if the one person who understands the process is unavailable?
FAQ
What is trade reconciliation?
It is the process of matching the firm’s trade, position, and cash records against external records from brokers, custodians, clearers, and administrators, then explaining and resolving differences.
How do you do trade reconciliation?
Define the records to compare, normalize identifiers and dates, apply deterministic matching rules, surface exceptions, investigate root causes, and retain evidence for every resolved break. In practice, that means a repeatable process for trade, position, and cash — not just a daily spreadsheet export.
What is post-trade reconciliation?
Post-trade reconciliation is the part of the lifecycle after execution, covering allocation, confirmation, clearing, settlement, and books-and-records checks. It is where timing gaps, booking differences, and settlement risks show up.
Is trade reconciliation the same as position reconciliation?
No. Trade reconciliation asks whether the transaction was recorded correctly. Position reconciliation asks whether your holdings are correct. A missing trade can create a position break, but the fix is not always the same.
What is a trade break and how is it resolved?
A trade break is any mismatch between your record and an external record. It is resolved by identifying the source — timing, fees, corporate actions, FX, allocation, static data, cancels, or file drift — then correcting the underlying record or agreeing the expected difference.
Can AI do trade reconciliation?
AI is not the matching engine. Matching is deterministic work. Where AI can help is break triage, classification, summarization, and explaining likely causes from historical patterns — but only after the rules and data model are already sound.
The right reconciliation setup is not the one with the flashiest dashboard. It is the one that tells you, quickly and audibly, which differences are real, which are timing noise, and who owns the rest.