QIF format reference

QIF (Quicken Interchange Format) is a legacy bank-export format from the 1990s. Quicken stopped supporting QIF for new imports in 2005, but many older banks still produce it — particularly older online banking portals that haven't been updated. If your bank's only download option is QIF, this page is for you.

For everything else, prefer OFX/QFX or CSV. QIF is supported but it's the format you settle for, not the format you choose.

What's supported

Extension: .qif
Encoding: ASCII / UTF-8 (rarely contains non-ASCII)
Sections: bank account transactions, cash, credit card, investment (limited)

Format structure

QIF is line-oriented. Each line starts with a single-letter prefix indicating what the line means:

!Type:Bank
D04/15/2026
T-642.18
NReference 1042
PLinode
MApril hosting
^
D04/12/2026
T-59.99
PAdobe
MCreative Cloud subscription
^

The structure:

!Type: declares the section (Bank, CCard, Cash, Invst, etc.)
Each transaction is a series of single-letter-prefixed lines
^ on its own line marks end-of-transaction

Field reference

The single-letter codes Solid recognizes:

Code	Maps to	Notes
`D`	Date	`MM/DD/YYYY` or `MM/DD'YY` (the apostrophe variant exists in older exports)
`T`	Amount	Decimal — positive (deposit) or negative (withdrawal). May include thousands separators.
`U`	Amount	Same as `T`; some QIF files use one, some use the other
`N`	Reference number	Check number or transaction reference
`P`	Payee	Free text; usually the merchant or counterparty
`M`	Memo	Additional description
`L`	Category / class	If filled, used as an account hint
`C`	Cleared status	`*` or `c` = cleared, `X` = reconciled, blank = uncleared
`^`	End of transaction	Always literal

Less common, less reliable across QIF dialects:

Code	Notes
`S`	Split-line category — for transactions split across multiple categories
`E`	Split-line memo
`$`	Split-line amount
`A`	Address line(s) — for paper checks; we ignore

Date formats

QIF dates are the most variable thing in the format. Solid accepts:

MM/DD/YYYY — the modern default
MM/DD'YY — the apostrophe variant from older Quicken exports (rendered as 04/15'26 for April 15, 2026)
MM/DD/YY — two-digit year, interpreted same as elsewhere (YY ≤ 49 → 21st century)

Some QIF exports use the European DD/MM/YYYY order — Solid asks for the interpretation at the mapping step if dates are ambiguous.

What QIF doesn't carry well

QIF is bank-statement quality at best, not full accounting data:

No account names — the file represents one account at a time, but the file doesn't say which one. You assign the account at the mapping step.
No double-entry information — QIF transactions are single-sided. The "other side" of every entry is implicit (you mapped the file to one specific account).
No multi-currency — the format predates broad multi-currency support. Currency is whatever the bank exported in.
No transaction IDs — unlike OFX's FITID, QIF has no per-transaction unique identifier. Re-imports are deduplicated by amount + date + payee, which is less reliable.
Splits are dialect-specific — different QIF producers handle split transactions differently; Solid handles the most common Quicken dialect. If splits look wrong, the import preview surfaces them.

Encoding

ASCII-only QIF is universal. UTF-8 is accepted (with or without BOM). CP-1252 is the fallback for older Windows-Quicken exports.

QIF files almost never contain characters outside ASCII because the format predates widespread Unicode support. If yours does (a payee name with accents, an em-dash in a memo), test the import on a few rows first to confirm encoding.

Common errors

"Could not parse date 04/15'26" — older Quicken apostrophe variant. Solid does support this; check the parser's error message — it might be flagging a different bad date in the file. Open the QIF in a text editor and look for the row.

"Unknown section type !Type:Foo" — QIF has dialect-specific section types. Common ones (Bank, CCard, Cash, Invst, Oth A, Oth L) all import. Less common ones (Class, Cat, Memorized) are list-data we don't import — they're for setting up Quicken's UI metadata and don't translate to Solid's model.

"Re-imports show duplicates" — without FITID, dedup is by amount+date+payee. Two coffee purchases for $4.50 on the same day at the same shop look like duplicates to the parser. The import preview lets you confirm vs reject; if you want both, mark them as not-duplicate.

"Splits show up as separate transactions" — the QIF dialect's split format isn't matching ours. Re-export from the source if possible; otherwise, the splits import as separate single-line entries that you can manually merge with a journal entry.

"Transactions in the wrong period" — date format ambiguity (US vs European). Re-run the mapping step and pick the correct interpretation.

When to prefer something else

Bank offers OFX or QFX as well — pick OFX/QFX every time. Better dedup, structured fields, fewer dialect issues.
You're moving from QuickBooks Desktop — IIF or .qbextract migration; QIF is for Quicken-era data, not QB.
You're moving lots of QIF data and they're noisy — consider exporting the QIF, opening in a spreadsheet, cleaning up, exporting as CSV. CSV's column-mapping is more forgiving than fighting QIF dialect quirks.

When QIF is the right choice

Your bank only exports QIF (some smaller credit unions, some legacy financial-institution portals)
You have a one-off batch of historical Quicken data to bring forward
A client gave you a QIF and you don't want to ask them to re-export

Cross-references

OFX/QFX format reference — the better-quality alternative when your bank offers both
CSV format reference — the universal fallback for any source
Import & Export overview — table of every supported format