Thirty-Day Reconciliation

Both arms are computed on the same deduplicated data, so this isolates what the calculation fixes are worth. Figures exclude the ten deactivated duplicate clients, which the plan says to exclude from reporting; including them the shape is identical (432 → 70 days, $25,622.98 → $1,548.64).

This is the question that matters most for the books, and it has two halves. No day that balanced under production went out of balance — that count is zero. But 237 client-days that were balanced had their line amounts change anyway, and a balance-only view would hide every one of them.

None of those 237 came from the calculation fixes. Both fixes are provably inert on balanced days — see the decomposition below. They came from the data being corrected underneath.

The second pattern is worth reading carefully: Card Payments falls by exactly what Fees gains, so the day stays balanced while the split between the two lines changes. That is a data-freshness effect from re-importing, not a change in how anything is calculated. Three real rows:

NGAN moves $29.59 out of Card Payments and into Fees; NGVC moves $49.60 the other way. Both stay balanced to the cent. NGGP is the first pattern — production held an all-zero summary for a day with $2,478.44 of card payments, $1,148.11 of gyros and pitas, and so on.

Applied in sequence, each measured against the state before it. Percentages of a 3,040 client-day population.

The data work is the only step that unbalances anything: 19 days go out of balance purely from correcting the data, mostly where a refund that had been sitting under the twin client now lands on the right one. The two calculation fixes then absorb all 19, which is why the end-to-end figure is zero.

Each fix is easiest to check on a single order. In every case below the day's imbalance equals the fix amount exactly, which is what you would expect if the fix is booking something real that was previously booked nowhere.

A guest's tip was handed back. The reversal is recorded on the order, but get-tip reaches tips by joining through :sales-order/charges, and a return-only order has no charge to join through — so the −$60.00 was invisible and the day credited a tip that no longer existed. The other four largest R1 repairs are the same shape: NGFF 08-01 (−$40.00), NGSG 07-29 (−$40.00), NGNV 08-09 (−$35.00), NGJS 07-25 (−$35.00).

The $427.10 is inside the card tender the customer paid, so it lands on the debit side — but nothing credited it, leaving the day short by exactly that amount. Next largest: NGFO 07-16 ($275.23), NGRN 08-06 ($236.96), N-30008 07-24 ($229.42), N-30003 07-18 ($225.00).

These are days production held an empty summary for — trivially balanced at zero. Filling them in with real figures exposes the same two calculation gaps every other day had, and both fixes then close them. Not one of the 19 survives as a regression. Their clustering on 08-13 is expected: it is the most recent day, so it is the one production had least chance to compute.

Of 6,300 client-day slots in the window, production held a summary for only 2,242. The remaining 4,058 had none at all — nothing to compare against, and nothing an accountant could have looked at.

They are not evenly spread. Eight consecutive days show 210 missing summaries each, which is every client in the database:

Five client-days above the ten-cent materiality threshold, totalling $404.04. Everything else — 62 days — comes to $1.62, with the largest single day at nine cents.

The ten-cent threshold separates register rounding from real variance with nothing sitting near the boundary — the largest sub-threshold day is 9.00¢ and the smallest material one is $9.62, two orders of magnitude apart.

NGBK 2026-08-06, traced. Summing that client-day's orders directly: tender totals $6,358.99 while the orders' own totals come to $6,059.57 — a difference of $299.42, exactly the imbalance. Square recorded more payment than the orders account for. Three explanations were checked and ruled out: the day has no refund lines at all, no order carries two charges for one payment id, and the nine orders lacking line items carry zero tender. This is a source-data discrepancy, not a calculation defect, and not something either fix should paper over.

• Run against a production backup restored to basis-t 209608347, newest transaction 2026-08-14 22:52. Nothing in production was touched.
• "Before" is production's own stored summaries, read via as-of — not a re-simulation of them. Datomic keeps every past value, so the comparison is against exactly what was there.
• A day counts as out of balance when debits minus credits is at least half a cent. Line amounts are compared at the cent, so floating-point noise does not read as a change.
• R1 and R2 only ever add credits, so baseline is derived as fixed + untendered tip + service charges. That identity was checked against a from-scratch baseline recomputation on 20 random client-days and agreed on every one.
• All 14,458 summaries in the database were recomputed through the real job, not a test harness.

Every figure here comes from the restored database and can be re-derived from it. The comparison tool is committed as auto-ap.jobs.compare-sales-summaries.

The unit tests covering both fixes and the re-key run with:

Note that the restore currently has Phase 0 applied and the twins deactivated. Re-running the comparison after re-activating them will move the contended clients' figures; everything outside those ten client pairs is unaffected.