Why did an IIF import create a new account in QuickBooks?

Because the account name in the IIF file did not exactly match a name in your chart of accounts. IIF matches accounts by name, including spacing, punctuation and capitalisation. When the name is not found, QuickBooks does not prompt and does not report an error: it creates an account with that name and posts everything to it.

What account type does QuickBooks give the account it creates from an IIF import?

When the file does not declare account types, it was a Bank account in every test we ran, regardless of what the statement was. For a credit card that is the wrong type: the account becomes an asset instead of a liability. A file that declares the type in an !ACCNT section gets that type instead: a missing credit card account declared as CCARD was created as a Credit Card account.

Why do my credit card charges show as CHK instead of CC after an IIF import?

Because the transactions landed in a Bank account rather than a Credit Card account. When the target account is a real Credit Card account, a CREDIT CARD CHARGE line shows in the register as CC and a CREDIT CARD CREDIT line shows as CC CRED. When the account was auto-created as a Bank account, the same file produces CHK and DEP instead.

How do I stop an IIF import from creating a new account?

Copy the account name out of your chart of accounts and paste it into the file rather than typing it from memory: IIF matches on the exact name, and a name that is not found always becomes a new account. To make sure any account QuickBooks does create comes out as the right type, the file needs an !ACCNT section declaring it; ours include one. Without that section the importer creates a Bank account whatever the transactions say.

IIF Import Created a New Account in QuickBooks — And Made It the Wrong Type

The short version

If the account name in an IIF file doesn't exist in your chart of accounts, QuickBooks doesn't ask and doesn't report an error. It creates an account with that name and posts everything there. In our test it created that account as a Bank account every time — whatever the statement really was.

On a chequing statement that's a nuisance. On a credit card it's wrong in two ways at once: a liability becomes an asset, and every transaction type is downgraded — charges that should record as CC come out as CHK.

What we tested

QuickBooks Desktop for Mac, in a scratch company file created for the purpose, with a backup taken first. Two imports through File › Utilities › Import › IIF Files: one naming an account that didn't exist, one naming a real Credit Card account.

Import 1 — the account name doesn't exist

The file named an account that was not in the chart of accounts. What happened:

No prompt. Nothing asked whether the account should be created.
No error, no warning. The import reported success.
The account was created with exactly the name from the file.
It was created as a Bank account — the statement was a credit card.
Every transaction landed there as CHK or DEP, not as CC or CC CRED.

The file said CREDIT CARD CHARGE. QuickBooks accepted it, created the account, and then recorded the transactions as cheques — because a Bank account can't hold a credit card charge, and nothing in the import is allowed to fail. This is the file it was given, straight out of our converter:

!TRNS	TRNSID	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT	DOCNUM	MEMO
!SPL	SPLID	TRNSTYPE	DATE	ACCNT	NAME	AMOUNT	DOCNUM	MEMO
!ENDTRNS
TRNS		CREDIT CARD CHARGE	01/05/2024	Visa Card		-12.40		COFFEE SHOP 4471
SPL		CREDIT CARD CHARGE	01/05/2024	Uncategorized Expense		12.40		COFFEE SHOP 4471
ENDTRNS

Import 2 — the account exists, with the right type

Same file, same transaction types, but pointed at a Credit Card account that already existed. Everything landed correctly:

In the IIF file	Target is a real Credit Card account	Target was auto-created (Bank)
`CREDIT CARD CHARGE`	`CC`	`CHK`
`CREDIT CARD CREDIT`	`CC CRED`	`DEP`

Signs behaved correctly too: a charge increased the balance owed, a payment reduced it. So the transaction types in the file are right — the account they're pointed at is what decides whether they survive.

What this means for you

The advice usually given is "make sure the account name matches exactly." That's true but incomplete, because it implies the only risk is a duplicate account you can tidy up later. The real requirement is stronger:

A transaction row can't carry the account type. A different section can.

An IIF transaction row names an account but has no field for the account's type, and the importer doesn't infer one — it creates a Bank account and then reshapes the transaction to fit, rather than the other way round.

An !ACCNT section earlier in the same file can carry the type, and we now write one. When we first published this page we said nothing in the file could change the outcome, and that we deliberately didn't write that section. Both of those are out of date. We tested !ACCNT on 22 August 2026 and it does two things we needed at once: missing accounts get created with the type we declare, and accounts you already have are left alone, type included. So a file from our converters no longer produces a wrongly typed account, and it still can't damage a chart of accounts that was already correct. On 14 September 2026 we tested the case this page started with, a missing credit card account. Declared as CCARD, it was created as a Credit Card account, with the charge recorded as CC and the payment as CC CRED.

