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
| File | What QuickBooks showed | What 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 file | Type it should be | Type QuickBooks created |
|---|---|---|
Uncategorized Expense | Expense | Bank |
Uncategorized Income | Income | Bank |
Accounts Receivable | Accounts Receivable | Bank |
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:
| Test | Result |
|---|---|
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
- Write down the account balance before you import. This is the only check that does not depend on QuickBooks telling you the truth.
- Read any warning dialog before clicking OK, and copy the text. It is the real result, and it disappears when you dismiss it.
- 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.
- 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.
- Check Lists › Other Names if your file has a NAME column.
How to avoid all of it
- 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.
- 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.
- Copy account names out of your chart of accounts and paste them. IIF matches on exact text, including spaces, punctuation and capital letters.
- 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
- An IIF import created a new account and made it the wrong type
- 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