Getting a CSV out of a bank statement is easy. Getting one your accounting software accepts on the first try is the actual job — and it fails for boring reasons: a date read as month-first, a decimal comma, a minus sign written in a format the importer doesn't recognise. This guide covers the exact column layouts the major tools expect, the traps that cause rejections, and how to skip the whole problem.

What a bank statement CSV needs

At minimum, three columns: date, description, amount. Where tools differ is how the amount is expressed:

Optional but useful: a Reference or Payee column (many banks print a payment reference distinct from the description), and a running Balance. Balance isn't imported by most tools, but keep it — it's how you verify nothing was dropped, which we'll come back to.

The layouts, tool by tool

Xero

Xero's bank statement import takes Date, Amount, Payee, Description, Reference. One signed amount column. The date format has to match what your Xero organisation expects — this is the single most common failure, and it's why ISO dates (2026-03-15) are the safest thing to export: unambiguous in every locale.

QuickBooks Online

Accepts a 3-column layout (Date, Description, Amount) or a 4-column one (Date, Description, Credit, Debit) with positive numbers in each. QuickBooks generally wants MM/DD/YYYY. If you're in Europe converting a European statement, this is where a European date silently becomes the wrong American one: 03/07 read as March 7th rather than 3 July.

Wave, FreeAgent, and most others

Nearly all accept a date/description/amount CSV with a column-mapping step during import — you point at which column is which. These are the forgiving ones. The mapping step is also your chance to catch a misread column before it lands in your books.

QuickBooks Desktop

Doesn't take plain CSV for bank transactions — it wants QBO or IIF. If someone hands you a CSV and you're on Desktop, you need a converter that emits the right format rather than a spreadsheet.

The five traps that cause rejected imports

  1. Date format. 03/07/2026 is 3 July in Bratislava and March 7 in Boston. If your import lands transactions in the wrong months, this is why. Export ISO (YYYY-MM-DD) wherever the tool allows it.
  2. Decimal separators. A statement from Tatra banka or mBank prints 1.234,56. Feed that to a tool expecting 1,234.56 and you get a number a thousand times too large, or a rejected row. Convert to plain 1234.56 before import.
  3. Thousands separators inside unquoted fields. 1,234.56 in an unquoted CSV cell is two columns, not one. Every amount field should be quoted, or the separator removed.
  4. Negative number styles. Banks write money out as -45.00, 45.00-, (45.00), or 45.00 D. Only the first is universally understood. If your imported debits show up as income, this is the culprit.
  5. Encoding. Save as UTF-8 or Slovak, Czech, German and Polish payee names arrive as mojibake — and some importers reject the file outright rather than mangling it.

Getting the CSV out of the PDF

The free route: Excel

If your statement is a digital PDF with a text layer, Data → Get Data → From PDF in Excel will pull tables out at no cost. Expect to spend time: multi-line descriptions split across rows, columns that drift between pages, headers repeating mid-table. Then save as CSV, fixing the five traps above by hand. Free, and fine for one statement — we walk through it fully in converting a bank statement to Excel. It does nothing at all for scans, since there's no text to extract; that's a different problem.

The direct route

Convert the statement and pick the export shaped for where it's going: plain CSV, a Xero-ready CSV with their exact columns and ISO dates, a QuickBooks Online CSV in the 4-column credit/debit layout, or QBO/OFX/QIF/IIF files for tools that prefer those. All five traps are handled by construction — UTF-8, quoted amounts, plain signed decimals, normalised dates.

Before you import: prove nothing was lost

A CSV that imports cleanly can still be incomplete — and a missing transaction is far more dangerous than a rejected file, because nothing tells you. The statement itself provides the check: opening balance + credits − debits = closing balance. If your rows satisfy it, nothing was dropped or misread; if they don't, something is missing before it ever reached your books.

In a spreadsheet that's =SUM(D:D) against the printed totals. Every Statement Mill export runs this reconciliation automatically and shows the result per file — it's the whole reason the tool exists.

CSV or OFX? A quick word

If your software accepts OFX or QBO, prefer them: they carry unique transaction IDs, so importing an overlapping period twice gets flagged as duplicates instead of quietly doubling your books. CSV has no IDs — duplicate imports are easy to create and tedious to unwind. Choose CSV when you want to review or edit rows before importing, or when it's the only format on offer.

The short version

Match the layout your tool documents, export ISO dates and plain signed decimals in UTF-8, and check the balances before importing. Do those three and CSV import stops being a chore that eats an afternoon. Convert your first statement free — 3 pages without signing up, 20 with an account — and the CSV comes out already shaped for wherever it's going.