The name still has to match. If it doesn't, you get a second account under the new name. It will at least be the right kind of account now, but your transactions are still not in the account you meant.

If it already happened

If you took a backup before importing, restore it. That is the clean fix and it's the reason we tell people to back up on the converter page — an IIF import writes straight into the company file and there is no undo.

If you didn't back up, the transactions have to come out before the account will go anywhere: QuickBooks won't delete an account that still has transactions in it. Work through the register for the invented account, then deal with the account itself, then create the real one with the correct type and re-import.

We haven't tested whether changing the invented account's type from Bank to Credit Card after the fact produces correct results, so we're not going to tell you it does. Restoring a backup is the option we can vouch for.

How to avoid it next time

Create the account in QuickBooks first, with the right type — Bank for chequing and savings, Credit Card for a card.
Copy the name out of your chart of accounts and paste it. Don't type it from memory. IIF matches on spacing, punctuation and capitalisation, so "Business Checking" and "Business Checking" are two different accounts.
Back up the company file before the import, every time.
Import one statement, then look at the register before importing the rest. The transaction type column is the fastest tell: if you're expecting CC and seeing CHK, stop.

Our CSV to IIF converter asks for the account name in a field of its own rather than burying it in the file, for exactly this reason — it's the single most damaging thing to get wrong, and it's invisible until reconciliation.

Why the format behaves this way

It's worth understanding rather than just working around, because it explains a whole class of IIF surprises: IIF has no error channel. The format was designed for bulk loading lists into QuickBooks, the import runs unattended, and it is built to complete rather than to validate. There is no mechanism for the importer to stop and ask "I don't recognise this name — what did you mean?"

Given a name it doesn't know, it has two options: refuse the file, or guess. It guesses, and it guesses Bank. What makes that worth noting is that the guess ignores evidence the file does supply. Look at the row above: TRNSTYPE and ACCNT are on the same line, so the line that names the unknown account also says CREDIT CARD CHARGE. The importer creates a Bank account anyway, and then rewrites the transaction into something a Bank account can hold.

That is why an IIF import can report complete success and still be wrong. A QBO import behaves differently: it lands in the bank feed's review queue, where you match each transaction before anything is recorded. If the choice is available to you, a .qbo file fails more safely than an IIF file does.

Frequently asked questions

Does this happen on QuickBooks Desktop for Windows too?

We tested on Desktop for Mac. The IIF import path is the same feature on both, and we have no reason to expect a difference — but we haven't run it on Windows, so we're recording what we measured rather than what we assume. If you've seen it behave differently on Windows, we'd genuinely like to know.

Why doesn't QuickBooks just ask me?

Because the import isn't interactive. IIF exists to load large lists in one pass, and stopping to ask about each unknown name would defeat that. The design assumes the file was produced by something that already knows your chart of accounts — which is true when QuickBooks itself exported it, and not true when the file came from anywhere else.

Can I put the account type in the IIF file so this stops happening?

Yes, in an !ACCNT section, and our converters now write one. This answer used to say we deliberately didn't, on the grounds that creating accounts in someone's books is a bigger thing to get wrong than a bad import you can restore from backup.

What changed our mind was measuring what actually happens without it. We were not choosing between creating accounts and not creating them: QuickBooks creates the missing ones either way. We were choosing between it creating them with the right type and creating them all as Bank accounts. Put like that there was nothing to weigh up.

The other half of the decision was making sure the section can't do damage. We tested a file that declared an existing Bank account as an Expense account, which is the worst thing our converter could get wrong. QuickBooks ignored it and left the account as a Bank account. An !ACCNT section fills gaps; it does not overwrite what is already there.

Is CREDIT CARD CHARGE actually the right transaction type?

Yes — this was the other thing the test settled. Published sources disagree, with some listing CREDIT CARD and CCARD REFUND instead. Against a real Credit Card account, CREDIT CARD CHARGE and CREDIT CARD CREDIT show in the register as CC and CC CRED, which is correct. Those are the values we write.

Is my bank data uploaded anywhere if I use your converter?

No. Every converter here runs in the browser, and each page ships a Content Security Policy with connect-src 'none' — your browser refuses to let the page make any network request. Watch the Network tab in developer tools while you convert; it stays empty.

"Your data has been imported" can be wrong two of five test files wrote nothing
CSV to IIF converter for QuickBooks Desktop
OFX to IIF converter reads the account type from the file
QBO to IIF converter when Web Connect won't take the .qbo
Which file does your QuickBooks take? Desktop vs Online, all formats
CSV to QBO converter goes through the review queue instead

An IIF import created a new account — and made it the wrong type