What you are seeing
!Type:Bank
QIF is the least specified format still in daily use. It has no version, no schema and no bank identifier, and its account type is declared in one short line that decides what kind of account the transactions belong to. When a QIF import puts transactions somewhere unexpected, or a credit card behaves like a bank account, that line and the sign of the amounts are where to look.
The type header
A QIF file opens by declaring what it contains. Everything after that line, until the next header, is read as transactions of that type:
!Type:Bank
D03/15/2026
T-42.50
PCITY WATER
^| Header | Account kind | Use for |
|---|---|---|
| !Type:Bank | Asset | Checking, current and savings accounts |
| !Type:CCard | Liability | Credit cards |
| !Type:Cash | Asset | Petty cash and cash wallets |
| !Type:Oth A | Asset | Other assets, such as a loan you made |
| !Type:Oth L | Liability | Other liabilities, such as a loan you owe |
| !Type:Invst | Investment | Brokerage accounts; a different record layout entirely |
Spell the header exactly as above, including the space in Oth A and Oth L. A misspelled header is not rejected everywhere, and an importer that does not recognise it has to guess, which is a quieter route to the wrong account.
The fix is upstream: set the account type before the file is written so the header matches the account you are importing into, rather than editing it afterwards.
Why the wrong type matters even when the numbers look right
A bank account is an asset and a credit card is a liability. Import a card statement as !Type:Bank and the card becomes an account of things you own rather than money you owe. The register may look plausible, but net worth, balance sheet reports and anything that totals assets and liabilities are wrong from that moment.
Nothing fails. The import completes, the transactions are all there, and the mistake surfaces weeks later in a report that does not make sense. That is what makes it expensive to find.
Why the signs come out reversed
The T line carries the amount, written from the account holder’s side: money out of the account is negative, money in is positive. On a card that means a purchase is negative and a payment to the card positive, which is how Quicken writes card QIF files.
Card statements print it the other way round: purchases as plain positive numbers, payments with a CR or a minus. A QIF built from the statement as printed reads every purchase as a credit and every payment as a charge. The totals stay plausible, and the account simply behaves as though the month went unusually well. MYOB’s help puts it plainly for its own imports: withdrawals should be negative.
Two mistakes that travel together
A card statement imported as Bank with printed signs is wrong twice, in ways that partly cancel in the register and fully show in reports. Check both the header and the sign of the first purchase before importing any card QIF.
Why a new account appears
Importers that read the account details from the file match an existing account by name and type together. Where the type disagrees, some create a new account rather than report a conflict, so the transactions are not missing, they are in an account you did not expect and may not have noticed.
If transactions have “disappeared” after a QIF import, look at the account list before looking at the file. Sort it by date created if the software allows; the stray account is usually the newest one.
Quicken, Xero and MYOB treat QIF differently
- Quicken Classic for Windows: File → File Import → QIF File, then choose the destination in “Quicken account to import into”. Quicken’s current help says the destination account must already exist and that any account type can now take a QIF import; older releases only allowed cash, asset and liability accounts. If your account is missing from the list, it does not exist yet in the data file or is not valid for QIF import.
- Xero: QIF is one of its manual import formats. You choose the bank account before importing, so the type header does not route the file, but the signs still have to be right.
- MYOB: imports QIF and OFX. Its help asks for dd/mm/yy dates where the bank offers a choice, and withdrawals negative.
The !Account block, and why it helps
A QIF file may open with an account block naming the account the transactions belong to, before the type header:
!Account
NBusiness Current
TBank
^
!Type:BankWith it, the importer knows which account is meant rather than inferring one from the type. Without it, a file of type Bank imported into a program with three bank accounts goes wherever the importer decides, which is the other route to transactions appearing somewhere unexpected. The name on the N line must match the existing account exactly, and the T line must match its type.
The other QIF trap: dates
QIF writes the date on a D line and says nothing about its order. The same file means different things depending on whether the importer reads it day-first or month-first, and Quicken’s own files have traditionally used short forms such as 3/15’26, with an apostrophe marking years from 2000.
There is no in-band fix
Nothing can be added to a QIF file to state the date order. The only defence is knowing which order was written and confirming the importer agrees, which is why a converter should tell you which order it used rather than leaving you to infer it.
Categories, and the bracket convention
The L line carries the category for a transaction. A plain name is a category; a name in square brackets is another account, which makes the entry a transfer rather than income or spending.
LOffice Expenses <- a category
L[Savings Account] <- a transferA converter that writes bracketed values by accident creates transfers to accounts that do not exist, and some importers respond by creating them. If unfamiliar accounts appeared after an import, this is worth checking alongside the type header.
Fixing a file you already have
- 1Back up the data file.
- 2Delete the account created by the bad import, or the transactions it put in the wrong account. QIF has no transaction IDs, so a second import will not recognise the first and you will have both.
- 3Open the .qif in a plain text editor. It is plain text.
- 4Correct the !Type: line, and the T line of any !Account block, to match the destination account.
- 5For a card, check the sign of a purchase. If purchases are positive, the amounts need reversing before import.
- 6Import into the existing account, then compare the first few transactions and the closing balance with the statement.