LedgerlyBookkeeping Helper

Ledgerly turns a small business's bank and card CSVs into categorized books, a closed month, and a real profit and loss report. Small service businesses (a cleaning company, a home care agency, a detailer) often keep books in a spreadsheet or pay for software they barely use. The hard part isn't the math. It's sorting hundreds of rows, catching doubles and personal charges, and proving the month matches the bank statement.

Claude mode is built and its request and parsing are tested, but I never called the live API during the build, so the first real key run still needs a manual check. There's no login and no way for one bookkeeper to serve several clients yet. The categories and reports were checked against seeded demo data, not a real business's year of statements.

This one is a featured build on the revenue track, built by Claude Code on September 23 in one focused run of about half an hour. I set the scope (business books, not a personal budget, and clearly different from the budget dashboard in project 32), the audience, the chart of accounts, and the rule that tests come before UI.

Claude Code wrote the pure core in integer cents, 285 checks, a seeded demo generator, and the seven views. It's plain ES modules, hand-rolled SVG charts, Node for tests and a tiny static server, and an optional Claude mode. Claude only handles the leftovers the rules can't sort, and its suggestions show up as accept or reject chips. You stay in charge.

The demo isn't a fixture. A seeded script writes realistic bank and card CSVs, and the app imports them through the same pipeline a real user would run, so the demo actually proves the importer. At the end Claude drove the app in headless Chrome over the DevTools protocol, from categorizing through locking the month, with zero console errors.

The API connection kept dropping long responses, so every file went in under about 4 KB. That forced seventeen small core modules and one UI module per view, which also made each piece easier to test.

• Dedupe has to be a multiset, not a set. Two real $3.00 coffees on the same day must survive, while the same file imported twice adds nothing. Counting copies per date, amount, and description does both.
• Learned rules should match on a normalized vendor key, not a raw substring. "CHIPOTLE 2291" and "CHIPOTLE 0881" are the same vendor.
• Reconciliation is where bookkeeping earns trust. Showing the difference to the cent and offering to add the missing transaction, prefilled with that amount, turns a scary number into a two-click fix.
• The tests caught Claude's own bugs: a JSON extractor that read a bare array as its first object, a vendor key that lumped every Zelle payee into "ZELLE TO," and an import commit that re-deduped rows it had already accepted.

The shape here is one I used all sprint: one pure core imported by the UI, the tests, and the demo, so the shipped code is the tested code. The "Claude suggests, local code decides, you approve" pattern shows up again in the two Claude Cowork agents in this stretch, built in a separate session: Winnow (70) lets Claude propose signals but keeps the scoring local, and Sieve (69) runs Claude's drafts through the same validator as its own.

I'd store data in Supabase with a login so a bookkeeper can serve several clients, and add OFX import next to CSV.