You have a .qif file — years of Quicken history, an old Microsoft Money export, a GnuCash
interchange file, or a legacy bank download — and you need it in a spreadsheet. Maybe you're
reconstructing records for taxes, migrating to new software, or settling an estate where the
only financial history anyone can find is a Quicken backup. Quicken itself stopped importing
QIF for bank accounts back in 2005, so even owning Quicken doesn't necessarily help. Here's how
to get it done without Quicken at all.
Why renaming .qif to .csv doesn't work
A CSV holds one record per line with comma-separated columns. A QIF file is the opposite shape:
one field per line, where the first character says what the field is (D date, T amount,
P payee), and a ^ line ends each transaction. Opened raw in Excel you get a single column of
cryptic codes — every transaction smeared across eight rows. On top of that, the fields
themselves need interpretation: dates come in four different formats, amounts may have thousands
commas, and split transactions spread one purchase across repeating S/E/$ line groups. For
the full breakdown of the format, see What is a QIF file?
Convert QIF to CSV in your browser
The free QIF to CSV converter on LegacyFile does the actual parsing:
- Drop your .qif file into the converter. Parsing happens entirely on your device — nothing is uploaded, which matters when the file is your complete financial history.
- It walks every section —
!Type:Bank,!Type:CCard,!Type:Cash, investment sections — and tracks!Accountblocks in multi-account exports, so every row knows which account it came from. List sections like the category list are skipped, not mistaken for transactions. - It resolves the date ambiguity file-wide. QIF dates can be
01/15/2024,15/01/24, or the 2000s Quicken quirk01/15'04. The converter scans the whole file for evidence (any day above 12 settles which position is the month), reads every date consistently, normalizes them toYYYY-MM-DD, and tells you which format it detected — with a warning if the file was genuinely ambiguous. - It keeps split transactions honest. A split stays as one row with its total in the Amount column, the legs itemized in the Category cell ("Office Supplies $-600.00; Computer Equipment $-400.00"), and a Splits column counting the legs — so your spreadsheet sums to the real balance change with nothing double-counted.
- Check the summary and preview, then export CSV, XLSX, or JSON. The CSV/XLSX opens directly in Excel, Google Sheets, or Numbers.
What ends up in each column
| Column | Source |
| -------- | ---------------------------------------------------------------------- |
| Date | The D line, normalized to YYYY-MM-DD under the detected format |
| Amount | The T line (or its U duplicate), parsed to a plain signed number |
| Payee | The P line |
| Memo | The M line, plus split memos and any multi-line address |
| Category | The L line — or the itemized split legs for a split transaction |
| Number | The N line: check number, or the action (Buy, Sell) for investments |
| Cleared | The C line's status character, as written |
| Account | The active account from the most recent !Account block, when present |
| Type | The section the transaction came from: Bank, CCard, Cash, Invst... |
| Splits | How many split legs the transaction had (0 for a simple transaction) |
When something looks off
The converter never fails silently. An amount it can't parse, a date that fits neither format, a
record missing its closing ^, or a file where every date could be read both ways — each gets
kept and flagged in a warnings list instead of being dropped or crashing the conversion. That's
the safest default when the source system that wrote the file was discontinued years ago and
there's no re-exporting the data.
One last tip: if the same source can still produce an OFX or QFX download, prefer it — it's a
stricter format with none of QIF's ambiguity, and LegacyFile's
OFX to CSV converter handles it the same way. But when all that survives is
the .qif, that's exactly what this converter is for.