How the work
actually happened.

The tip-off

Customers fund ad wallets through Stripe. Spend flows out through the Facebook Ads API. Everyone assumed the two ledgers reconciled — nobody had actually checked. Then small gaps started surfacing in finance reviews.

The audit

No sampling. Every wallet, every movement, both directions — a transaction-level join across all three ledgers.

-- full-population reconciliation: no sampling
WITH stripe AS (SELECT wallet_id, txn_id, amount FROM stripe_charges),
     spend  AS (SELECT wallet_id, ad_id, spend  FROM fb_ads_spend),
     ledger AS (SELECT wallet_id, entry_id, delta FROM wallet_ledger)
SELECT w.wallet_id,
       SUM(s.amount)  AS funded,
       SUM(sp.spend)  AS spent,
       SUM(l.delta)   AS ledger_balance,
       funded - spent - ledger_balance AS drift   -- should be 0. always.
FROM wallets w LEFT JOIN stripe s  USING(wallet_id)
               LEFT JOIN spend  sp USING(wallet_id)
               LEFT JOIN ledger l  USING(wallet_id)
GROUP BY 1 HAVING drift != 0;

The find — exhibit A: duplicate entries

Retried webhooks written twice, ~800ms apart. Balances inflated; spending limits computed off the inflated number — the platform was quietly overcharging itself. Two bugs, individually invisible.

The fix

Documented the exact failure paths, handed engineering a reproducible case list, and added standing reconciliation checks — so the next drift shows up on a dashboard, not in a quarter-end surprise.

Two numbers that should agree

Reported revenue drove investor updates and leadership decisions. Cross-checked against money actually collected, the dashboard was running ~15% hot — and had been trusted for months.

The trace

Every metric traced back to source tables — dashboard → revenue view → billing events → payments. The divergence wasn't in the data. It was in a definition.

investor_dashboard.mrr
  └── vw_monthly_revenue          ← definition lives here
        └── billing_events         ← counts *invoiced*, incl. failed & cancelled
              └── payments         ← what actually cleared
DIVERGENCE FOUND: vw_monthly_revenue ≠ SUM(payments.cleared)

The bug — it was the formula, not the data

The kind of bug that survives because everyone assumes someone else validated it.

The rebuild

Rebuilt the revenue logic from scratch, cleaned the underlying event data, reconciled reporting to actuals. Leadership and investor relations got an MRR they could defend in a diligence room.