I build automations for a living, and the one I see people abandon most is money tracking. Not because the tools are bad. Because everyone builds the fun part (categorization, charts) and skips the grind: pending charges that post twice, refunds that land in the wrong month, a subscription that changed its billing descriptor and now looks like a merchant you've never heard of. That grind is the whole job. This role is the grind.
What it does. You paste in or upload a raw statement export (CSV, copied rows, whatever shape it arrives in). It produces two artifacts:
- The Ledger: every transaction on one line, date normalized, amount signed correctly (refunds negative, charges positive), merchant cleaned to a canonical name, category assigned. If a rule was applied ("VEND*0421 → vending machine, snacks"), the rule is shown, never silently assumed.
- The Exceptions List: the transactions it could not confidently resolve, each with a concrete question. "This $84.90 pending charge from the 3rd posted at $89.12 on the 6th. Keep the posted amount?" "Two $12.99 charges same merchant same day. Duplicate or two purchases?" An exception with no question is a bug.
The conviction I hold, and you should too: a ledger with silently-wrong rows is worse than no ledger. People eyeball a categorized list, trust it, and never notice the pending-then-posted double count or the refund netted against the wrong month. So this role refuses to guess. Anything below confidence, it flags. An empty exceptions list at the end of a 200-row statement is suspicious, not satisfying. Real statements have 5 to 15 genuine oddities. If it reports zero, ask it to re-check for same-amount pairs thirty days apart and descriptor changes mid-month.
Rules it carries that a generalist won't infer:
- Pending and posted versions of the same charge are one transaction. Match on approximate amount plus merchant within 10 days, keep the posted one, drop the pending.
- A refund is its own line, never netted against the original charge. Netting hides chargebacks and partial refunds.
- Merchant descriptors lie. "SQ *BLUE DOOR" and "BLUE DOOR CAFE" are the same place; build the canonical-name mapping as it goes and reuse it next month, so each statement is easier than the last.
- Never infer a category from the merchant name alone when the amount is unusual for that merchant. A $400 charge at a place that normally sees $15 goes on the exceptions list.
Memory: it keeps your canonical merchant map, your category list, and last month's unresolved exceptions between runs. Recurring exceptions (a charge you never resolved twice in a row) get escalated, not repeated.
Cadence: run it the day each statement drops, or paste a mid-month batch whenever you want a checkpoint. Once a month is enough; daily is a chore nobody keeps.
What it refuses: guessing a category to fill the list, merging refunds into charges, and producing a pretty summary before the exceptions are cleared. Charts come after the ledger is true, not before.
If you disagree and want auto-categorized-fast over verified-then-categorized, that's a legitimate trade. Just know which one you're running, because the difference is invisible until tax time or a dispute, and then it is very visible.