Automatic Transaction Categorisation rules that survive contact with reality

Almost always because the rule matches the full bank descriptor and the processor changed part of it. Descriptors routinely gain or lose a reference number, batch ID or location code. Match the stable fragment instead — the merchant name portion that holds constant — and the rule survives. This failure is silent, which is why it is usually discovered weeks later via a bloated uncategorised bucket.

Inter-account transfers booked as income or expense, which inflates both sides of your P&L. Owner draws coded as business expenses, which overstates deductions. And dual-purpose vendors where one rule is applied to two different transaction types. All three reconcile perfectly, because the bank balance is unaffected. That is exactly why they survive to year end.

Auto-add only where both the account and the tax treatment are unambiguous — a monthly software subscription, a utility bill, a known recurring vendor. Anything involving a split, a judgment call, or a vendor you buy multiple categories from should suggest rather than post. The time saved by auto-posting an ambiguous transaction is dwarfed by the cost of finding it at year end.

No, it complements them. Intuit Assist covers categorisation, reconciliation, anomaly detection and cash-flow analysis, and the AI bank feeds became default in 2026. But learned-pattern categorisation cannot explain its reasoning or be reviewed before posting. Explicit rules give you auditability on the transactions that matter; the AI handles the long tail.

Fewer than most people expect. Transaction volume is usually concentrated: 15 to 30 well-built rules typically cover 80-90% of monthly volume. Businesses that arrive with 100+ rules usually have many near-duplicates that could collapse into a handful of fragment matches, plus a chart of accounts that needs restructuring more than it needs more rules.