QuickBooks said the IIF import worked. Twice, it hadn't.

We put five IIF files through QuickBooks Mac Plus 2024 to find out what it does when something in the file is wrong. Two of them showed a warning, then said Your data has been imported, and wrote nothing at all. Every account QuickBooks invented along the way came out as a Bank account, including the income one and the receivables one.

The short version

"Your data has been imported" is not a result. It appears at the end of the run whether or not the transactions were written. If a warning dialog came up first, that warning is the real outcome, and clicking OK does not fix anything. The only reliable check is to open the register afterwards and look.

What we tested

QuickBooks Mac Plus 2024, in a company file created for the test and thrown away afterwards, with a backup before every import. One Bank account existed at the start, named TEST BANK A. Everything else in the files pointed at names that were deliberately missing, so we could see what QuickBooks does with each kind of gap. Five files, run in order, checking balances after each one.

This is the Mac result. QuickBooks for Windows 2019 and later behaves differently in at least one respect, covered further down.

The five results

FileWhat QuickBooks showedWhat actually happened
Valid file, account exists Your data has been imported Posted correctly. Balance went 0.00 to -12.40
Unknown name in the NAME field Your data has been imported Posted. Name created under Other Names, not as a customer
Receivable with no customer Warning, then Your data has been imported Nothing posted. Both accounts still 0.00
Amount written -1,234.56 Your data has been imported Posted correctly as -1234.56
Two sides don't balance Warning, then Your data has been imported Nothing posted. Balances unchanged

The two silent failures

Both failing files behaved the same way: a warning dialog, then the ordinary success message, then no change to any balance. The warnings were worth reading, because neither of them says the import failed.

Receivable with no customer:

The Customer field may not be blank. From the drop-down list,
choose a customer, or you can enter a new one.

That reads like a form telling you to fill something in, and there is no form. There is nothing to click except OK, and OK takes you to the success message.

Unbalanced transaction:

Transaction is not in balance. Make sure the amounts in the detail
area on the form for this transaction equal the amount at the top
of the form.

The file had a 10.00 line against a 7.00 line. QuickBooks did not post the 7.00 and put the 3.00 difference somewhere, and it did not post anything at all. The transaction was dropped whole, quietly.

Every account it invented was a Bank account

This is the part with the most reach, because it happens on the imports that succeed. The test file used names that were not in the chart of accounts. QuickBooks created all of them, without asking, and typed all of them the same way:

Name in the fileType it should beType QuickBooks created
Uncategorized ExpenseExpenseBank
Uncategorized IncomeIncomeBank
Accounts ReceivableAccounts ReceivableBank

It does not infer the type from the name, even for names QuickBooks itself uses. It does not infer it from how the account is used in the file. It creates a Bank account and moves on, and the import still reports success.

Why this one matters more than it looks

A wrong account name usually announces itself, because the account shows up in the wrong place in your chart of accounts and you go and fix it. A wrong account type does not. Your expenses sit in something that looks like a bank account, your profit and loss is missing them, and every total involved is wrong until somebody notices.

We had been telling people on our own converter pages that Uncategorized Expense and Uncategorized Income are accounts QuickBooks ships with, so they would always be there. This test is what corrected us: the new company file had neither, and both were created as Bank accounts.

What we did about it

An IIF file can carry an !ACCNT section that names accounts and gives each one a type. Our converters did not write one, on the reasoning that creating accounts in somebody's books is a bigger thing to get wrong than a bad import you can restore from backup. The test above is what changed that. We were never choosing between creating accounts and not creating them, because QuickBooks creates the missing ones regardless. We were only choosing whether they came out with the right type.

Before changing anything we ran a second round, because a section that can create an account might also be able to alter one, and altering a chart of accounts that was already correct would be far worse than the problem we were fixing. Two files answered it:

TestResult
Declare a new account as EXP, then post to it Created as an Expense account, not a Bank account
Declare an existing Bank account as EXP Ignored. The account was still a Bank account afterwards

Those are the two halves we needed: it fills in what is missing and it does not touch what is already there. Every file our converters produce now starts with an !ACCNT section declaring the type of each account it uses, so a missing account is created as the right kind. Accounts you already have are unchanged, type included, even if we declared them differently.

