The problem
EHAS Design is my husband Eric’s construction company, and every tax season meant pulling transactions out of eleven accounts: business checking and savings, two credit cards, a Home Depot card, Venmo, and store credit accounts at the hardware store and the lumber yard. Clients pay by Venmo, Eric moves the money to checking, and the bank sees two deposits for one payment. Off-the-shelf bookkeeping tools were either too expensive or wanted him to adopt invoicing, payroll and a CRM to get the one thing he needed.
What I built
A three-stage Python pipeline. The first stage unifies CSV, HTML and PDF statements (the lumber yard’s come through pdftotext and regex) into one format and pairs inter-account transfers, so money moving from Venmo to checking counts once. The second is a rules engine: description regex, then Venmo counterparty and note rules, then account defaults. The third produces the summary in the format his accountant asks for.
On top of that, a React dashboard with seven views (summary, categories, excluded, transfer pairs, job audit, monthly, about). The first version was read-only. The second let Eric edit categories, leave notes and flag rows, synced to Netlify Blobs through a Netlify Function, and that is where it got interesting: 846 of the 1,310 transactions had no ID in their source data, so one edit rewrote hundreds of rows. Of the 863 entries in his change log, 17 were real. Those 17 went back into the pipeline as rules.
The public version
The live demo runs the same architecture on about 1,165 synthetic transactions, with per-visitor edit storage, a guided tour, and analytics. None of the client’s real records are in it.
Numbers
- 1,310 transactions across 11 accounts, 100% categorized
- Pipeline runs in under 10 seconds
- 17 real edits recovered out of 863 logged, all encoded as pipeline rules
Both write-ups are in Writing: part 1 on the pipeline, part 2 on what broke when a real user touched it.