Every importer has one moment where it tells you it is done.
Here is that moment, at the end of a file import into a twenty year old accounting product:
QuickBooks Information
Your data has been imported.
I have nine test files that produce that message. Two of them wrote no transactions at all, and one of those two still left three new records behind in the database on its way out.
That last part is the one that travels. If a format has no per record result channel, there is exactly one place left to tell the user what happened, and it fires whether or not anything worked. A partial write underneath it is invisible.
Nine files, each broken in one specific way
I maintain a browser based converter that turns bank CSV files into the formats accounting software will take. One of them is IIF, a tab separated format QuickBooks Desktop has used since the 1990s, with a reputation for failing quietly.
I had a specific worry. Our files reference accounts by name. If the name is not in the user's chart of accounts, what happens? Everyone writing about IIF says QuickBooks creates the account for you. Almost nobody says what kind of account it creates.
So I built five files, each broken in one way, and ran them against QuickBooks Mac Plus 2024 in a throwaway company file. Four more came later, for a reason I will get to.
Two of the five said imported and posted nothing
| The file | What QuickBooks showed | What actually happened |
|---|---|---|
| Valid, account exists | Your data has been imported | Posted correctly |
| Unknown name in the NAME field | Your data has been imported | Posted. Name created as an "Other Name" |
| Receivable with no customer | Warning, then Your data has been imported | Nothing posted |
Amount written -1,234.56
|
Your data has been imported | Posted correctly as -1234.56 |
| Two sides that do not balance | Warning, then Your data has been imported | Nothing posted |
Here is the warning from the unbalanced file, the one thing that distinguished a failed run from a good one:
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.
That reads like instructions for a form you are looking at. There is no form. There is one button, it says OK, and it takes you to the success message.
So the warning was the result, and clicking OK destroyed the only copy of it.
I went looking for the copy that should have survived. QuickBooks for Windows 2019 and later is widely described as writing a line by line import report with numbered error codes, and people quote things like [3040] on Intuit's forums. None of my imports produced one, and the app's own log held internal identifiers and nothing else. On this build the dialog you clicked past is the entire record.
Every account it invented was a bank account
The company file started with exactly one account in it. Everything else the five files referenced was missing on purpose. QuickBooks created all of them without asking, and gave all of them the same type:
| Name in the file | Type it should be | Type QuickBooks made | Created during |
|---|---|---|---|
Uncategorized Expense |
Expense | Bank | a run that posted |
Accounts Receivable |
Accounts Receivable | Bank | a run that posted nothing |
Uncategorized Income |
Income | Bank | a run that posted nothing |
It does not infer the type from the name, not 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.
A wrong account name announces itself, because the account appears in the wrong place and somebody goes and fixes it. A wrong account type does not. Expenses sit in something that looks like a bank account, the profit and loss report is missing them, and every total involved is wrong until someone notices.
The failure was only half a failure
Look at the right hand column again. Two of those three accounts were created by the receivable file, and the receivable file is one of the two that wrote no transactions.
So that run rejected the transaction and kept the side effects. Nothing was posted, two new accounts were left behind in the chart of accounts, both of them the wrong type, and the last thing on screen said the data had been imported.
That is the case worth designing for if you consume other people's files. "It failed" is not the same statement as "nothing happened", and a user who is only told the first one will assume the second.
We had been telling people the opposite
This is the part I would rather not write. Our own converter pages said that Uncategorized Expense and Uncategorized Income are accounts QuickBooks ships with, so they would always be there and the category side of every entry was safe.
I did not measure that before publishing it. I read it, it matched what everyone else says, and it went on the page as a reassurance. The blank company file had neither account. The line had been sitting there telling people not to worry about the exact thing that was going wrong.
Both pages now say what the test found instead.
The fix, and the test that had to come first
IIF has a section that carries account types:
!ACCNT NAME ACCNTTYPE
ACCNT Amex Platinum CCARD
ACCNT Uncategorized Expense EXP
ACCNT Uncategorized Income INC
We had deliberately not written that section, 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.
That reasoning was wrong, and measuring is what showed it. We were never choosing between creating accounts and not creating them. QuickBooks creates the missing ones either way. We were only choosing whether they came out with the right type.
That still left the question of whether the section is safe, which needed a second round of files. The one that mattered declares an account that already exists as the wrong type. If !ACCNT can retype an account somebody is already using, this fix is worse than the bug: instead of a stray account in a new file, you have a corrupted chart of accounts in a real one.
It cannot. The account was still a bank account afterwards. The section fills gaps and leaves everything else alone. That is the result that made the change shippable, and out of nine files it is the only one whose answer could have stopped it.
The two rules I came out with
Put the outcome where dismissing it does not destroy it. A modal warning is gone the moment someone clicks OK, and on the build I tested nothing else recorded it. The user is then holding a screen that says the import succeeded and no way to find out otherwise except by counting rows.
Before changing how a tool writes to somebody else's data, write the test whose result would stop you, and run that one first. Eight of my nine files told me things worth knowing. Only one of them could have cancelled the change, and if I had run it last I would have built the whole thing before finding out.
The converter is at qbofile.com. It runs in the browser, nothing is uploaded, and every file it writes now declares its account types.
Top comments (1)
?