A categorisation rule is a mapping from a raw bank transaction description to a spending category. When your bank statement says “AMZN*MARKETPLACE 415-781-5523 WA”, a categorisation rule translates that to “Shopping” (or “Amazon” if you’re more granular). Without categorisation rules, a bank feed is just a list of cryptic strings and numbers.
This is the “invisible UX” of every personal finance app — users don’t see the rules, they see the result. But categorisation accuracy is what separates apps that feel intelligent from apps that feel broken.
How categorisation rules work
Most apps use a combination of:
Vendor-maintained merchant database. The app operator (YNAB, Monarch, Copilot) maintains a database mapping common merchant strings to categories. “NETFLIX.COM” → Entertainment. “WHOLE FOODS” → Groceries. “SHELL OIL” → Transport: Fuel. The quality of this database determines first-pass accuracy.
User corrections as training data. When you correct a miscategorised transaction, the app records the correction. In most apps, the same merchant string will be categorised correctly in future. In smarter apps (Copilot, Monarch), the correction propagates backwards to fix existing transactions with the same merchant.
Explicit user rules. You can create rules manually: “any transaction from Merchant X always goes to Category Y”. This is important for unusual merchants, company-specific vendors, and the “Costco problem” — a Costco transaction can be groceries, household goods, electronics, or clothing depending on what you bought.
The Costco problem: why splits exist
Categorisation rules fail when one transaction covers multiple categories. A £180 Costco run might be:
- £100 groceries
- £40 household supplies
- £40 clothing (that jumper you grabbed)
A rule can only assign one category. The solution is split transactions — manually dividing a transaction across multiple categories. Most apps support splits; the quality of the split UI varies significantly.
Categorisation accuracy benchmarks (our testing)
In our 100-transaction standardised test CSV across the 5 reviewed apps:
| App | First-pass accuracy |
|---|---|
| Copilot | 91% |
| Monarch | 88% |
| YNAB | 85% |
| Tiller (AutoCat) | 72% |
| PocketSmith | 79% |
First-pass accuracy improves significantly after 30 days of corrections. The 30-day accuracy for Copilot and Monarch reaches ~95–96%. The gap between apps narrows over time but the first 4–6 weeks of a new app feel more or less intelligent depending on the starting accuracy.
Why categorisation matters for Mint refugees
Mint refugees (users who relied on Mint’s auto-categorisation for years) typically have 3–5 years of correction history embedded in Mint’s system — corrections that set “AMZN*PRIME” to “Subscriptions” instead of “Shopping”, rules that split Costco bills, rules that route a specific employer’s expense reimbursement to “Income: Reimbursement” not “Income: Salary”. None of this transfers when you migrate.
The categorisation history is non-exportable from Mint (the CSV export includes transactions and amounts, not the categorisation rules). Starting over in a new app means rebuilding this muscle memory. Budget 4–8 weeks for the new app’s rules to learn your correction patterns before judging it against what Mint knew about you.
Related terms
- Bank Feed / Aggregation — the import layer that categorisation rules apply to
- Split Transactions — handling the multi-category transaction problem
- Recurring Transaction Detection — the complement to categorisation rules for subscription management