Categorisation Rules

Rules turn a recurring incoming transaction into a coded posting without anyone looking at it. A monthly direct debit to the same supplier for the same purpose should not need a human decision twelve times a year.

Deterministic first

Rules are evaluated before any AI-assisted suggestion is considered. The ordering is deliberate and worth understanding: a rule you wrote produces the same answer every time and can be pointed at when someone asks why a transaction was coded a particular way. A suggestion is a guess, however good.

So anything you can express as a rule, express as a rule. Reserve assistance for the genuinely ambiguous residue, and treat its output as a proposal for a person to accept.

Writing a rule

A rule matches on what the incoming transaction contains — the counterparty, the reference, the amount, the direction — and sets what it should become: the account, and any analysis dimensions you use. Match on the most stable attribute available. A supplier's name in a bank narrative is more durable than a reference number that changes monthly.

Order and specificity

Put specific rules before general ones. A rule catching everything from one supplier will swallow the one transaction from that supplier that should have been treated differently, if it is evaluated first. Review the order whenever you add a rule, not only when something goes wrong.

Keep the set small

A rule set nobody understands is worse than no rules, because its mistakes are systematic. Periodically review which rules are actually firing and delete the ones that are not — a rule matching a supplier you stopped using two years ago is a trap waiting for a similarly-named new one.

Check what rules are doing

Sample automatically-coded transactions occasionally rather than assuming. The failure mode of a good rule set is not that it stops working; it is that it quietly keeps working after the underlying assumption changed.