The script carried its own copy of the balance rules, and since 1.0.26 that
copy was stale: it reported 631,078.98 MXN where the application reports
-416,403.42. An audit that disagrees with production is worse than no audit,
because its numbers look authoritative and diff cleanly against yesterday's
run. It now mirrors NOT_CASH_JOURNAL and archiveIsHistorySql, keeps the
floor-only figure as a labelled line so older runs still diff, and says
plainly which line is the app's.
Section B stops being an open defect list. EFECTIVO is a receipt book whose
receipts are posted to the datos2 ledger by design, so those rows exist and
always will; what matters is whether any of them still reaches a balance.
That is now a counted assertion which must stay at 0, and it fails loudly if
someone writes a balance query that forgets the exclusion.
Section A grew the line that changes its recommendation. "Floor them, never
carry" was written when the floorless group looked like utilities receipts
whose charges were never migrated. Measured on production today: of the 99,
ninety-five carry insurance-line cash and NONE carry utilities rows. The
seguros EFECTIVO is that line's only ledger, so flooring them deletes
receipts rather than removing a double count.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Matching the datos2 `CN` reference against EFECTIVO folio `N` finds pairs
only where both were keyed correctly. Jorge Cuadros Jr's account carries
`C13647` against EFECTIVO folio `13649` — same day, same 3,500.00 MXN, one
receipt — and POWERS carries `C135808` against `13508`. Folio matching alone
calls both accounts clean, which is exactly backwards: an account used as a
validator reporting a false negative is worse than no audit.
A second pass now sweeps the C-refs the first pass left orphaned, on
proximity alone (same customer, same three-day window), and both passes are
judged by the same money rules. The folio is demoted to a lead: it can be
wrong in either direction, so it never decides anything on its own.
278 confirmed pairs, up from 276 — 989,740.00 MXN and 88,392.00 USD on the
EFECTIVO side. Of the 97 orphaned C-refs only 3 had any EFECTIVO row nearby,
so the remaining 94 are datos2-only postings rather than misses.
Rejections rise to 3. RAMIREZ, SUSANA pairs 3,320.00 MXN against 18,000.00
the next day; that is a partial application, not a duplicate, and it needs a
human rather than a rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Read-only. Reports what a corte would touch without touching it.
The platform inherited legacy's BALANCE FORWARD rows (1,170, all dated
2026-01-01) but not the yearly process that produces them, and
BillingService floors balances per customer on those rows. Two populations
fall outside that floor, and they are unrelated defects that happen to
surface as the same symptom — a customer whose balance reads as a credit
the office does not owe.
A. 102 customers have no BALANCE FORWARD row, so their balance is a raw
lifetime sum. Only the current-year charge ledger (datos2) was migrated;
the per-year charge tables stayed in DreamHost. What survives before the
cutover is the EFECTIVO cash journal, and it shows: 199 of their 201
pre-cutover rows are credits. Flooring them at 2026-01-01 moves the book
by -82,297.78 MXN and -52,020.20 USD. 91 of the 102 are left with no rows
at all, so their balance becomes zero — an assertion, not a figure
recovered from anywhere, which is why this script proposes and does not
apply.
B. 276 cash receipts booked twice in 2026 — once in EFECTIVO under folio N,
once in datos2 as reference CN — across 120 customers, 986,240.00 MXN and
88,252.00 USD on the EFECTIVO side. Both rows sit after the floor so both
count. The statement already hides them via
STATEMENT_EXCLUDED_SOURCE_TABLES; the balances worklist, the movement
browser and the /clientes/:id card do not.
The folio alone does not establish a pair — folios are reused. Every pair is
corroborated on money too: equal amounts when both legs share a currency, or
an implied USD->MXN rate inside the band exchange_rates observed that year.
Two of 278 folio matches fail that test and are reported apart rather than
counted, both same-day partial applications that need a human.
Matches the balance-forward row in both shapes, as numid.service.ts does.
Databases imported before the type was minted carry those rows with typeId
NULL, and name-only matching reports every customer as floorless on such a
copy — including the dev database, which the API itself currently reads as
+20,653,109.15 MXN against a floored -9,194.61.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rmancinasandClaude Opus 5