How Accountants Validate Imported Data

Validation is not the same as trusting a tidy-looking spreadsheet. Imported data can look immaculate and still be short two transactions or carry a transposed digit. The job is to catch that before it becomes a wrong VAT return or a year-end that won't close.

Why validation is a control, not a glance

In practice, validating imported data is part of your file's controls, the same way you'd evidence a sample or document a judgement. It's the step that lets you sign off on figures you didn't key yourself.

Here's the distinction that trips people up. Completeness and correctness are two separate questions, and passing one tells you nothing about the other. A statement can be perfectly correct on every line it shows and still be missing three lines that never imported. It can show every line and have one figure read 1,920 instead of 1,290. You need a check that catches both, because clients and converters fail in both directions.

The running balance is the only single test that covers both at once. The bank prints a balance after every transaction — the account's true position at that exact moment. Recompute that column yourself from the opening figure, applying each transaction in order, and your number has to agree with the bank's at every row. 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 maths breaks, and the first row where your figure stops matching the bank's is the precise location of the problem. That's a checksum on the whole period in one pass.

A validation workflow you can put on a file

This is roughly the order I work in when client data arrives — whether it came from a portal upload, a PDF the client emailed, or a scan of a paper statement.

1. Confirm the source and the period. Right account, right entity, exact dates. Note the opening and closing balances printed on the statement before touching anything — those two figures are what everything reconciles against.
2. Chain the opening balance. This period's opening balance must equal last period's closing balance. A break in that chain means a gap exists before you've validated a single line, and this period's check won't close it.
3. Recompute the running balance line by line. Opening figure, apply each credit and debit in date order, confirm your 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 plus total credits minus total debits must equal the printed closing balance. Ties to zero, the period is internally consistent. Off by anything, treat the whole import as unvalidated until you've found the cause.
5. Sanity-check the data that passes the maths. A duplicated transaction that nets correctly, a date sitting outside the period, a garbled description, a credit dropped into the debit column on a single-amount layout. These survive the running balance, so you look for them deliberately.

Document which of these you ran. When a query comes back at year-end, "I reconciled the running balance and it tied" is a defensible answer. "It looked right" isn't.

Where imported data actually goes wrong

The PDF, scan or photo adds a failure point that doesn't exist on the original: extraction. And extraction breaks the maths without breaking the appearance, which is exactly what makes it dangerous on a client file.

The same handful of slips come up again and again. A row vanishes in the seam between two pages, so the period is quietly short one transaction. A wrapped description splits one payment into two phantom rows, inflating the count. Two digits transpose, so 1,290 imports as 1,920. A credit lands in the debit column on a layout where the bank prints one signed amount instead of two in/out columns. None of these wave a flag — 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 clean-looking import 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 the VAT box won't agree or the year-end balance refuses to tie.

So validating imported data means running 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 came through intact. If it doesn't, extraction introduced an error and you've caught it before it reached the ledger.

What this means for VAT and year-end

Validation is upstream of everything you report. A missing line that drops a standard-rated sale understates output VAT. A duplicated purchase overstates input VAT. Neither shows up as obviously wrong on the face of the return — the numbers are just quietly off by the value of the line that broke. Under Making Tax Digital, the figures flow through from your records with no manual re-key to catch it, so the validation has to happen at the point the data comes in.

Year-end is the same problem with a longer fuse. An import that didn't reconcile in month three sits in the books until the closing balance won't agree twelve months later, and then you're hunting one transaction across a year of postings. Catching it at import — when the running balance first breaks — turns an afternoon of detective work into a thirty-second fix.

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're not handed numbers and left to trust them. You get a result. If the period reconciles, you see a confirmation before you download anything. If it doesn't, the statement is flagged rather than quietly passed along, and you know to look before you post a single line. For a practice processing client packs at volume, that's the validation control done for you on every file.

One honest point about where this stops. Once the data is validated, the path into your 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. Treat it as producing a verified import file, not a one-click sync. Working from PDFs after the fact, that's the cleaner route anyway: you already know the file balances before it reaches the ledger.

Manual validation versus a checked conversion

The two middle rows are the point. 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 on a Friday afternoon. A recomputed running balance doesn't get tired on page seven.

A worked example

A client quarter, roughly 240 transactions over an eleven-page PDF. By hand that's a real afternoon, and the first time I footed it, page seven wouldn't tie. 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 a line, and that line happened to be a standard-rated sale.

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, before the wrong figure reaches a return. For the wider workflow this sits in, see bank statement analysis for accountants and the client bank data collection guide; the accountants and bookkeepers hub pulls the rest of the practice guides together.