Why a Correct Statement Doesn't Net Out: The Balance Conventions Behind Reconciliation Breaks

Spend any time listening to treasury teams work through their accounts and a particular complaint surfaces with surprising regularity. The transactions on a statement don't sum to the ending balance. This isn’t a skill issue from a new graduate, it’s from people who reconcile every day and know the mechanics cold. When experienced practitioners hit a statement that won't tie out, the cause is rarely a missing transaction or a bank error. Far more often the statement is internally consistent and doing exactly what it was designed to do, and the break sits in a mismatch between which figures are being compared. That’s a question of balance conventions and date bases rather than arithmetic.

That distinction is the whole game, and it is easy to lose even for people who could define reconciliation in their sleep. The math itself is simple, the change in balance over a period should equal the net transaction activity across it. What is not trivial is that a modern statement reports more than one balance and stamps every entry with more than one date, and that equation only holds when you hold both of those constant. 

This guide is about the handful of conventions that cause an otherwise-correct statement to appear broken, and how to work a genuine breakdown to the single item actually causing it.

The Two Conventions Behind Most Breaks

Before reaching for anything more elaborate, it is worth knowing that the large majority of statements that appear not to net out fail for one of two reasons, and both are conventions rather than errors. The bank is reporting more than one balance, or it is stamping entries with more than one date, and the reconciliation has quietly compared figures that were never meant to line up. Rule these two out first and the genuine exceptions, the ones that actually need investigating, become far easier to isolate.

1. Booked Balance vs. Available Balance

This is the single most frequent culprit, and it catches experienced professionals as readily as anyone. The root of it is that every modern electronic statement reports more than one balance, and the transaction lines only net against one of them.

Under the ISO 20022 camt.053 standard that increasingly governs how banks deliver statement data, an account statement carries an opening booked balance (OPBD) and a closing booked balance (CLBD). It may also carry a closing available balance (CLAV), reported as a deliberately separate figure. 

The booked balance reflects entries the bank has actually posted to the account. The available balance reflects what you can draw on, which may be reduced by holds, uncleared deposits, or pending authorisations that have not yet been booked as entries. Bank of America's reference guide to the camt.053 format sets out these balance types explicitly, and the structural point is the one that matters. Only the booked entries net against the booked balance.

Sum the transaction lines, which are booked entries, and compare the result to an available balance, and you will be out by exactly the value of the holds and uncleared items. The statement is consistent, but the comparison is not. The good news is that the correction is relatively straightforward once you understand the cause. Reconcile booked against booked. The available balance tells you what you can spend, not whether the account ties out, so leave it out of the check.

2. Value Date Versus Booking Date

The second recurring source of apparently missing amounts is timing, and it is subtler because nothing is actually absent. The amount is simply attributed to a different day than expected.

Each transaction on a statement typically carries two dates. The booking date is when the bank posted the entry to the account, the value date is when the funds become effective for interest calculation. These frequently differ, as a transfer booked on a Friday may carry a value date of the following Monday. Reconcile on a value-date basis while the balance change was driven by booking-date posting, or the reverse, and entries appear to fall on the wrong side of the period cut-off. A day that should tie out won't. Cross-border activity, weekend settlement, and bank cut-off times all widen this gap. Pick one basis, apply it to both the balance figures and the transaction set, and the timing-driven discrepancies dissolve.

Working a Genuine Breakdown To One Item

When an account still doesn't reconcile after balance type and date basis have been ruled out, a structured pass beats hunting line by line. The recurring categories are familiar to anyone who does this at volume. Bank-only items the ledger never recorded, such as interest credits, account fees, and service charges, timing differences such as outstanding cheques or deposits in transit that the bank has not yet booked, errors on either side, and occasionally fraud, which is the underlying reason reconciliation has always been treated as a control rather than a clerical task. 

Trovata's breakdown of the case for daily reconciliation makes the operational version of that point. The more often the check runs, the smaller the transaction set to sift and the faster anomalies surface, which is the opposite of the month-end scramble many teams default to.

A workable sequence runs in four passes. 

What survives those four passes is the real exception, and it is usually a single identifiable item rather than the diffuse sense that everything is off.

Why Scale Requires Automation

For one account at one bank, the manual process above is entirely workable. The difficulty is multiplication. A treasury team running dozens or hundreds of accounts across several banking relationships faces a different problem from the logic of any single reconciliation. It faces the sheer volume of statements, formats, and balance conventions to normalise before that logic can be applied at all. The pain is real and growing. A 2024 Deloitte survey found that 58% of treasury teams ranked visibility into cash and financial risk as their single greatest challenge, with fragmented, manually assembled data consistently named as the cause.

This is where automated reconciliation earns its place. The checks stay the same, but what changes is that the normalisation of disparate statement formats such as BAI2, MT940, and camt.053 into a consistent structure, the matching of booked entries against the change in booked balance, and the flagging of accounts that fall outside an acceptable threshold all run continuously rather than once a month. 

Platforms built on direct bank API connectivity compare the change in balance to net transaction activity at the account level and surface only the accounts that don't tie out, so the team's attention goes to genuine exceptions rather than to reconciliation arithmetic.

The Practical Takeaway

When a statement won't tie out, the instinct is to start hunting for the rogue transaction, but the more reliable move is to assume the statement is right and check the comparison instead. Three causes account for almost all of it, in roughly this order of likelihood. 

1. Booked entries are being compared against an available balance. 

2. Value dates and booking dates have been mixed across the balance figures and the transaction set. 

3. Or a genuine bank-only item or timing difference is sitting unposted, waiting to clear.

None of the first two means anything is actually wrong with the account. They are conventions the statement was built on, not errors, and once you know to look for them they take seconds to rule out. What remains is the real exception, and it is almost always a single identifiable item rather than the diffuse sense that the whole account is off. A statement that appears not to net out is rarely a problem to be solved and far more often a question to be asked correctly.

The harder version of this problem is not the logic but the volume. Running the same disciplined check across dozens or hundreds of accounts, each in its own statement format and balance convention, is where the manual approach stops scaling and the exceptions start hiding in the noise. This is the work Trovata is built to absorb. By normalising statement data across banks and matching booked activity against the change in booked balance automatically, it surfaces only the accounts that genuinely don't reconcile, so the team's attention goes to the one item that needs a decision rather than to the arithmetic confirming that the rest are fine.

If reconciliation breaks are still eating into your team's mornings, see how Trovata automates the check across every bank and account. While the conventions don't change, the time you spend ruling them out can. Book a demo today.