Trade Reconciliation: Cash, Position and Trade Breaks

Every morning in a trading business starts the same way. Statements arrive from brokers, custodians, clearers and venues, an export comes out of the order management or portfolio system, and two or three people know from memory which differences are normal.

That is a break log held together by institutional knowledge, not a reconciliation process.

Trade reconciliation is the process of matching a 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. This post walks through where breaks actually come from, what T+1 changed, what a break costs, and when we think owning the matching layer makes sense.

How Trade Reconciliation Differs From Position and Cash Reconciliation

Trade reconciliation checks that each transaction was booked correctly, while position and cash reconciliation check holdings and money, and treating one kind of break as another wastes the morning. We see teams spend an hour fixing a booking that was really a cash timing issue and still miss settlement.

Breaks can enter at execution, allocation, confirmation and affirmation, clearing, settlement, or in books and records after the fact. The later a mismatch survives, the more it costs. A discrepancy caught in allocation is paperwork, while the same discrepancy found after settlement becomes a fail, a fee, a client question and an audit trail problem.

The Eight Places Trade Reconciliation Breaks Come From

Most firms do not have one trade reconciliation problem. They have eight recurring sources of noise, each with a different owner, a different process fix and a different software fix. We start with the one that creates the most noise.

1. Timing and Value-Date Differences

This is the biggest source of false breaks. One system books on trade date and another on settlement date, or one counterparty updates intraday while another posts after the close.

The process fix is to define which fields are compared at which stage of the lifecycle. The software fix is date-aware matching rules and tolerances instead of one rigid comparison. You know it is working when the morning break count stops including trades that resolve by themselves a day later.

2. Fees, Commissions, Taxes and Rebates

One side books gross and the other net, or the amount is right but the fee is posted as a separate line. These breaks look like price errors and are usually convention errors.

The process fix is a written booking convention for each asset class and venue. The software fix is rule-based treatment of fee lines and derived cash amounts, so a net-versus-gross difference is classified automatically rather than investigated by hand.

3. Corporate Actions and Their Timing

Splits, dividends, mergers and redemptions create breaks that are correct on one side and incomplete on the other. The trade record was right when booked, and the world changed underneath it.

The process fix is timely event sourcing from the reference-data team or the administrator. The software fix is a model that reconciles against the expected effect of each event, not only against raw trade rows.

4. FX and Multi-Currency Cash Legs

Cross-border trades add another place to drift, because 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, so the trade and its cash legs reconcile as one unit.

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 executions correctly, every downstream report looks broken even though each fill was right.

The process fix is one consistent allocation policy. The software fix is hierarchical matching that understands parent and child relationships between orders, fills and allocations.

6. Cancels and Corrects Arriving After the File

By the time a cancel shows up, yesterday's report is already stale. Teams then argue about which version of the trade the counterparty is holding.

The process fix is a cut-off rule plus an exception queue for late corrections. The software fix is replayable event history rather than rows that get overwritten, so you can show what the record said at any moment.

7. Stale or Divergent Static Data

Instruments, counterparties, account identifiers, settlement instructions and venue codes go stale more often than their owners think. A single wrong settlement instruction can break every trade that touches it.

The process fix is one owner for golden-source reference data. The software fix is normalizing identifiers before matching, not after the break has been created.

8. File and Identifier Format Drift

A broker changes a feed, a venue renames a field or a custodian reorders columns, and a whole class of trades stops matching overnight.

The process fix is vendor change management and test files before every cutover. The software fix is schema mapping, versioned parsers and feed monitoring that alerts when a file's shape changes, before anyone sees a spike in breaks.

Illustrative Example: One Mismatch, Three Possible Causes

Illustrative example. This is a constructed scenario, not a client incident.

A firm buys 10,000 shares on Tuesday. Its order management system books the trade at 14:02 against internal instrument ID 48817. The broker's end-of-day file shows 9,000 shares at the same price against the ISIN, and a separate 1,000-share line timestamped 16:40.

The match reports a 1,000-share quantity break. Before anyone changes a booking, there are at least three explanations to check:

• Timing. The 1,000-share line is a late partial fill that arrived after the internal snapshot was taken.

• Identifiers. The second line carries an identifier the mapping table does not link to instrument 48817.

• Correction. The broker cancelled and rebooked part of the fill, and the firm holds only the original version.

Each explanation points to different evidence and a different owner. Treat the first finding as a hypothesis until the source record confirms it.

A Break Triage Table

The causes below are hypotheses to verify, not diagnoses. Ownership varies by firm, so treat the team column as a common starting split.

Whatever the cause, preserve the audit trail. Record the original values, the evidence used, who resolved the break and what changed. An adjustment without that history fixes today's number and creates tomorrow's audit question.

What T+1 Settlement Changed for Trade Reconciliation

T+1 did not make trade reconciliation conceptually harder, but it made late reconciliation far less tolerable. The SEC adopted rules on February 15, 2023 to shorten the standard settlement cycle for most broker-dealer transactions from T+2 to T+1, with a compliance date of May 28, 2024.

The deadlines moved into the trade date itself. DTCC's guidance says broker-dealers must complete allocations, confirmations and affirmations no later than end of the day on trade date, and it recommends finishing allocations by 7:00 PM ET to meet the DTC affirmation cutoff of 9:00 PM ET. Trades that miss it can still settle bilaterally, but DTCC describes those routes as more costly and more operationally intensive.

