QIF to CSV

What QIF is, and why it fights you

QIF stands for Quicken Interchange Format. It’s what old Quicken versions, plus a surprising number of banks, still spit out. Open one in a text editor and you get D6/14'26 on one line, T-42.50 on the next, and a lone ^ marking where a transaction ends. Each line is a single-letter code plus a value. Human-readable? Barely. Spreadsheet-friendly? Not at all.

That’s the gap this fills. Paste the QIF text on the left and a proper CSV table comes out on the right, one row per transaction, with named columns you can sort and filter. It re-parses as you type, so you can fix a stray line and watch the output update live.

What each field code becomes

QIF packs everything into terse codes. Here’s the mapping the parser uses:

• D is the date. Quicken’s date format is genuinely awful, so it gets normalized to YYYY-MM-DD where possible. That D6/14'26 becomes 2026-06-14, apostrophe and all.
• T and U both carry the amount. They’re duplicates in Quicken’s own files, so whichever is present fills the Amount column. Thousands separators like 1,200.00 get cleaned up.
• P is the payee, the store or person on the transaction.
• L is the category. Transfers wrapped in [brackets] come through untouched so you can spot them.
• M is the memo or note.
• C is the cleared flag. A * or c reads as “Cleared”, an X or R reads as “Reconciled”, and blank stays blank.
• N is the check or reference number, dropped into its own column.

Split-transaction lines (S, E, $) and address lines (A) don’t map to these seven columns, so they’re skipped rather than mangled.

Things to watch out for

Dates are the part most converters get wrong. QIF almost always uses US month-first ordering, and Quicken marked 2000s years with an apostrophe instead of a four-digit year. So 6/14'26 is June 14, 2026, not the 6th of something. Two-digit years without an apostrophe pivot at 70: 69 reads as 2069, 70 reads as 1970. If a date doesn’t match any known shape, it’s passed through as-is instead of being guessed at and silently corrupted.

Amounts keep their sign. A debit stays negative, a deposit stays positive, exactly as the file recorded it. The CSV follows RFC 4180 quoting too, so a payee like Netflix, Inc. with a comma in it gets wrapped in quotes and won’t split across two columns when Excel opens it.

Messy files happen. A record missing its date and amount, or a trailing block with no closing ^, gets noted in an amber box above the output instead of crashing the whole conversion. You still get every valid transaction, plus a short list of what looked off.

Nothing gets uploaded. The parsing runs in JavaScript on your machine, which matters when the file is your actual bank history with payees and balances in it.

FAQ

My bank exported QIF instead of CSV. Will this work?

Almost certainly. Banks that offer QIF use the same D/T/P/L codes Quicken does. Paste the file contents and check that the dates and amounts look right.

Why is the date format different from my file?

It’s normalized to YYYY-MM-DD so spreadsheets sort it correctly. Quicken’s M/D'YY format sorts alphabetically, which scrambles the order. If a date can’t be parsed, it’s left exactly as written.

Are split transactions handled?

Not as separate rows. The S/E/$ split lines are skipped, so a split transaction shows up as a single row with its top-level amount, not one row per split.

Does it open the .qif file directly?

Not yet. QIF is plain text, so open it in any editor, copy everything, and paste it in. Takes a few seconds.

What does the Cleared column mean?

It reflects QIF’s C flag. * or c means the transaction cleared the bank; X or R means you reconciled it against a statement. Blank means neither was set.

Is my financial data sent anywhere?

Nope. Everything stays in your browser. No server, no upload, no logging, so it’s fine for real account exports.