Bank Statement CSV Format Explained
There is no such thing as the bank statement CSV format. Every bank invents its own, and the differences between them are the reason a file that opens perfectly in one program is unreadable in the next.
Published 9 August 2026 · 6 min read
The short answer
There is no standard, and no specification to point at. CSV itself defines only how to separate values on a line. It says nothing about what those values mean. Everything above that is decided by each bank on its own: which column is the date, how a debit is marked, what a thousands separator looks like.
That is why the honest version of this question is not *what is the format* but *what varies between them*, which is a question with a real answer and a fairly short one.
If you are trying to work out whether a file will be read by something, open it in a text editor first. Everything that matters is visible in the first three lines, and this page is essentially a list of what to look at.
What every bank statement CSV has in common
Three fields, and only three are universal: a date, a description, and an amount. Everything else is optional and plenty of banks omit all of it.
A running balance column is common and genuinely useful, because it makes a file self-checking. Each row's balance should equal the one above it plus that row's amount, so a missing transaction is detectable from the file alone. Reference numbers, transaction type codes, categories and cheque numbers all turn up, and none is dependable.
The five things that differ
Almost every failed import comes down to one of these.
| What varies | What you will see |
|---|---|
| The separator | A comma, a semicolon, or a tab |
| The decimal mark | 1,234.56 in the US and UK; 1.234,56 across much of Europe |
| The date order | 05/01/2026 meaning 5 January or 1 May, with nothing saying which |
| How money out is marked | A minus sign, parentheses, or a separate column entirely |
| What sits above the data | Nothing at all, or ten lines of account details first |
The semicolon is not a quirk. It is a direct consequence of the decimal comma. A locale that writes 1.234,56 cannot also use the comma as a field separator, so it uses a semicolon, and the file is still a perfectly ordinary CSV.
Three shapes, all of them normal
A US-style export: one signed amount column, a running balance, dates month-first.
Date,Description,Amount,Balance 01/05/2026,COFFEE SHOP,-24.50,1482.19 01/09/2026,CLIENT INVOICE 1042,1250.00,2732.19
A UK-style export: debits and credits in separate columns, dates day-first, and an empty cell wherever a row is not that kind of transaction.
Date,Description,Debit,Credit,Balance 05/01/2026,COFFEE SHOP,24.50,,1482.19 09/01/2026,CLIENT INVOICE 1042,,1250.00,2732.19
A European export: semicolons, comma decimals, and money out written in parentheses rather than with a minus.
Datum;Beschreibung;Betrag 05.01.2026;KAFFEEHAUS;(24,50) 09.01.2026;RECHNUNG 1042;1.250,00
All three are valid, all three are common, and a tool that handles one and not the others is the usual reason a statement will not go in.
One amount column, or two?
This is the split worth understanding, because it changes what a number means. In a single-column layout the sign carries the direction: -24.50 is money out and 1250.00 is money in. In a two-column layout the *column* carries the direction and the figures are usually both positive, so a 24.50 under Debit means the same as -24.50 in the other shape.
Reading a two-column file as though it were a one-column file is the failure that does the most damage, because it does not error. Every debit comes through positive, the statement appears to be almost entirely income, and the total is wrong by twice the value of every payment.
Column headings for the pair are not standardised either. Debit and Credit, Money In and Money Out, Paid In and Paid Out, Withdrawals and Deposits are all in circulation, and some banks label them in the file and not in the export.
The rows that are not transactions
A bank statement CSV is frequently not a clean table. Exports carry account details, an address block or a date range above the header row. Totals sit at the bottom. Page footers repeat through the middle where the export was generated from a printable statement, and blank rows separate sections.
None of that is malformed. It is a report that happens to be saved as CSV rather than a data file, which is a distinction worth keeping in mind when a spreadsheet opens it into an obvious mess. What makes those rows identifiable is that they carry no usable date, which is the one field a real transaction always has.
Every layout on this page is read without configuration, and where a layout cannot be read you are shown the file and asked to point at the columns yourself. Nothing is uploaded.
Convert a statement CSVHow to tell what you have
Open the file in a text editor rather than a spreadsheet. A spreadsheet has already made decisions about it by the time you see it, and those decisions are what you are trying to inspect. Then read the first three lines and answer five questions:
- Is the separator a comma, a semicolon or a tab?
- Is the decimal mark a point or a comma?
- Is there one amount column or a debit/credit pair?
- Does any date have a first number above 12? If so the file is day-first and you know it for certain.
- Is there anything above the header row, and does the file end with a totals line?
That is the entire inspection, and it takes about fifteen seconds once you know what you are looking for.
What a CSV cannot tell you
Nothing in the file says which bank it came from, which account, or what period it covers, unless a human put that in a preamble row. There is no field for any of it. That is the difference between a CSV and an OFX document, and the reason a CSV converted to .qbo cannot name the institution unless you say which one.
It also has no notion of a transaction identity. Two identical payments on the same day are indistinguishable, so loading the same statement twice gives you every transaction twice with nothing to detect the overlap.
And critically, a CSV cannot tell you it is incomplete. A file missing its last page parses perfectly. The only defence is a running balance column, or knowing the opening and closing figures from the statement itself and checking the transactions against them.
Frequently asked questions
Is there a standard bank statement CSV format? No. CSV defines only how values are separated on a line; what the values mean is decided by each bank. Two statements from different banks can share no column names, no date order and no decimal convention while both being entirely valid.
Why does my CSV open with everything in one column? Almost always because the file uses semicolons and your spreadsheet expected commas, which is normal for a file exported in a locale that writes decimals with a comma. Most spreadsheets let you choose the separator on import rather than double-clicking the file.
My dates came out wrong. Why? Because 05/01/2026 is 5 January in the UK and most of Europe, and 1 May in the US. Nothing in a CSV states which convention it used. The only certain signal is a date whose first number is above 12, since 19/02 can only be day-first. A file with no such date can be read either way without anything looking wrong.
Why do my debits come through as positive numbers? Because your file has separate Debit and Credit columns and something read it as a single amount column. In a two-column layout the direction is carried by which column the figure is in, not by its sign, so the figures are usually both positive and need the column to be interpreted.
Should I edit the CSV before converting it? Usually not, and opening it in a spreadsheet to do so is how dates get silently reformatted and leading zeros get dropped. Preamble rows, totals lines and page footers carry no date and are skipped automatically. If a layout genuinely cannot be read, pointing at the columns is safer than editing the file.