OFX to QIF conversion turns each tagged transaction in an OFX bank file into a short QIF record of letter-prefixed lines. The date, amount, payee, memo and check number move across. The transaction IDs, account numbers and closing balance stay behind. Dates are rewritten in the order your older program reads, so set that first.
Which OFX fields survive the move to QIF?
The fields that survive are the ones a paper check register would hold: date, amount, payee, memo and check number. QIF has no place for the bank's identity, the account number, the statement period, the closing balance or the unique ID that OFX gives each transaction, so a converter drops them without warning.
Worked example, field by field
Below is one example credit card purchase in an OFX file. The values are made up.
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20260209000000[-5:EST]
<TRNAMT>-23.15
<FITID>CC0209-000118
<NAME>CORNER HARDWARE
<MEMO>Store 112 Springfield
</STMTTRN>
The QIF record a converter writes from it, in a file that starts with a credit card type line:
!Type:CCard
D2/9/2026
T-23.15
PCORNER HARDWARE
MStore 112 Springfield
^
Read the two side by side:
| OFX element | Value in the example | Becomes in QIF |
|---|---|---|
| TRNTYPE | DEBIT | Nothing. Only the minus sign remains. |
| DTPOSTED | 20260209000000[-5:EST] | D2/9/2026 |
| TRNAMT | -23.15 | T-23.15 |
| FITID | CC0209-000118 | Nothing |
| NAME | CORNER HARDWARE | PCORNER HARDWARE |
| MEMO | Store 112 Springfield | MStore 112 Springfield |
Four of the six values made it. For an old ledger program, those four are usually all it would use anyway.
OFX DTPOSTED values rewritten as QIF D lines
OFX dates are always written year, month, day, often with a time and a time zone on the end. A QIF D line is a plain calendar date in the order the reading program expects, usually month first in US software. The converter has to cut the time off, pick the day and write it in that order.
The OFX 2.2 specification sets out the full date form as YYYYMMDDHHMMSS.XXX [gmt offset[:tz name]]. It also says a bare YYYYMMDD means the start of that day in GMT. That detail causes an odd edge case. A converter that turns every date into your local time can move a midnight GMT posting back to the previous evening in the United States, so a February 9 purchase lands on February 8. The fix is to use the date digits as written and ignore the time.
Before you convert, check two things:
- Day order. Find out whether your program reads 2/9/2026 as February 9 or 2 September. Copy the style of a QIF file it has accepted before.
- Year style. Some old readers want a two-digit year. A few use an apostrophe for years after 1999.
After converting, read the first and last D lines and compare them with the first and last DTPOSTED values.
Do OFX amount signs carry into the QIF T line?
Yes, if the converter copies TRNAMT as written. The OFX specification says transaction amounts are signed by their effect on the account, so a debit is negative. QIF uses the same convention on its T line: negative for money out, positive for money in. A sound converter changes nothing.
Credit cards are where trouble starts. On a card, a purchase is money out of your pocket, so it carries a minus sign in OFX, and a payment to the card is positive. If the QIF file is labelled !Type:Bank instead of !Type:CCard, some programs show the card's register with the balance moving the wrong way. Match the type line to the account.
A quick test is to total the T lines in a spreadsheet. The total should equal the sum of TRNAMT values in the OFX. If it equals the same figure with the opposite sign, every amount was flipped and you need a different converter setting.
An OFX download holding several accounts
One OFX file can hold more than one account. The OFX specification includes an example of a banking response with multiple accounts, each in its own statement block. QIF expects one account per list, so split the file: produce one QIF per account, each with its own type line, and import them one at a time.
Signs that your OFX holds more than one account:
- More than one
<BANKACCTFROM>or<CCACCTFROM>block. - More than one
<LEDGERBAL>near the end. - Transaction dates that restart partway down the file.
Some converters handle this and ask which account to export. Others merge everything into a single list, which mixes card charges into checking. If yours merges, open the OFX in a text editor, copy each statement block into its own file with the header lines on top, and convert each one.
Keeping the OFX original once the QIF exists
Keep the OFX file. It is the better record because it carries what the QIF threw away: the bank's transaction IDs, the account identity and the ledger balance. If the old program's register and the bank ever disagree, the OFX can show exactly what the bank sent and whether a line was imported twice.
OFX is also the more useful file for anything you do next. Many current programs read it, and the same data can become a QuickBooks file. Turning an OFX or QFX file into a QBO explains that small header edit. If the transactions started life in a spreadsheet, building an OFX from Excel and making a QFX from an XLS file show the reverse direction.
One caution for business accounts: if the OFX holds deposits from an online store, the bank lines are payouts after fees, not sales. Recording the sales themselves is a separate job, covered in importing Shopify sales into QuickBooks Online.
If what you really have is a pile of PDF statements, SimpleBankConvert is being built to make CSV and QBO files straight from them. Join the list on the get started page.