Guide · troubleshooting

Why a converted bank statement doesn't reconcile

When extracted transactions don’t add up to the statement’s balances, the cause is almost always one of six things. The residual — the exact difference — usually tells you which one you have. This guide applies whatever tool produced the conversion.

Start with the residual

A failed check comes with a number. Use it.

“Doesn’t reconcile” means: opening balance plus the extracted transactions doesn’t equal the closing balance. The difference is the residual, and it is evidence. Here is a real one — a single amount extracted as −6.82 instead of −46.82 — caught and corrected:

One extracted amount is wrong (−6.82 instead of −46.82) — the check catches the 40.00 residual:

Not reconciled

Opening

£1,250.75

Transaction sum

+£1,220.78

Calculated closing

£2,471.53

Statement closing

£2,431.53

Residual

+£40.00

Included

Warnings

After correcting that one amount against the source page, the same check passes:

Reconciled

Opening

£1,250.75

Transaction sum

+£1,180.78

Calculated closing

£2,431.53

Statement closing

£2,431.53

Residual

£0.00

Included

Edited

A balance check is a strong consistency check — it does not prove every individual field is correct. Sample data shown.

Diagnosis by shape

Read the residual before touching any row.

Four shapes cover most failures:

Equals one transaction: A row is missing (residual in the direction of that row) or duplicated (opposite direction). Search the rows for the residual amount first — it’s the fastest diagnosis there is.
Exactly double a transaction: That transaction’s money-in/money-out direction is flipped. Halve the residual and search for the result.
Small and odd: A misread digit somewhere. Follow the running balances to the first row where the arithmetic breaks.
No residual at all: The check couldn’t run — the statement doesn’t print the balances it needs. That is “insufficient data”, not failure, and no honest tool should report success on it.

The six causes

Symptom, how to find it, how to fix it.

1 · A misread amount

Symptom: The residual is a small, odd-looking number that matches no transaction — it is the difference between the real amount and the misread one. A dropped leading digit is the classic: 46.82 read as 6.82 leaves exactly 40.00.
Find it: Sort the rows by amount and compare anything suspicious against the statement page. If per-row balances exist, the first broken running balance sits on the misread row.
Fix it: Correct the amount to what the statement shows. In any spreadsheet, re-add the column afterwards; in StatementStudio, the check re-runs on its own after the edit.

2 · A money-in/money-out flip

Symptom: The residual is exactly twice one transaction. A 46.82 payment counted as money in moves the total by 93.64 — double the amount, in the direction of the flip.
Find it: Halve the residual and search the rows for that amount. Statements that print debits and credits in separate columns make flips easy to spot; single signed columns hide them.
Fix it: Flip the direction on that row, not the number. If several rows flipped together, the layout’s sign convention was misread — check every row from the same column before trusting the rest.

3 · Missing rows or a missing page

Symptom: The residual equals one transaction (a skipped row) or a whole day’s worth of them (a skipped page). Running balances jump across the gap.
Find it: Check the page count against the statement’s own numbering — “page 3 of 5” language, or a balance that doesn’t carry over from one page to the next.
Fix it: Re-export from the bank if the PDF itself is incomplete. If the source is fine but rows were skipped, add them by hand against the page.

Possible missing pageWarning

The statement may skip a page. Check the source PDF before using the export.

4 · A row extracted twice

Symptom: The residual equals one transaction, in the opposite direction to a missing row. Two rows show the same date, amount, and near-identical description.
Find it: Compare the running balances: a real repeat (two identical coffees) steps the balance down twice on the statement; an extraction duplicate shows a balance the statement never printed.
Fix it: Delete the duplicate — after checking the source. Repeated pages in the PDF itself produce whole blocks of duplicates.

Date	Description	Amount	Balance
6 May 2026	CARD PURCHASE PRET A MANGER	(£6.75)	£2,792.78
6 May 2026	CARD PURCHASE PRET A MANGERPossible duplicate	(£6.75)	£2,786.03

Possible duplicateWarning

This row has the same date and amount as another transaction, with a similar description. Both are kept — compare the source pages before deleting either one.

Both rows stay in the data. Nothing is auto-deleted — the running balances show whether the statement really charged twice. Sample data shown.

5 · Date or ordering problems

Symptom: The opening/closing totals pass, but a running balance breaks mid-statement — or a row’s date falls outside the statement period entirely.
Find it: Follow the first broken running balance; the row where the arithmetic first fails is usually the row that moved. Ambiguous day/month dates (04/05 vs 05/04) are the quiet culprit.
Fix it: Restore the statement’s printed order and correct the date against the page — don’t re-sort by parsed date and hope.

Running balance needs reviewWarning

The balance does not add up from the previous row. Check this row against the source page.

6 · The statement doesn’t carry what a check needs

Symptom: No failure at all — the check reports “insufficient data”. The statement prints no opening balance, no closing balance, or no balances anywhere.
Find it: Look at the statement itself: some banks’ e-statements simply omit balances, and a mid-period export may start with a “brought forward” line instead of an opening balance.
Fix it: There is nothing to fix — there is nothing to check against. Verify rows against the source individually, and treat any tool that claims a “reconciled” result on such a statement with suspicion.

The flagged examples above are StatementStudio’s actual warnings, shown as the product words them. In other tools, run the same checks by hand: re-add the amount column, follow the running balances, and compare page counts.

One caution

Reconciling proves consistency — not correctness.

Two errors that offset exactly still pass. A right amount under a wrong description still passes. A balance check is the strongest cheap test a converted statement can face, and it is still only arithmetic — keep the source pages within reach for anything that matters.

How StatementStudio runs this check — the equation, the four outcomes, and what each one unlocks — is documented on the reconciliation-check page, and you can watch a failing check get corrected in the interactive demo.

Questions

Quick answers

My statement shows no opening or closing balance — can it still reconcile?

Not fully. Without printed balances there is nothing to check against, so the result is Insufficient data rather than a guess. You can still review each row against the source and export.

The residual equals one transaction exactly. What does that mean?

Usually a missed or duplicated row. If a transaction is missing, the residual matches its amount; if a row was extracted twice, the residual matches it in the other direction. Search the rows for the residual amount first.

The residual is exactly double one transaction. Why?

A direction flip. A 46.82 payment read as money in instead of money out moves the total by 93.64 — twice the amount. Check that row’s money-in/money-out direction against the source page.

Everything matches except one running balance. What is it?

Often a reordered or misdated row. A running-balance mismatch is flagged on the exact row where the arithmetic first breaks, so start there and compare it with the source page.

See it on sample data

Watch a 40.00 residual get diagnosed and fixed.

Step through the demo Choose a bank-statement PDF