What your accountant actually wants from your bank statements

The email arrives in January and says almost nothing: please send your bank statements for the year, in Excel if possible. You have twelve statement documents per account, a banking app that will not export more than ninety days, and no idea whether "in Excel" means a spreadsheet of transactions or the statements themselves dropped into a workbook. Getting this wrong costs a round trip, and round trips at year end are the reason a return sits unfinished for three weeks.

What your accountant wants is narrow and specific. They want the transactions as data, complete, unedited, and traceable back to the statement they came from.

What "in Excel" actually means

It means one row per transaction, in a table where every field occupies its own column, so the file can be sorted, filtered, summed and imported. A statement page pasted into a sheet does not qualify, however much it resembles one on screen.

The distinction matters because a pasted statement looks like a table and does not behave like one. Descriptions and amounts land in the same cell, single transactions split across two rows, and the amount column arrives as text so it will not sum. None of that is usable until somebody repairs it, and repair work at year end is time spent on formatting instead of on the accounts.

The columns to send

The column set below covers what any accountant or bookkeeping system needs.

• Date. One consistent format across every row and every account. Where a statement shows both a transaction date and a posting date, send both in separate columns rather than choosing between them.
• Description. Exactly as the bank printed it, including the reference codes that look like noise. Those codes are often the only way to identify a payment later.
• Amount. Either one signed column, with money out negative, or separate debit and credit columns. Ask which they prefer; if you cannot ask, a single signed column is the more portable choice, and the trade-offs between the two are covered in choosing an export format for bank statements.
• Running balance. The figure printed against each transaction on the statement. This is what lets anyone check the file without reading the original.
• Account identifier. The last four digits of the account, or the account name. Once rows from two accounts sit in one workbook, a table without this column cannot be pulled apart again.

Everything past those is optional. A sixth column for your own notes is welcome. Twelve columns of your own analysis is not.

Send the whole period, and every account

Coverage is where most client submissions fall short. Send every month of the accounting period, in order, with no gaps. Send every account the business touched: the current account, the savings account you moved a lump sum into once, the card, and the account you thought was dormant. A dormant account that received a single payment in August is exactly the one that produces a question in March.

The reason is not thoroughness for its own sake. Your accountant reconciles what the books say against what the bank says. Any account outside the file is an account where those two cannot be compared, and unexplained money is the slowest thing to resolve at year end.

When several accounts are involved, combining them into one workbook with a consistent column set is more useful than sending eleven separate files with eleven different layouts.

Run one check before you send

There is a single check worth running on the converted file, and it takes under a minute per account. Take the opening balance from the first statement, add everything that came in, subtract everything that went out, and compare the result against the closing balance on the final statement.

For a year on a small business current account, that looks like this: an opening balance of 4,182.06, total money in of 61,340.00, and total money out of 58,927.44, giving 6,594.62. If the final statement also says 6,594.62, the file covers the period with nothing missing at the ends.

That endpoint check only tells you the period closes where the bank says it closes. It rests on one figure, and one figure can come out right for the wrong reasons: a row lost in April and a row of the same value duplicated in September cancel each other, and the calculation still lands on 6,594.62.

Rechecking every row rather than the two ends is what closes that gap. Each transaction's balance is recalculated from the opening figure, compared against the balance printed on the statement, and flagged where the two disagree, so a wrong digit in an amount lands on a named row instead of disappearing into a total. The cancelling pair cannot hide from it either: the lost row throws the recalculated balance out from April onward, and every row between there and the duplicate is flagged even though the year closes.

What it still does not reach is whatever the arithmetic never touches. Dates, descriptions and the categorisation that comes later take no part in the equation, a row for 0.00 satisfies it whatever else is wrong with it, and on a statement layout that prints no running balance column there is nothing to recalculate against in the first place. So read the flagged rows and spot check the dates at each month boundary. The full routine is set out in how to verify a converted bank statement.

Getting the file made

1. 1

   Download every statement for the period

   Collect the statement documents for each account, month by month, straight from online banking rather than the transaction list in the app. The app view is capped by date and usually drops the running balance.
2. 2

   Convert them in one batch

   Upload the statements together and let the engine read each bank's layout. There is no template to configure per bank, which matters when the business banks in two places.
3. 3

   Review anything flagged

   Open the rows the running-balance check flagged and compare them against the statement page. This is the only proofreading the file needs.
4. 4

   Add the account identifier and export

   Label the rows by account, export to spreadsheet or CSV, and name each file so the account and period are obvious from the filename alone.
5. 5

   Send the statements alongside the file

   Attach the original statement documents in the same message. The spreadsheet is the working copy; the statements are what it is checked against.

If the period runs to several hundred pages across multiple accounts, the mechanics of doing it in one pass rather than a month at a time are covered in converting a full year of bank statements.

What to leave out

Do not send a summary. A total for "office costs" is a conclusion, and your accountant needs the transactions that produced it, because the classification is the part they are responsible for.

Do not send retyped data. Rekeyed figures carry transposition errors that nothing in the file will catch, and the running balance you typed from the statement will agree with itself while disagreeing with the bank.

Do not redact by deletion. If a payment genuinely must not be described, keep the row, keep the amount, and replace only the description text, so the balance chain survives.

Naming is the last piece and the cheapest to get right. A file called current-4471-2025.xlsx tells your accountant what it is without opening it. A file called bank final FINAL v3.xlsx starts a conversation neither of you wants in the last week of the deadline.