QIF Converter — and the Modern QFX/OFX It Replaced

What QIF actually is

QIF (Quicken Interchange Format) is an old, plain-text format Intuit used before OFX. It marks records with an account-type header and one-letter field codes — D for date, T for amount, P for payee, M for memo — each transaction ending with a caret.

A fragment looks like this:

!Type:Bank
D03/03/2026
T-42.30
POffice Supplies
MCard payment
^
D03/05/2026
T1200.00
PClient Payment
^

Why Quicken moved to QFX and OFX

Intuit deprecated QIF import for bank and credit-card accounts in modern Quicken in favour of QFX (Quicken's flavour of OFX). The reason is reliability: QIF had no account matching and no standard for balances or unique IDs, so imports frequently duplicated transactions or landed in the wrong account. QFX/OFX carry account identifiers and transaction IDs that make the import clean and de-duplicated.

Why QIF still gets searched

Plenty of long-running setups still lean on QIF: older Quicken versions, GnuCash, some budgeting tools, and scripts built years ago. If your tool only reads QIF, that requirement is real — but it is worth checking, because most modern software has moved to OFX-based feeds or CSV import.

Where your tool accepts OFX or CSV, you'll get a cleaner result than QIF ever gave — with the right account matched automatically and duplicates skipped rather than doubled.

What FlowParse gives you

FlowParse turns your statement PDF into the format most likely to import cleanly:

Why FlowParse skips QIF

Producing QIF would mean handing you a format its own vendor retired for bank imports — one with no account matching and no duplicate protection, so the very import you're trying to do would be prone to doubling transactions. That is a worse result, not a feature.

FlowParse instead gives you QFX/OFX, which import into Quicken as a proper feed, plus CSV for the legacy cases. It is the honest choice: the format that actually works, not the one that merely matches the search term.

What FlowParse reads from the statement

From the PDF, FlowParse captures the account summary and every transaction — date, description/payee, a signed amount, and the running balance. That is everything QIF encoded and more, since QFX/OFX also carry the account and transaction identifiers that make the import reliable.

Card payments, transfers, direct debits and fees keep their payee and memo text as printed, so the register you end up with reads the way the statement did.

flowparse.io

How to import your statement into Quicken

A clean Quicken import, no mapping

Because a QFX file carries the account and transaction IDs Quicken expects, importing it matches the account automatically and skips transactions you've already recorded. There is no column mapping and no manual account selection — the friction QIF was infamous for simply isn't there.

That reliability compounds when you import month after month: each new QFX slots into the same register without creating the duplicate entries that plagued QIF-based workflows.

GnuCash and other QIF-era tools

GnuCash, long a heavy user of QIF, also imports OFX directly and reads CSV — either of which FlowParse produces and both of which behave more predictably than a hand-built QIF. If your specific tool truly only accepts QIF, export CSV and use its own importer or a small converter to produce the QIF locally.

The principle holds across the legacy landscape: start from clean, reconciled CSV or OFX from FlowParse, and let the destination tool do the last step in the format it prefers.

Import a year at once

Upload up to 100 statements and Smart Merge consolidates them into one reconciled dataset with duplicate detection and a source-file reference before you export — turning a year of catch-up into a single clean import.

For someone rebuilding a register after a gap, that consolidation avoids the tedium of importing twelve files one by one and hoping the overlaps don't double up.

Reconciled data, reliable import

FlowParse reaches around 98% field-level accuracy on standard layouts and validates opening balance plus transactions against the closing balance, flagging discrepancies in the editable preview before you export. The file you import is data you have reviewed.

Combined with the duplicate protection in QFX/OFX, that means your register stays correct rather than accumulating the phantom or doubled entries QIF imports were known for.

Your data stays private

Uploads run over TLS, processing is EU-hosted, the source PDF is deleted immediately after processing, and your documents are never used to train AI models.

Nothing is retained once your file is produced, so your statements don't linger on a server after the conversion is done.

The QIF field codes, and their modern equal

QIF's one-letter codes are the whole format: D for the date, T for the amount, P for the payee, M for a memo, N for a cheque or reference number, and a caret to end each record. It is compact and human-readable, which is why it lasted — but it says nothing about which account the records belong to, and nothing about a unique ID per transaction.

Everything those codes captured, FlowParse captures too — and then some. A QFX or OFX file carries the same date, amount, payee and memo, plus the account identifier and transaction IDs that QIF lacked. So moving to QFX/OFX loses no information; it adds the two fields that make an import reliable.

Why QIF imports duplicate — and QFX doesn't

The classic QIF headache is the duplicate. Re-import a QIF that overlaps a period you already loaded, and every shared transaction is added again, because QIF has no unique identifier for the tool to match on. Fixing it means hunting down and deleting the doubles by hand.

QFX and OFX solve this with a transaction ID (FITID) on every line. On import, Quicken recognises IDs it has already seen and skips them, so overlapping statements merge cleanly instead of doubling. It is a small piece of metadata that turns a fragile import into a dependable one.

Migrating an old QIF-based workflow

If your process has run on QIF for years, the move is easier than it looks. For each statement, export a QFX or OFX from FlowParse and import that instead of building a QIF — modern Quicken and most successors read it natively, with the account matched and duplicates handled.

For a tool that genuinely only speaks QIF, export CSV and let a small local converter produce the QIF, so FlowParse still does the hard part — reading the PDF accurately — while your legacy tool handles the final format. Either way you retire the manual, error-prone step and keep the register you already have.

Reviewing the register after import

A clean import is the goal, but a quick review still pays off. Because FlowParse reconciles the statement before export and QFX/OFX de-duplicate on import, what you are checking is minimal: that the opening and closing balances in Quicken match the statement, which they will when the file reconciled and imported cleanly.

That is a world away from the QIF routine of scanning for doubled entries and misfiled transactions after every import. The reliability is built in upstream — reviewed and reconciled before export, matched and de-duplicated on import — so the register stays trustworthy with a glance rather than an audit.

Beyond Quicken: budgeting and PFM tools

QIF outlived Quicken's own support for it partly because personal-finance and budgeting tools adopted it. Many of those have since moved to OFX or CSV import, which FlowParse produces directly — so whether you use a spreadsheet budget, a PFM app or a classic desktop tool, there is usually a cleaner path than a hand-built QIF.

The advice is the same across all of them: start from FlowParse's reconciled CSV or OFX, and let the destination handle the final step. You keep the accuracy of a reviewed extraction while meeting whatever format your specific tool prefers, without the date and duplicate traps QIF was prone to.

Bank, cash, card and investment types

QIF used its !Type header to distinguish accounts — Bank, Cash, CCard, Invst and others — because each behaves differently. A bank account tracks transactions and a balance; an investment account tracks buys, sells and income. That header was QIF's way of telling the importer how to interpret the records that followed.

OFX carries the same distinction more robustly, with explicit account and security identifiers. FlowParse focuses on bank and credit-card statements, where the mapping to a QFX/OFX bank feed is clean and reliable, and where the overwhelming majority of PDF-to-register conversions actually happen.

The QIF date-format trap

One of QIF's quietest failures is the date. The format never pinned down whether a date was MM/DD/YY or DD/MM/YY, so the same file could import differently depending on the tool's locale — turning the 3rd of April into the 4th of March without any error to warn you.

FlowParse sidesteps that entirely: it normalises dates during extraction and QFX/OFX carry them in an unambiguous form, so a transaction lands on the day it actually occurred regardless of where you or your software are set. It is a small thing that has quietly corrupted many a QIF-based register.

A worked example: PDF to Quicken register

Say you have a year of a credit-card statements as PDFs and want them in Quicken. You upload the twelve files, Smart Merge consolidates them and de-duplicates the overlaps, the balance check confirms each month reconciles, and you export a single QFX.

Open it in Quicken and the transactions flow into the matched account, with the transaction IDs ensuring nothing already recorded is added twice. A year of card activity is in your register in a couple of minutes, correctly dated and free of the duplicates a stack of QIF imports would have produced. That is the whole promise in a single run: accurate data in, a clean and reconciled register out.

The effort this saves versus QIF wrangling

Getting statements into a register the old way meant exporting or hand-building QIF, importing, then cleaning up duplicates and misfiled entries and re-checking dates — a fiddly loop repeated per file. The format that was supposed to save time often created its own.

Converting to QFX/OFX collapses that to upload, review, import. The account matches itself, duplicates are skipped, dates are unambiguous, and the data was reconciled before it left FlowParse. Choosing the modern format isn't a compromise for QIF — it removes the very chores QIF was notorious for.

Who this is for

Quicken users bringing PDF statements into their register, people migrating off old QIF-based setups, and anyone who wants a bank import that actually matches accounts and avoids duplicates.

You get the modern format that works — with CSV on hand for the genuinely legacy cases — rather than a retired format that imports badly. It is the same statement data you were after, delivered in the format most likely to import cleanly on the first try.

Frequently asked questions

Related