Exact-code equality is the whole basis of FX reconciliation —
order_transaction_bridge matches on foreign_currency_code = %(ccy)s — so a
row labelled 'BAHT' could never match a THB order and a row labelled
'null' could never match anything. 226 of 1,632 coded rows (14%) were
unmatchable for this reason alone, silently degrading a shipped job.
187 rows carried the literal 4-character STRING 'null' rather than SQL
NULL, 42 of those also carrying foreign_currency_amount = -1.00 exactly.
Root cause is a truthy guard in the CC processors' Parse node —
't.foreign_currency_code || null' passes the string "null" straight
through, because a non-empty string is truthy. Not historical: 155 rows in
2026-03 but also 8 in May, 3 in July and 21 in August. Fixed at source in
the same change (smarthome cc-statement-processor-paperless.json).
Mappings were verified against IMPLIED RATE, not trusted from the label,
because a row whose rate contradicts its currency is a broken ledger row
rather than a mislabelled one — the trap order_transaction_bridge's rate
guard exists for. All six agreed: BAHT 0.0433 vs THB 0.0470, INDIAN RUPEE
0.0183 vs INR 0.0180, U.A.E. DIRHAM 0.4287 vs AED 0.4184, US DOLLAR 1.4054
vs USD 1.5513, NZ DOLLAR 0.8243 vs NZD 0.9311, EURO 1.6342 vs EUR 1.6964.
foreign_currency_amount is untouched by the relabels — only the code was
ever wrong, so this is a relabel, never a recompute.
Applied row counts matched the pre-flight exactly: 42, 187, 13, 10, 6, 4,
4, 2. Postcondition asserted inside the transaction: 0 non-ISO codes
remain. Verified after: 0 'null' strings, 0 -1.00 sentinels, 1445 coded
rows (1632 - 187).
