Green tests proved the converter agreed with itself, not with GnuCash

Look at what the two sides of that equality are made of. In IIF the block is double entry: the account line reads -150.00, the two category lines read 100.00 and 50.00, and the block sums to zero ^[5][6][1]. QIF records the same purchase from the account's point of view only, so the T line is -150.00 and the split lines are -100.00 and -50.00, which add up to the T line instead of cancelling it ^[7][2]. The converter therefore negates every split amount on the way across, which in the source is one character inside a template string ^[8]. The maintainer of qbofile, a browser based converter for the formats small business accounting runs on ^[1], is blunt about what that character is: a claim about how software they did not write reads a format they do not own ^[2][9].

No assertion built from the converter's own output can reach it. `sumOf(splits)` and `transaction.total` are both computed downstream of the convention ^[3], so inverting the convention inverts both, the difference is still zero, and the suite reports success ^[4].

The write-up then does the thing most people skip and mutates the code: minus sign deleted, four tests red, minus sign restored, all green ^[10]. That is worth having, because it rules out a vacuous assertion, which the author notes is a real failure mode ^[11]. It also establishes less than it feels like it establishes. A correct sign, flipped, goes red. An incorrect sign, flipped, also goes red ^[12]. The same observation follows from both hypotheses, so it eliminates neither of them ^[4].

What settled the question was a file built so the answer had to come from outside: one credit card account so the `!Type:CCard` header gets exercised, two separate split transactions, and one category fed by both of them, 100.00 from the first and 120.00 from the second ^[13]. That last choice is the load-bearing one. 220.00 appears in neither transaction on its own ^[3], so it cannot be produced by reading back what the generator just wrote; it only shows up if an importer parsed both blocks and got the sign right in both. GnuCash reported Office Supplies at 220.00, raised no warnings, did not complain that a split failed to balance, and brought the account in as a credit card ^[14]. Fifteen minutes, and the belief became a measurement ^[15].

The defect that mattered was never in the sign. Deciding which lines deserved an external check meant re-reading the whole chain, and the bug was sitting in it ^[16]. QIF has separate P and M fields for payee and memo, and IIF carries both, but the generator emitted only a P line, fed by a `description` field defined upstream as `MEMO || NAME` ^[17]. Every transaction carrying a memo shipped that memo as the payee and dropped the payee ^[18]: `PSUPPLIES RUN` in the output, COSTCO gone ^[19]. Nothing errors, the importing software has no way to know a field went missing, and neither does the person reading the register afterwards ^[20].

That is the failure mode a format converter exists to prevent, and by the author's own account they had built one ^[20]. It survived because the join between parser and generator was checked in the middle instead of at both ends; it was the second time that day the same assumption went unexamined, that a downstream generator can hold everything the upstream parser produces ^[21]. The rule written down afterwards is to open the field lists at both ends and diff them ^[22]. The write-up does not argue for external checks everywhere, and grants that most of the time the unit test genuinely is the last word ^[24]. The triage question is narrower than any coverage target: whether the line rests on a belief about someone else's software ^[23].