The importer said it worked, wrote nothing, and left two accounts behind

The dialog is the entire result channel, and it does not vary with the outcome. Nine deliberately broken files produced it nine times ^[1], and two of those runs posted no transactions at all ^[2], so the message cannot separate a write from a no-op ^[16]. There is nothing narrower underneath it: no per-record status, no count of rows accepted. That is the author's generalisation, and it holds beyond this product. When a format carries no per-record result channel, the one remaining place to report fires whether or not anything worked, and a partial write underneath it is invisible ^[13].

The single run that did report a problem is worth reading closely. The unbalanced file raised a warning telling the user to check that the amounts in the detail area on the form match the amount at the top, and there is no form on screen: one OK button, and it advances to the success message ^[6]. Failure notice and success notice sit on the same click, and the click destroys the only copy of the first one ^[6]. QuickBooks for Windows 2019 and later is widely described as writing a line by line import report with numbered error codes that people quote on Intuit's forums ^[7]. None of these imports on QuickBooks Mac Plus 2024 produced one, and the application's own log held internal identifiers and nothing else ^[8].

The company file started with exactly one account, and every other account the files named was missing on purpose. QuickBooks created all of them without asking and typed every one as a bank account ^[9]. Not from the name, not even for names QuickBooks itself uses, and not from how the file used the account ^[10]. The receivable file is where that gets expensive: it wrote no transactions and left two new accounts behind ^[12]. The source's own arithmetic does not fully close, since the opening says one failing run left three records while the later attribution puts two of the three with the receivable file ^[3][12], so the figure to hold is the load-bearing one, two accounts created by a run that posted nothing ^[17].

A wrong account name gets fixed, because the account turns up somewhere visible and somebody goes and corrects it. A wrong type stays put. 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 ^[11].

The converter had left IIF's !ACCNT type section out on purpose, reasoning that creating accounts in somebody's books is worse than a bad import you can restore from backup ^[15]. The test removes the premise, because the accounts get created either way and the only open variable is who picks the type. The same measurement caught a reassurance on the converter's own pages, that Uncategorized Expense and Uncategorized Income ship with QuickBooks, in a blank company file that had neither ^[14]. A user told only that an import failed will assume nothing happened ^[18], and here that assumption is wrong by two accounts ^[17].