Check a bank statement balance without hiding extraction errors

A closing balance that matches is a useful check, not proof that a converted statement is correct. Start with the opening balance, keep the statement’s order, and compare each intermediate balance when one is printed. Do not change a transaction merely to make the final number work.

This guide is a review protocol, illustrated with the fictional workspace. BankStatementScan is in preparation and does not process your files. The arithmetic below is our synthetic example, not a result produced by OCR or a statement from a real bank.

Work through a small, explicit example

Assume one account in EUR, opening at 1,000.00. The five movements are a 1,500.00 credit, then debits of 89.90, 23.40 and 200.00, followed by a 23.40 refund. Total credits are 1,523.40 and total debits 313.30.

Step	Movement	Expected balance
Opening	—	1,000.00
1	+1,500.00	2,500.00
2	−89.90	2,410.10
3	−23.40	2,386.70
4	−200.00	2,186.70
5	+23.40	2,210.10

The final calculation is 1,000.00 + 1,523.40 − 313.30 = 2,210.10. Keep the opening figure outside the transaction rows: including it as a payment would double-count it. If the document contains several accounts or currencies, make a separate check for each. There is no meaningful cross-currency sum without a separately defined conversion policy.

Find the first disagreement, not just the final gap

Suppose the second debit was read as 899.00. The first disagreement appears immediately after that row. Compare the source page, decimal separator and column position there before examining every later balance. A later correction should retain what the source said and what you changed.

If the source has no running balances, you cannot honestly claim to have checked them. Check the final equation if enough figures exist and label the missing control. If pages are absent, even a calculation on the available rows may be incomplete. Check page numbering, period and continuation rows first.

A match can conceal several kinds of error

Two wrong amounts can offset one another. Swapping descriptions leaves the total unchanged. A wrong date may preserve every balance. An opening balance copied from another period might mask missing rows. Review descriptions, dates and provenance separately; arithmetic is only one test.

Do not silently delete repeated-looking payments: two purchases of the same amount can be legitimate. Likewise, totals and page reports are not new transactions. Microsoft’s PDF connector documentation describes multiline-row cleanup as a consideration. That is a reason to inspect row boundaries, not to assume any tool gets them right automatically.

Finish with a review record

Record which source pages were checked, which values were unavailable, and which corrections were made. A simple result such as “closing equation matches; row descriptions reviewed; page 3 missing” is more useful than a single green badge. It does not certify authenticity, rule out fraud or replace a ledger reconciliation.

Explore the planned workflow, then check CSV import conventions before handing the table to another tool.

You can request access through this website’s form. It sends your email and visit context to BankStatementLab for BankStatementScan; a recorded request does not create an account or provide immediate access. See privacy.