Data + AI · reconciliation

Tally

Payments reconciliation across ledger, processor and bank, graded against a hidden answer key.

Release candidate Code

0.999
Error precision
0.994
Error recall
~7s
1M ledger rows
68/68
Unsafe requests refused

Case studyData + AI

PythonDuckDBdbtFastAPINext.jsAirflowsqlglot

Problem: Every payment is recorded three times: in the internal ledger, at the payment processor and at the bank, and the three never agree. Payments are booked twice, arrive late, settle in batches, get split, carry fees and lose their references. Most reconciliation demos show a dashboard and ask you to trust it.
Who it's for: Finance and operations teams who have to explain every gap between what was booked and what landed in the bank.
Design decisions: Six screens (overview, exceptions, payouts, scorecard, runs, ask) built around one question: what needs a decision, and how much money is at stake. Real errors and benign look-alikes are separated everywhere, so people only review what matters. Accessibility is checked against WCAG 2.1 AA in CI.
Technical decisions: Python with DuckDB as the warehouse and dbt for staging and marts. A synthetic world generator plants 13 defect classes and records the answer key. Ingestion has schema contracts, a quality gate and idempotent loads. FastAPI serves a Next.js dashboard; runs are resumable, with backfills, alerts, freshness checks, lineage and an Airflow DAG.
The hard problem: The first engine scored 1.000 on the easy world and only 0.561 precision on the hard one: a mistyped reference usually names another real order, so it linked payments to the wrong order and invented duplicates. The rewrite only believes a reference match when merchant, currency and time agree, accepts strong evidence first, then falls back to attribute matching and a tightly bounded fuzzy tier.
Result: 0.999 error precision and 0.994 recall on the hard world, no false alarms on benign look-alikes, every ledger link correct, stable across 8 seeds, and about 7 seconds for one million ledger rows. The question assistant answered 45 of 45 evaluation questions and refused 68 of 68 unsafe requests.

Screens

Walkthrough: overview, exceptions, payouts and the scorecard.

How it's built

Warehouse
DuckDB + dbt staging and marts
Engine
5 matching tiers, 14 finding classes
Safety
3-layer validation for generated SQL

Next project

Citable