For a US implementation, establish the instruments, counterparties and processing deadlines that apply to your business. Do not use a single settlement assumption for every instrument or market.

In our view, when people ask for intraday reconciliation they rarely mean running the same report more often. They mean a process that ingests new events, re-runs matches and routes exceptions to the right person before the lifecycle closes around the error.

What a Reconciliation Break Really Costs a Trading Firm

The cost of a break is mostly people time and settlement friction, so start with your own numbers rather than a vendor quote. We would build the model from five lines:

• Analyst hours per day spent finding, classifying and clearing breaks, multiplied by 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.

• The tail risk of a real error hiding inside routine trade reconciliation noise.

The biggest line item is usually not on the P&L at all, and it is key-person concentration. If three people know how to interpret the break log and two of them leave, the firm has lost a control, and that cost appears only when the business is under stress.

Four Trade Reconciliation Options Compared Honestly

For standard equities and cash flows a vendor platform is often the right answer, and building only makes sense when your flows are unusual. The table compares the four options we see most often.

There is no prize for building trade reconciliation software if the real need is better controls on ordinary flows. Buy first, and build only the parts a platform cannot own.

When Owning the Trade Reconciliation Layer Makes Sense

Owning the matching layer becomes rational when the breaks come from your own products and venues rather than from one noisy counterparty. We would consider a build when several of these are true:

• Instruments, venues or booking rules are unusual enough that a generic engine needs heavy custom configuration anyway.

• Break volume is driven by your product design, not by one counterparty.

• Most hours go into exception workflow, evidence and escalation rather than the match itself.

• You need an audit trail and data model you control for regulators, investors or diligence.

• The same reconciliation data feeds P&L attribution, funding, client reporting or control analytics.

Two reasons do not count, which are that the vendor is expensive and that a developer says it looks easy. Most reconciliation projects fail in exception handling, replay, evidence and feed onboarding rather than in matching.

Any team proposing a build should be able to explain an immutable event log, normalization before matching, versioned deterministic rules, tolerances stored as data, an exception workflow with owners and ageing, full replay of any past state, and a way to onboard a new feed without a fresh engineering project.

The engineering questions are about source records, explicit matching rules, exception handling and the evidence behind corrections. Better Software has trading infrastructure experience with UTR8 and AllOptions and embedded engineering experience with Valon. Those engagements provide relevant finance context; they should not be read as claims that we delivered this exact reconciliation design for each firm.

Related problems show up in reproducible RIA fee runs and in three-way reconciliation for title agencies.

Questions to Ask Before Approving a Reconciliation Build

A build proposal is ready for approval only when it can answer specific questions about breaks, sources of truth and replay. These are the ones we would put to any team, including our own:

• Which breaks are we trying to reduce, among timing, static data, allocation, corporate actions and feed drift?

• What share of current effort is match logic and what share is 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?

• Who approves a rule change, and how is the old version retained?

• If this stays in a vendor tool, which data do we lose for other workflows?

• What happens if the one person who understands the process is unavailable?

Fix Trade Reconciliation at the Source of Each Break

Good reconciliation separates genuine booking errors from expected timing differences and assigns each unresolved item to an owner. Set review deadlines around your instruments, counterparties and settlement obligations. Buy standard matching capabilities where they fit, and build only the exception handling or integrations your existing tools cannot support.

An existing reconciliation tool may already cover your flows. Custom engineering is worth discussing when a specific gap remains, such as an exception workflow or a data model the platform cannot hold. If you want a second view on a reconciliation design or a build-versus-buy decision, the team at Better Software can walk through it with you, and our financial software development page describes how we work with finance teams.

Discuss a reconciliation workflow with Jai, our founder.

Scope a reconciliation software project

Start with two redacted source files, the fields you compare, current matching rules and a few unresolved breaks. Record the review deadline, the person who approves a correction and what evidence must remain afterward. This is enough to make a first engineering conversation concrete.

Discuss your reconciliation workflow, or review our financial software development experience. We can help build a new product or improve an existing system.

Frequently Asked Questions

What Is Trade Reconciliation in Investment Banking?

In investment banking, trade reconciliation is usually a middle-office and operations control. We see it run daily across front-office bookings, clearing records and custodian statements, with breaks assigned to owners and aged until resolved, because unresolved breaks become settlement fails, capital charges and audit findings.

What Is Post Trade Reconciliation?

Post trade reconciliation covers every check after execution, including allocation, confirmation, clearing, settlement and books and records. We treat it as one lifecycle rather than separate reports, because a break that starts in allocation often surfaces only at settlement, when it is far more expensive to fix.

What Is a Cash Break?

A cash break is a difference between the cash a firm expects and the cash an external statement shows. We usually trace cash breaks to fees booked differently, FX legs, value-date timing or settlement amounts, and we resolve them separately from trade breaks because the owner and the fix differ.

How to Do Trade Reconciliation?

We start by defining which records are compared at each lifecycle stage, then normalize identifiers and dates, apply deterministic matching rules with tolerances, and route every exception to an owner. Each resolved break keeps its evidence, so the same reconciliation can be replayed later for an auditor or investigation.

What Does It Mean to Reconcile a Trade?

To reconcile a trade means confirming that both sides agree on its economic details, including instrument, quantity, price, side, trade and settlement dates, account and settlement instructions. When we find a difference, we either correct the underlying record or document an agreed, expected difference with the counterparty.