PRO

Effect Payment Reconciliation

The safety net under exactly-once: normalize records from your ledger and the processor's statement (each source's date and amount quirks absorbed in one transformation layer), match by transaction id, and classify every difference into an explicit bucket: matched, amount mismatch, missing internal, missing external. A transaction stamped 23:59:55 internally that the processor shows at 00:00:30 next day is held as pending_cutoff and carried to the next run instead of paging anyone at 1am; it resolves to a match when the counterpart arrives or escalates to a real discrepancy when it never does. One cent of drift is caught, never absorbed. Pinned to effect 4.0.0-beta.98.

Install
npx shadcn@latest add https://ui.aryank.space/r/effect-payment-reconciliation.json

Installs from ui.aryank.space. To add it by hand, copy the files in Files below, or register the @compronents namespace via the docs.

Visualization
recon
ledger
LedgerRecord
processor
ProcessorRecord
quarter close
unknown
// no reconciliation job exists; the drift compounds quietly

Exactly-once was engineered everywhere, so nobody checks. A processor-side retry posts 25.01 against your 25.00, day after day, and the first anyone hears of it is a quarter close that is off by an amount no query can explain. Nothing errored; the books just diverged.

Files

Dependencies