Payment Recon — invoice_total cents/dollars parse bug (2026-07-28)
payment_reconciliation.update_smartsuite_payment_status() divided any numeric
invoice total by 100, assuming the legacy SmartSuite currency-in-cents format.
Post-cutover, ss.get_record is supabase_read_service, which overlays the
Supabase projects.invoice_total column — already dollars — onto raw_data
under the SmartSuite slug. Result: a 12.00, so
total_paid >= invoice_total was almost always true and a PARTIAL payment
could be wrongly promoted to Paid. Observed live on UPRO-INV-9148
(record 10abd6a1f3c481bc678e7795) when Dustin marked it paid.
Fixed in entirely-api 006e9f7 (pushed, container rebuilt): parse now mirrors
smart_reconciliation._get_invoice_totals — dict = legacy cents (raw_data
fallback), any other non-null value = dollars via float(), including numeric
strings (cert_gen writes the field as str(subtotal); those previously fell
through to 0.0, making Paid unreachable).
Verification: dry comparison across the 30 most recent
payment_tracking.db invoices — old parse understated 100× on all 30; new
parse matched the Supabase invoice_total column 30/30. Post-deploy dry-run
of the real function (writes mocked) returned $1,200.00 / Paid for
UPRO-INV-9148.
Historical audit (read-only, 149 invoices with payments): one plausible casualty — MANA-INV-9011, paid 1,600, marked Paid (single remittance_exact payment 5/19/2026; the 0 net” rows are 5/19 payment+reversal pairs, not this bug.
Related: smart-reconciliation, Supabase, payment-reconciliation