To batch convert bank statements to CSV for client work, run the whole folder at once but write one CSV per account and statement period. Keep a fixed column order, one date format and one sign rule across every file. Then check each CSV against its statement's opening and closing balance before anything is imported.
Why one CSV per account instead of one CSV per batch?
One CSV per account is the right split because accounting systems import bank lines into a single bank account at a time. A file that mixes two accounts has to be cut apart again before import, and that hand cutting is where lines get lost or posted twice. A per-account file goes straight in.
The batch itself can still be as large as you like. The conversion step benefits from volume: you load one folder, every statement is read in the same pass, and you deal with the failures together. The split only matters at the output end. Think of the batch as one job and the CSV files as many deliveries.
There are three ways to cut the output, and only one of them suits posting:
- One CSV for the whole batch. Useful for a cross-client review or an archive. Useless for import, because it holds many clients and many accounts.
- One CSV per client. Better, but a client with checking, savings and a card still gets a file that mixes three bank accounts.
- One CSV per account per period. Each file maps to exactly one bank feed in one set of books. This is the one to import.
A combined statement that prints checking and savings on the same pages needs a decision before the run. The bank sent one PDF, but you still want two CSV files. The guide to splitting a statement that holds several accounts shows how to separate the sections so each one balances on its own.
Where the per-account rule bends
A batch export for the whole run is still worth keeping. Some bookkeepers sort it by amount to spot outliers across all clients in one view. That file is for reading, though, not for posting. Name it so nobody mistakes it for an import file, for example with the word "review" in the name and the month of the run.
CSV column order for a converted statement batch
A statement CSV needs a date column, a description column and the money, written as either one signed amount or a separate debit and credit pair. Every file in the batch should use the same columns in the same order, with a single header row, so a mapping you set up once in the books works for every client.
Intuit's help article on formatting CSV files for QuickBooks bank uploads describes two layouts. The three-column layout has Date, Description and Amount. The four-column layout has Date, Description, Credit and Debit. The same article says to leave cells blank rather than fill them with a zero, and to label the money headers plainly as "Credit" and "Debit".
Pick one of those two layouts for the whole practice. Mixing them means some clients' imports are mapped one way and some another, and a new staff member will eventually map a file the wrong way round.
Columns worth adding for your own use
Extra columns help review, as long as you know whether the target system will ignore them or reject them. A sensible extended layout looks like this:
- Date
- Description
- Amount (or Credit and Debit)
- Running balance, from the statement where the bank prints one
- Check or reference number
- Source file and page, so a doubtful line can be traced to the PDF
If the import tool only accepts the core columns, keep the extended file as your working copy and produce the slim one for upload. The working copy is what lets you answer "where did this line come from?" six months later.
A sample file, for illustration
The rows below are invented to show the shape of a three-column file with two working columns added at the end:
Date,Description,Amount,Balance,Source
2026-04-02,DEPOSIT MOBILE 0402,1850.00,6210.45,ridgeway-electric_4471_2026-04.pdf p1
2026-04-03,ACH ELECTRIC UTILITY,-312.18,5898.27,ridgeway-electric_4471_2026-04.pdf p1
2026-04-07,CHECK 1093,-725.00,5173.27,ridgeway-electric_4471_2026-04.pdf p2
Which date and sign formats should a statement CSV use?
A statement CSV should use one date format throughout and one sign rule: money out negative, money in positive, in a single amount column. The date format must be one the target import reads correctly, and the same one in every file of the batch, so that 04/05 never means April in one file and May in another.
Dates are the quiet failure. Two banks in the same batch may print 04/05/2026 and 2026-04-05, and a converter that copies each bank's style straight into the CSV produces files that look fine and import wrong. Normalize in the converter, not by hand in a spreadsheet afterwards. Spreadsheet programs also guess at dates when a CSV opens, and resaving a file can rewrite every date in a local format you did not choose.
Sign rules across account types
Signs depend on the account. On a checking account, a deposit raises the balance and a withdrawal lowers it, so deposits are positive and withdrawals negative. Credit card statements print a purchase as a charge that raises what the client owes. If the card CSV keeps the bank's printed sign, purchases arrive as positive numbers and the books read them as money in.
Decide the rule from the point of view of the books: money leaving the client is negative, whatever the statement prints. Then hold every file in the batch to it. Banks that print dates and signs differently are the usual reason one client's file comes out reversed.
Number formats inside the amount column
Amounts should hold digits, an optional minus sign and a decimal point. Currency symbols, thousands separators and trailing "CR" or "DR" markers all confuse imports. Parentheses for negatives, common in printed statements, are another one to convert before the file is written.
Batch converting statements to CSV, step by step
A batch conversion to CSV runs in five stages: gather the folder, convert everything in one pass, set aside the statements that fail, write one CSV per account and period, then check each file. Doing the stages in that order keeps one bad statement from holding up the clean ones.
Here is the run as a step list:
- Gather. Put every statement for the month into one folder or archive. If you send a compressed folder, the notes on what to check before uploading a zip of statements cover nested folders and stray files.
- Convert in one pass. Upload the whole folder. Each file should be matched to its client and account from what is printed on the statement, not only from its name.
- Separate failures. Any statement that cannot be read, or whose transactions do not add up to the printed closing balance, is held back. The routine for handling failed statements after a batch run covers how to rerun them without redoing the whole batch.
- Write the CSV files. One file per account per period, all in the layout you chose, with names that carry client, account and month.
- Check every file. Use the checklist in the next section before any file goes near a client's books.
AutoBankConvert takes a folder of statements across banks and months in one upload and runs a balance check on each before it is marked done. Its exports are QuickBooks and Xero files, per client or per batch, so if you need a plain CSV, ask about it when you request a spot at Get started.
Who should run the batch
The run is mechanical once the layout and names are fixed, which makes it a good task to hand over. A written version of these five steps, plus the checklist below, is the core of the training for a new bookkeeping assistant taking over statement work. Keep the review of failures with someone who knows the clients.
Checks to run on every statement CSV in the batch
Every statement CSV should pass four checks before import: the line count matches the statement, the amounts add up from the opening to the closing balance, every date sits inside the statement period, and the file holds one account only. A file that fails any one goes back to the PDF.
The table below is the per-file checklist. The example column uses invented numbers for a single account.
| Check | How to do it | Example result |
|---|---|---|
| Line count | Count rows (minus header) against transactions on the statement | 47 rows, 47 lines printed |
| Balance | Opening balance plus the sum of the amount column equals closing balance | 4,360.45 + 812.30 = 5,172.75, matches |
| Date range | Sort by date; first and last fall inside the period | 2026-04-01 to 2026-04-30, all inside |
| One account | Source column shows one file and one account ending | all rows from account ending 4471 |
| Signs | Largest deposit is positive, largest payment negative | payroll deposit +1,850.00, rent -2,400.00 |
| Blanks | No cells holding a lone zero in debit or credit | none found |
The balance row does most of the work. If the opening balance plus every amount does not land on the closing balance, a line is missing, doubled or carries the wrong sign. The size of the gap often tells you which: a gap equal to twice one amount points at a flipped sign, while a gap equal to one amount points at a dropped or repeated line.
Doing the checks across a large batch
Opening forty CSV files by hand is slow. Keep a small summary sheet with one row per file: client, account, period, row count, opening, closing and the computed difference. Every difference should read zero. Any row that does not is the only file you need to open.
Statement CSV files that open fine but import wrong
A statement CSV can look perfect in a spreadsheet and still import wrong. The common causes are a date read in the wrong order, a sign reversed for a whole card account, a header row the importer treats as a transaction, and a file saved over by a spreadsheet program that changed its formats.
Each one has a tell you can look for before import:
- Swapped day and month. Every transaction dated after the 12th lands in a strange month, or the import rejects only those rows. Look for a file where all dates fall on day 12 or earlier.
- A reversed card file. Purchases show as deposits. The client's income for the month jumps by roughly the card's total spend.
- Summary rows. Lines such as "Opening balance" or "Total deposits" copied in as transactions. They usually have no date, or the date of the period start.
- Spreadsheet resaves. Long reference numbers turned into scientific notation, leading zeros stripped from check numbers, or dates rewritten in a regional style.
- Encoding problems. Accented payee names turning into odd symbols. Harmless for amounts, but it can stop a categorization rule from matching.
The habit that prevents most of these is simple. Treat the converter's CSV as the original and do not resave it in a spreadsheet program. If you need to edit, edit a copy, then rerun the per-file checks on the copy before it is imported.
When CSV is the wrong output
CSV is a lowest common format. If the client's accounting system has its own import format and your converter can write it, that file usually carries less risk than a CSV you map by hand. Use CSV when you need a neutral file: for a spreadsheet review, for a system with no other import route, or for handing data to someone outside the practice.