Getting a bank statement into GnuCash
GnuCash will read three transaction formats, so the question is not whether your statement can get in, but which route causes the least trouble. The short answer: OFX, because it is the only one of the three that carries a transaction id.
🔒 Convert your statement now — CSV or PDF in, OFX or QIF out, free, nothing uploaded.
What GnuCash accepts
From the GnuCash manual:
| Format | Menu |
|---|---|
| OFX / QFX | File → Import → Import OFX/QFX transactions |
| QIF | File → Import → Import QIF... |
| CSV | File → Import → Import Transactions from CSV |
The manual also notes that "Files using these formats do not necessarily use the file extensions shown above" — so judge a file by what is inside it, not by what it is called. Renaming a CSV to .ofx does not make it one.
Why OFX rather than QIF
This is the part worth understanding before you pick, because it decides how much tidying you do later.
An OFX file gives every transaction a unique id. Import an overlapping date range twice and the importer can recognise what it has already seen. A QIF file has no such field, so nothing in the file tells GnuCash that two imports overlap — import January to March, then February to April, and February and March arrive twice.
If you are importing month by month and never overlap, QIF is fine. If you are catching up on a year, or you are not certain where the last import stopped, OFX will save you an evening.
And why not just use GnuCash's CSV importer?
Often you should. If your bank's CSV is already tidy — one date column in a format GnuCash parses, a description, a single signed amount — then importing it directly is one step and there is no reason to involve a converter. Being honest about that is cheaper than pretending otherwise.
It is worth converting when the export is awkward, which bank exports usually are:
- Separate Paid in and Paid out columns instead of one signed amount.
- Day-first dates that get read as month-first, or the reverse. More on that below.
- Thousands separators, currency symbols, parenthesised or trailing-minus negatives.
- Title rows, address blocks and a closing-balance line that are not transactions.
- Only a PDF available, with no CSV export offered at all.
The date trap, which is the expensive one
A date like 04/01/2026 is both 4 January and 1 April depending on which way it is read, and both are valid dates, so nothing can flag it as an error. If your statement is day-first and the import reads it month-first, your transactions are silently filed in the wrong months. The totals still add up; the reconciliation just never matches.
QBOKit decides the order once, from the whole date column, not row by row — so one file does not end up half day-first and half month-first. The preview shows dates as YYYY-MM-DD precisely so you can confirm the reading before you download. More in wrong dates after import.
Starting from a PDF
If your bank only gives you a PDF, that works too: the PDF is read in your browser, the table is reconstructed from it, and you get the same OFX or QIF out. It needs a PDF with real text in it, which bank-issued statements normally have; a scan or photo would need OCR, which this tool does not do. See converting a PDF statement.
Steps
- Export a CSV from your bank, or download the PDF statement.
- Drop it on the converter. Everything happens in your browser; the file is not uploaded anywhere.
- Check the preview, in particular one date between the 1st and the 12th of a month.
- Choose OFX (or QIF if you have a reason to) and download.
- In GnuCash, use File → Import → Import OFX/QFX transactions and point it at the file.
Or see it work on a sample statement — no file of your own needed.
Sources
- Importing Transactions from Files — GnuCash Manual v5, source for the three accepted formats, the menu paths, and the note about file extensions.