Bank Statement Validation Guide

That one check is the difference between a statement you've glanced at and a statement you've actually validated. Everything else in this guide hangs off it.

What "validated" actually means

A validated bank statement is one where two separate questions have been answered yes. First: is every transaction present? Second: is every figure correct? People tend to assume that if the numbers on screen look reasonable, both boxes are ticked. They aren't related at all.

Completeness is about absence — a line that never made it onto the page. Correctness is about accuracy — a figure that's there but wrong. A statement can be perfectly correct on every line it shows and still be missing three. It can show every line and have a misread digit on one. You need a check that catches both failure modes, and the running balance is the only single test that does.

Here's why it works as a checksum. The bank prints a balance after every transaction — the account's true position at that exact moment. So if you recompute that column yourself, starting from the opening figure and applying each transaction in order, your number has to agree with the bank's at every row. The first row where the two diverge is the precise location of the error. A missing line throws every balance below it out by the same amount. A misread figure throws everything below it out by the difference. Either way, the running balance tells you it happened and roughly where.

The five checks that validate a statement

Run these in order. Each one assumes the previous passed, and together they cover the ways a statement goes wrong.

1. Confirm the source and period. Check the statement is for the right account and the exact dates you expect. Note the opening and closing balances printed on it before you touch anything else — those two figures are what you'll be reconciling against.
2. Match the opening balance to last period. This statement's opening balance must equal the previous statement's closing balance. If there's a break in the chain, you have a gap before you've started, and validating this period won't close it.
3. Check the running balance line by line. Take the opening figure, apply each credit and debit in date order, and confirm your running total matches the bank's balance column at every row. This is the completeness test. The first mismatch is your missing or misread transaction.
4. Reconcile the totals. Opening balance plus total credits minus total debits must equal the printed closing balance. If it ties out to zero, the statement is internally consistent. If it's off by any amount, treat the whole statement as unvalidated until you find the cause.
5. Sanity-check the data itself. Look for the things that pass the maths but are still wrong: a duplicated transaction that nets correctly, a date outside the period, a description garbled in extraction, a credit sitting in the debit column on a single-amount layout.

Validating extracted data is a different job

The five checks above apply to any statement. But the moment your data comes out of a PDF — or a scan, or a phone photo — you've added a failure point that doesn't exist on the original: extraction.

This is where most validation effort should go, because extraction breaks the maths without breaking the appearance. We see the same handful of slips over and over. A row vanishes in the seam between two pages, so the total is quietly short by one transaction. A 1,290.00 debit reads as 1,920.00 because two digits transposed. A wrapped description splits one transaction into two phantom rows. A credit lands in the debit column on a layout where the bank uses one signed amount instead of two. None of these announce themselves — the spreadsheet looks completely normal.

That's the trap with copy-paste and most basic converters. They hand you rows of numbers with no idea whether those rows are complete or accurate. You get a tidy-looking spreadsheet that's missing two lines and has a transposed figure on a third, and nothing on screen tells you. You find out weeks later, when something refuses to tie out.

So validating extracted data means doing the running-balance check *on the output*, not assuming the converter got it right. If the recomputed balance still reconciles to the closing figure after extraction, the data survived intact. If it doesn't, the extraction introduced an error and you've caught it before it reached your books.

How Export Bank Statement validates the data for you

This is the check the tool is built around. When you convert a statement with Export Bank Statement, it extracts every line — date, description, money in, money out, balance — across however many pages the statement runs to, including scanned and photographed statements read via OCR. Then it does the part most converters don't bother with: it walks the running balance from the opening figure to the closing one and flags any statement that doesn't reconcile.

So you don't get handed numbers and left to trust them. You get a result. If the totals reconcile, you see a confirmation before you download anything. If they don't, the statement is flagged rather than quietly passed along, and you know to look before you post a single line.

One honest point about where this stops. Once the data is validated, the path into your accounting software is convert, then import the CSV. The tool exports in the native bank-import format for Xero, QuickBooks and Zoho Books, so the lines arrive as reconcilable statement lines. It does not push transactions through a live bank-feed API — that's a separate, certified integration. Think of it as producing a verified import file, not a one-click sync. If you're working from PDFs after the fact, that's the cleaner route anyway: you already know the file balances before it ever reaches your ledger.

Manual validation versus a checked conversion

The point of the table is the middle two rows. A manual validation depends on you noticing what's absent or subtly wrong, which is the hardest thing for a human eye to do across a few hundred transactions. A recomputed running balance doesn't get tired on page seven.

A worked example

A client account, one quarter, roughly 240 transactions over an eleven-page PDF. By hand that's a real afternoon, and when I first footed it, page seven wouldn't tie out. Two transactions had landed on a single row during copy-paste, so the running total was understated by the second one. Nothing on screen looked wrong — the figures were just quietly short by one line.

Run the same PDF through the converter and the reconciliation check flagged it as not balancing and pointed at roughly where the gap sat, in seconds rather than an afternoon. That's validation doing its actual job: not telling you the numbers look fine, but telling you when they aren't. See missing transaction detection for more on how a dropped line shows up, and why extracted transactions don't reconcile for the usual extraction culprits.