Check a converted bank statement against its balances
After a statement is converted, StatementStudio compares the extracted amounts with the opening, closing, and running balances printed on the statement, where available. This page shows exactly what that check does, what each outcome means, and what it can and can’t tell you.
One equation, three places it must hold.
Opening balance + sum of transactions = closing balance. On the sample statement that is 1250.75 + 1180.78 = 2431.53, across 15 extracted rows. The same arithmetic is applied three ways:
- Opening → closing
- The opening balance plus every included transaction must equal the closing balance printed on the statement. The difference — the residual — is shown exactly, never rounded away.
- Running balances
- Where the statement prints a balance beside each row, every step is checked: previous balance plus this transaction must equal this row’s balance. A break is flagged on the exact row where the arithmetic first fails.
- After every edit
- The check re-runs after every committed edit, so the result always describes the rows as you reviewed them — not the raw extraction you started from.
All of it is decimal arithmetic on the rows you can see — nothing statistical, nothing invented.
What a 40.00 residual looks like — and how it gets fixed.
On the sample statement, one amount was extracted wrong: −6.82 instead of −46.82. The check catches the exact difference, and correcting that one row against its source page closes it:
A balance check is a strong consistency check — it does not prove every individual field is correct. Sample data shown.
A residual is a diagnosis, not just a verdict — its size and shape usually identify the cause. Why a converted bank statement doesn’t reconcile walks through the six common causes and how to find each one.
Four honest results — including “not enough information”.
The check never reports success it can’t support. These are the only four things it will say:
When the statement doesn’t carry enough to check
Some statements print no opening balance, no closing balance, or no balances at all. Then the honest answer is that a balance check is not possible — shown like this, with the reason, rather than a green tick it can’t justify:
Sample data, shown as it appears when a statement prints no balances. Row-level review beside the source still works exactly the same.
Failures arrive as flagged rows, not a red number.
When the arithmetic breaks, the row-level checks usually say where. These are two of the actual warnings, exactly as the product words them:
The balance does not add up from the previous row. Check this row against the source page.
The opening balance plus the included rows does not match the closing balance. Review the flagged rows before export.
Warnings are non-blocking: fix the row, or acknowledge it and export anyway. Blocking errors — an amount that couldn’t be read safely — must be fixed first. The full flow is on How it works.
What a passing check does not prove.
Reconciled means the arithmetic is consistent. It is strong evidence the extraction is complete and the amounts are right — and it is only that.
- Offsetting errors
- Two mistakes that cancel exactly — one row 10.00 high, another 10.00 low — still pass. Running-balance checks catch most of these where the statement prints per-row balances, but not all statements do.
- Descriptions
- The check works on amounts. A correct amount with a garbled description passes — which is why every row keeps its source page for eyeball review.
- Your books
- This checks a converted statement against itself — before the data enters your accounting system. It does not match transactions to your ledger or bank feed, and it is not accounting software. Matching into QuickBooks, Xero, or Sage happens after you import the exported file.
- Legitimacy
- The check confirms the numbers add up — not that every payment is one you recognise. Reviewing what the transactions are remains your judgement.
About the balance check
What does the balance check compare?
The opening balance plus the sum of the extracted transactions, against the closing balance printed on the statement — and running balances row by row, where the statement shows them.
What happens when the numbers don’t match?
The statement is marked Not reconciled and the residual — the exact difference — is shown. Flagged rows point at the likely causes, so you can check them against the source pages and fix or acknowledge each one.
What if my statement doesn’t show balances?
The check reports Insufficient data instead of guessing. You can still review every row beside its source page and export; the workbook’s validation summary records that the balance check could not be completed.
Does a passing check mean every row is correct?
No. It is one strong consistency check. Errors that offset each other exactly, or a wrong description on a correct amount, can still pass — so review flagged rows rather than relying on the check alone.
Is this the same as reconciling in my accounting software?
No — this check compares a converted statement against itself, before the data enters your books. Matching those transactions to your ledger or bank feed still happens in your accounting software.
Does the check re-run after I edit a row?
Yes. Checks re-run after every committed edit, so the result always reflects the rows as you reviewed them — and your edits are never overwritten by reprocessing.