How do you categorize bank transactions?

A bank gives you a description string and an amount. Categorization is the process of turning that into a label you can total up. The whole difficulty lives in the description, which was written for a payment network rather than for you: truncated merchant names, acquiring bank prefixes, store numbers, city codes and reference strings, all jammed into a fixed character limit.

Choosing the category list

Start with the list, not the transactions. A good list is short, mutually exclusive, and organized around decisions you might actually make. For a household that is typically housing, utilities, groceries, eating out, transport, health, insurance, subscriptions, shopping, entertainment, savings, debt repayment and income. For a business, mirror the chart of accounts you already report against so nothing needs remapping at year end.

Resist the urge to split finely. A category that contains three transactions a year tells you nothing and costs you a decision every time a borderline transaction appears. You can always split later; merging a sprawling list retroactively is much more painful.

Rules

A rule is a pattern plus a category. In its simplest form: if the description contains this text, apply this category. Better systems allow additional conditions such as an amount range, a direction, a specific account or a date window. The reason rules matter is that they are deterministic and retroactive. The same input always produces the same output, and adding a rule today fixes two years of history in one action.

Rule ordering and specificity

When two rules match the same transaction, something has to break the tie. The usual convention is that the more specific rule wins, and where specificity is equal, the more recently created rule wins. This matters more than it sounds: a broad rule written on day one will quietly swallow transactions that a precise rule written on day fifty was meant to catch.

Where AI fits

A language model is genuinely good at one part of this: looking at an unfamiliar merchant string and guessing what kind of business it is. It is a poor choice for the bulk work, because its answers can change between runs and it cannot tell you why it decided what it decided. The pattern that works is AI as a suggestion for the unmatched residue, with the human acceptance turning into a permanent rule. See how AI categorizes transactions for the detail.

A rule that pays for itself

One household's grocery shop appeared under four different description strings depending on which store branch and which card terminal processed it. Four rules, or one rule matching the common merchant token, collapsed roughly 300 transactions a year into a single reliable category. That one pattern accounted for more categorized rows than the next fifteen rules combined.

An ambiguity that needs a human

A large general retailer sells groceries, clothing, electronics and fuel. The description is identical regardless. No text rule can resolve this. The workable answers are to accept a single Shopping category for that merchant, to add an amount-based heuristic if the pattern is strong enough to trust, or to accept that those specific rows land in a review queue every month.

The over-broad rule

A rule mapping any description containing the word gas to Fuel also captured the gas utility bill. The category total looked plausible, so it went unnoticed for months. It surfaced only during a quarterly audit of the largest category, which is exactly why that audit is on the step list above.

• Consistency. The same merchant lands in the same category every time, which is what makes month-on-month comparison meaningful.
• Retroactive correction. One rule change fixes the full history rather than just the row in front of you.
• Explainability. You can point at the rule that made a decision. An accountant or auditor can follow it without trusting you.
• Compounding effort. Every exception you resolve permanently reduces future work.
• Speed. Rules process thousands of rows in milliseconds, with no per-transaction cost.

• Too many categories. Forty categories means constant borderline decisions and inconsistent history.
• Rules that are too broad. Match on distinctive merchant tokens, not on common words that appear across unrelated businesses.
• Fixing rows instead of rules. Correcting a transaction without updating the rule guarantees you will correct it again next month.
• Treating transfers as spending. Every internal transfer counted as an expense inflates outgoings and makes savings look like a cost.
• Booking refunds as income. A refund belongs back in the category it came from, otherwise both income and that category are overstated.
• Not applying new rules to history. If a rule only affects future transactions, your year-on-year comparison is comparing two different categorization schemes.
• Renaming categories mid-year. Reporting breaks silently. Decide the list up front and change it deliberately at a period boundary.