This does not make the name mismatch harmless. If the account name in the file is not exactly the name in your chart of accounts, you still get a second account under the new name and your transactions still go into it rather than the one you meant. It is now at least the right kind of account, which makes it easier to spot and easier to merge.

An unknown name becomes an Other Name, not a customer

When the NAME column held a name that did not exist, the import went through and the name was created. It was not created as a Customer or as a Vendor. It landed under Lists › Other Names as an Other Name record.

Other Names are real records, so nothing looks broken. But they are not customers or vendors, which means the transaction is invisible to anything that reports by customer or by vendor, and you cannot convert an Other Name into a customer later without moving it.

Two things that did not go wrong

Thousands separators were fine. An amount written -1,234.56 was read as -1234.56 and posted at that value. No error, no truncation to -1. This is worth recording because IIF error 3040, which is reported often on Windows, is an amount conversion error, and a comma is the obvious suspect. On this version it was not a problem.

There was no error report to find. QuickBooks for Windows 2019 and later is widely described as producing a line by line import report with numbered error codes. None of our five Mac imports produced one, and no error code appeared anywhere. We looked in the folder holding the files, the Desktop, Documents, the QuickBooks Application Support folder, and ~/Library/Logs/QuickBooks/QuickBooks.log, which contained only internal company file identifiers. On the Mac, the dialog you clicked past is the whole report.

How to check an import actually worked

  1. Write down the account balance before you import. This is the only check that does not depend on QuickBooks telling you the truth.
  2. Read any warning dialog before clicking OK, and copy the text. It is the real result, and it disappears when you dismiss it.
  3. Compare the balance afterwards. If it did not move by the total you expected, the transactions did not go in, whatever the last dialog said.
  4. Open the chart of accounts and look for new entries. Anything the import created will be there. If the file didn't declare account types, every new one is a Bank account, so sort by type and the strays stand out. If it did, as ours do, sorting by type may not show them, so look for names you don't recognise too.
  5. Check Lists › Other Names if your file has a NAME column.

How to avoid all of it

  1. Back up first. IIF writes straight into the company file and there is no undo. Restoring the backup is the clean fix for every problem on this page.
  2. Create every account the file mentions before importing, with the correct type. That includes the category account on the other side of each entry, not only your bank account.
  3. Copy account names out of your chart of accounts and paste them. IIF matches on exact text, including spaces, punctuation and capital letters.
  4. Import one transaction first. Cut the file down to a single row, import it, check the balance, then run the rest. A warning on one row is much easier to read than a warning that could be about any of four hundred.

Questions

QuickBooks said it imported. Is my data in there or not?

Check the balance, not the message. In our test the message was identical for the imports that worked and the imports that wrote nothing. If a warning appeared before it, assume nothing was written until the register proves otherwise.

Does the same thing happen on QuickBooks for Windows?

We have not tested Windows, so we are not going to tell you it behaves the same. One difference is already clear from Intuit's own community forums: Windows 2019 and later reports numbered errors such as [3040] and produces an import report, and the Mac version we tested produced neither. If you are on Windows and you get that report, it tells you more than the Mac gives you.

Can I just change the type of an account that was created wrong?

We did not test whether changing a Bank account to Expense after transactions have posted to it produces correct results, so we are not going to claim it does. Restoring the backup you took before importing is the option we can vouch for.

Why doesn't QuickBooks just stop and ask?

IIF is a bulk loader. It was built to push large lists in one pass from something that already knows your chart of accounts, which is true when QuickBooks exported the file and not true when it came from anywhere else. Stopping on each unknown name would defeat the point, so it guesses instead, and a Bank account is what it guesses.

Do your converters put anything in the NAME column?

No. We leave it empty, so nothing gets created under Other Names by our files. The account names our files use are Uncategorized Expense and Uncategorized Income on the category side, plus whichever account name you type in yourself, and all three are declared with their correct type in the !ACCNT section at the top of the file.

You still want the account you type in to match your chart of accounts exactly, because that is what decides whether the transactions land in your real account or in a new one beside it.

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', so your browser refuses to let the page make any network request. Watch the Network tab in developer tools while you convert; it stays empty.

Related