Bank statement to QIF
The oldest and most permissive format. Some information cannot survive it, and this page says exactly which.
QIF is the oldest of the five formats we export, and the most widely accepted by older desktop
software. It is plain text, one record at a time, each ended with a ^. It also has the fewest
fields, which means converting to QIF loses information. We would rather tell you which.
What is in the file
For each account, a type header — !Type:Bank for checking and savings, !Type:CCard for credit
cards, !Type:Oth L for loans — followed by one record per transaction carrying the date, the
amount, and the description as printed on your statement.
We write only the fields QIF actually defines. We do not invent tags to smuggle the rest through: an unknown tag makes many importers stop with an error, which is worse than a missing field.
Dates are exported in US month/day order
A date written 03/04'2026 in our QIF means 4 March 2026, not 3 April.
QIF has no way to say which order it is using — the file just contains numbers, and the importing software applies whatever regional setting it happens to have. We picked month/day because it is what the format’s original software expects. If you are in Europe, check that your accounting tool is reading these as US dates before you import a year’s worth of transactions.
If that ambiguity worries you, use OFX or QBO instead. Both carry an unambiguous date and there is nothing to configure.
What QIF cannot carry
- Currency. There is no field for it. If your statement is not in your accounting tool’s home currency, the tool will assume it is.
- The account number. Even the masked form your bank prints has nowhere to go.
- The principal/interest split on loan repayments. QIF has no concept of it.
The last one we refuse to simply drop, because on a loan statement it is the point of the whole
document. So the split goes into the memo line as text — something like
principal 412.66; interest 87.34. Your software will show it to a human but will not do arithmetic
with it. If you need the split as real numbers, take the Excel or
CSV export, which have proper columns for both.
What one record actually looks like
QIF is plain enough to read with your eyes, which is occasionally useful when an import goes wrong:
!Type:Bank
D03/04'2026
T-128.40
PSQ *CORNER BAKERY
^
D is the date in the month/day order described above, T is the signed amount, P is the payee
line carrying the description as printed on your statement, and ^ ends the record. On a loan
statement one more line appears, M, holding the principal and interest split as text.
Two details of that are ours rather than the format’s. The description goes on the P line even
when it is plainly not a payee name, because that is the line every importer displays. And a
description that ran across two lines on your statement is folded onto one here, since QIF records
are line-based and a stray newline ends the field early.
How the “we could not read this” warning appears
QIF has no comment syntax at all. So when part of your PDF did not make it into the file, we write
the warning as !Note: lines at the top.
That is a workaround, not standard behavior, and it is worth knowing why it is safe: importers
ignore ! lines they do not recognize, so the notes travel with the file without breaking the import.
It matters that the warning is in the file and not only on this website — the person who opens the
file next may be your accountant, who never saw our site at all.