Audit Preparation Using Bank Statements

This guide is written for practising accountants and bookkeepers who do this work every year-end. It assumes you already know what a substantive test is; what tends to eat the hours is the mechanical part — turning a stack of scanned PDFs into reliable, reconciled data the audit file can rely on.

What auditors actually want from the bank evidence

Auditors are testing two assertions above all: completeness (every transaction that happened is recorded) and existence (every recorded transaction really happened). Bank statements are the primary independent evidence for both, which is why a clean statement workflow saves you so much back-and-forth.

In practice the file needs to show three things tie together: the bank statements themselves, the cashbook or ledger, and the bank reconciliation that bridges any timing differences. The bank confirmation letter then independently confirms balances. Where reviews fall apart is almost never the reconciliation logic — it's a transcription error somewhere upstream, one line dropped or fat-fingered while the data was being keyed in from a PDF.

A worked example of how small that error can be, and how much it costs: a client's June statement runs to fourteen pages. On page nine, a 2,340.00 supplier payment gets read as 2,310.00 during data entry. Nothing looks obviously wrong — both are plausible numbers. But the ledger is now 30 out, the reconciliation won't balance, and you lose forty minutes scrolling pages to find a thirty-quid typo. Multiply that across a dozen accounts and you've lost a morning before any real testing starts.

A workflow that holds up to review

Here's the sequence I use when prepping a year's worth of statements for audit. It's deliberately boring, because boring is what survives a file review.

1. Collect a complete set, in order. Get every month for the period under audit, plus the month either side so you can verify opening and closing cut-off. Confirm there are no gaps in statement numbers — a missing statement is the single most common completeness hole.
2. Extract every transaction, including the balance column. Convert each PDF to a spreadsheet with date, description, money in, money out and the running balance preserved. Keep the balance — it's your checksum, and most exports throw it away.
3. Reconcile each statement to itself. Opening balance plus net movement should equal the stated closing balance. Do this per statement, not just for the year as a whole, so an error is isolated to one month instead of buried in twelve.
4. Tie the closing balance to the next opening balance. Month-to-month continuity proves you haven't skipped a period. Any break here is a gap you need to chase before the auditor does.
5. Agree the year-end balance to the bank confirmation. This is the independent check that the whole chain is real, not just internally consistent.
6. Sample for existence. Pull your high-value and unusual items and trace them to invoices, contracts or remittances. Completeness gets you the population; existence tests the population is genuine.

Step 2 is where the hours hide, and step 3 is where the differentiator earns its keep.

Where the reconciliation check changes the prep

Most PDF-to-spreadsheet tools stop at "we turned your statement into a grid." They give you no way to know whether they got everything — and a converter that silently drops one line on a long statement is worse than useful, because you'll trust a number that's quietly wrong.

Export Bank Statement does the part that matters for audit prep: it treats the running balance as a checksum on every line. After it extracts the transactions, it recomputes the balance from opening to closing and flags any statement that doesn't reconcile. You get a clear pass or a clear warning before you trust a single figure. That's the same completeness check a careful preparer does by hand — except it runs on every line of every page, and it doesn't get tired on page forty of a twelve-month set.

It handles scanned and photographed statements too, via OCR, which is where manual rekeying causes the most damage. A blurred "7" read as a "1", a comma swallowed in a thousands separator — those are exactly the errors the balance check catches, because a misread figure breaks the running total.

One honest limitation worth stating plainly, because it shapes the workflow: the tool converts statements and exports a clean CSV; it does not push transactions into Xero, QuickBooks or Zoho Books over a live bank-feed API. The path is convert, check the reconciliation result, then import the CSV. For audit prep that's actually the right shape — you want a reviewed file you can attach to the working papers, not a silent sync you can't point an auditor at.

Building the audit trail the file needs

A reviewer should be able to follow the evidence without asking you a single question. That means file structure as much as data quality.

Name each export by account and period — `business-current-2025-06.xlsx` beats `download (4).xlsx` when you're three weeks into fieldwork. Keep the original PDFs alongside the converted spreadsheets so the source is one click away. Where a statement was flagged and you fixed something, leave a short note saying what and why; a one-line explanation now prevents a query later.

If the engagement covers VAT, the same converted data carries straight into your indirect-tax checks — there's more on that in the VAT review using bank statements guide. And if you're doing broader fieldwork on the numbers, bank statement analysis for accountants covers cash-flow, recurring-payment and merchant patterns that often surface the unusual items worth sampling.

On privacy, which audit clients ask about more every year: files are processed and then deleted, and they're never used to train AI. That's an easy reassurance to give a client handing over a year of bank data, and it's worth saying before they ask.