Bank statement to CSV
What each column in the exported CSV means, and why one of them is allowed to be empty.
Every conversion to CSV produces one row per transaction, with thirteen columns, always in this order.
If a statement contains several accounts they all go into the same file — the account column tells
them apart. (The Excel export does the opposite: one sheet per account, because Excel handles sheets natively.)
The columns
| Column | What is in it |
|---|---|
account | The account name or label as printed on the statement. |
account_type | Checking, savings, loan, credit card, and so on. |
account_number | The account number as shown on the statement — normally already masked by your bank. |
currency | ISO currency code, e.g. USD, GBP, EUR. |
date | The transaction date, as written on the statement. |
value_date | The value date, when the statement prints one separately. Often empty. |
description | The transaction description, as printed. Not cleaned up or reworded. |
amount | Signed. Money out is negative, money in is positive. If your bank prints debit and credit as two columns, they are merged into this one. |
running_balance | The balance after this transaction, if the statement prints one on that line. See below. |
principal | For loan repayments split into principal and interest, the principal part. |
interest | The interest part of the same repayment. |
source_page | Which page of your PDF this row came from. Useful when you want to check a row against the original. |
description_raw | The description exactly as printed on the statement, line breaks included. description is the same text folded to one line; this column keeps the original so you can always compare. |
The file is written as UTF-8 with a byte-order mark. That is deliberate: without it, Excel on Windows mangles non-English merchant names.
Why running_balance is sometimes empty
Because plenty of statements do not print a per-line balance at all, and we will not invent one.
We could compute it — take the opening balance and add up the transactions. We deliberately do not. A computed balance looks exactly like a printed one, so if we had misread a single amount, the computed column would hide the error instead of exposing it. The balance check we run is only meaningful if the numbers in the file are the numbers on your statement.
Same rule everywhere in the export: a value we could not read is empty, never zero.
If part of the file could not be read
When something in your PDF did not make it into the table, the CSV says so — in a comment line at the
very top and a list at the bottom, both prefixed with #. Spreadsheet software will show them as ordinary
rows, which is the point: the warning travels with the file, so whoever opens it next sees it too, even if
that person is your accountant and never visited this site.
Opening it in a spreadsheet without changing it
A CSV is text, and spreadsheet software rewrites text the moment it opens it. Two of those rewrites are worth knowing about before you save over the file.
Long digit strings lose their leading zeros, so an account number printed as 00417 comes back as
417. And anything shaped like a date is reformatted to your regional setting, which can turn a
description such as 3/4 PAYMENT into a date. Neither of those changes the file we handed you —
both happen inside the spreadsheet — but both are written into the file if you then hit save.
If you are only reading the file, open it and ignore this. If you are going to edit it and save it again, take the Excel export instead: it is a real workbook, so every cell already has a type and nothing is re-guessed when it opens.
Importing it
Most accounting tools accept a generic CSV and ask you to map columns. Map date → date,
description → description or payee, amount → amount, and leave the rest unmapped unless the tool asks.
If your software rejects CSV or insists on a bank format, use one of the other four exports instead — QIF is the most permissive, OFX is the open standard, and QBO is the one QuickBooks requires.