Operations demo

CSV Reconciliation Helper

Upload two files, tell it which columns should match, and it does what a wall of VLOOKUPs usually does by hand — matches every row by key, checks the fields you care about, and writes out what's the same, what differs, and what's only on one side. Built by directing an AI assistant in plain English — one of a few small tools at nateeisenstein.com.

Sandbox. Fictional ledger and bank data. Load your own CSVs to try it on real data — nothing ever leaves this browser tab.

Load your two files

Paste CSV or TSV text, or upload a file — either works. Give each side a short name so the results are easy to read.

Not loaded
Not loaded

Match & compare

Pick the column in each file that uniquely identifies a row (an ID or reference number), then list the fields to check once rows are matched.

Reset

How I'd build the full version This demo is the core match-and-compare engine. Here's the rest — messy keys, real data feeds, and turning this into a routine, not a one-off.

Messier keys than a clean ID match

This demo matches on one column being equal. Real reconciliations often need a composite key (date + amount + last four of an account number, say) or a fuzzy match when the same transaction is spelled differently in each system — trickier, but the same idea: find the best candidate on the other side within a tolerance, and flag anything left over as a true exception rather than a formatting difference.

Where the files would come from

Instead of copy-pasting exports, a real version pulls both sides on a schedule — a bank feed via API or SFTP, the internal ledger from the GL system's own export or database — and runs the same match automatically every morning, so exceptions get caught same-day instead of at month-end close.

Tolerance rules that vary by account

A $0.01 rounding difference and a $500 miscoded entry shouldn't be flagged the same way. A real tool would let each compared field carry its own tolerance and severity, and learn which small differences are just timing (a check that clears two days later) versus a real break that needs a person.

Workflow, not just a report

Exceptions need an owner, a note, and a resolved/unresolved state — otherwise the same list gets re-read every day. That's the difference between a report and the reconciliation process I ran at AngelList, which is what this demo is modeled on.

Why this demo is client-side

Single file, nothing to run, no login, and nothing you paste in ever leaves the browser tab. The matching and comparison logic is exactly what a real service would run — only the data source and the workflow around exceptions change.