Key takeaways
What this article covers, in order:
- The anatomy of a rule
- A rule that works
- Three ways rules misfire
- How to write safer rules
- Rules vs suggestions
- When rules really earn their keep
What are bank rules? Each one is an instruction you write once, such as "if the description contains TELSTRA, code it to Phone and internet", that many accounting tools then apply to every matching bank transaction. Rules save time on predictable, repeating payments. They also make mistakes at scale, because a rule never asks whether this particular transaction is the exception. Here's how they work and how to think about them sensibly.
The anatomy of a rule
Almost every bank rule, in any accounting software that has them, has three parts:
- A condition. What to look for. Usually text in the description ("contains", "starts with", "equals"), sometimes the amount ("equals $49.00" or "between $40 and $60"), and sometimes the direction (money in or money out).
- An action. What to do when the condition matches: which account to code it to, which GST code to apply, maybe a contact name or a note.
- An order. When two rules could match the same line, which one wins. Usually the one higher up the list.
Some tools also let you split a match by percentage ("70% Motor vehicle, 30% Owner drawings") or create a transaction automatically without review.
A rule that works
Jack runs a physio clinic in Fremantle. His practice software subscription comes out on the 1st of every month for exactly $219.00, and the bank description always reads "CLINIKSOFT PTY LTD". A rule saying "description contains CLINIKSOFT, code to Software and subscriptions, GST on expenses" will be right every single time. One merchant, one purpose, one amount. That's the ideal case for a rule.
Three ways rules misfire
1. The condition is too broad
Jack writes a second rule: "contains WOOLWORTHS, code to Clinic consumables." It's meant for tissues, hand sanitiser and paper towel. Then one week his partner uses the business card for the family shop by mistake. The rule codes $312.45 of groceries to clinic consumables. No one notices, because the rule did exactly what it was told.
2. Rules fight each other
He adds "contains WOOLWORTHS PETROL, code to Motor vehicle." But it sits below the general Woolworths rule in his list. Every fuel purchase now matches the first rule and lands in consumables. The fuel rule never fires.
3. The world changes and the rule doesn't
His cleaner used to invoice under her own name. She sets up a company and the bank description changes. The old rule stops matching, and those payments sit uncategorised. Worse, he later hires a plumber whose business name happens to contain the same word as the old rule. The rule codes the plumber as cleaning.
Here's what one bad month can look like:
| Transaction | Amount | Rule applied | Should have been |
|---|---|---|---|
| WOOLWORTHS 1234 FREMANTLE | $312.45 | Clinic consumables | Owner drawings |
| WOOLWORTHS PETROL 0456 | $88.20 | Clinic consumables | Motor vehicle |
| WOOLWORTHS PETROL 0456 | $91.35 | Clinic consumables | Motor vehicle |
| WOOLWORTHS 1234 FREMANTLE | $42.60 | Clinic consumables | Clinic consumables |
The rules coded $534.60 to consumables ($312.45 + $88.20 + $91.35 + $42.60). Only $42.60 of it belonged there. That's $492.00 in the wrong place in a single month, and nothing looked broken.
How to write safer rules
If you use software with bank rules, these habits keep them honest:
- [ ] Be specific. Match the full, distinctive part of the description, not a common word.
- [ ] Add an amount condition for subscriptions with a fixed price, so a different charge from the same merchant gets flagged.
- [ ] Set the direction. A rule for supplier payments shouldn't also catch a refund from that supplier.
- [ ] Don't auto-post big-box or supermarket merchants. Code them by hand, or let the rule suggest but not finalise.
- [ ] Put specific rules above general ones.
- [ ] Review your rules every quarter. Delete ones for suppliers you no longer use.
- [ ] Spot-check rule-coded transactions when you reconcile, not just the uncategorised ones.
Rules vs suggestions
There's a difference worth understanding between a rule that posts a transaction automatically and anything that suggests a category for you to confirm.
A posting rule is fast and silent. Once set, matching transactions skip your attention entirely. That's the point, and it's also the risk.
A suggestion, whether from a rule or from AI looking at your history, still leaves the transaction in front of you. It costs a click per line, but you see every transaction go past. For most small businesses with under a few hundred transactions a month, that review click is cheap insurance.
Neither approach is wrong. Rules suit high-volume, highly repetitive accounts where someone checks rule output regularly. Suggestions suit businesses where the owner is the bookkeeper and wants to see where the money went.
When rules really earn their keep
Rules make the most sense when:
- the same merchant always means the same thing
- the amount is fixed or in a narrow range
- the volume is high enough that confirming each one by hand is genuinely tedious
- someone reviews the output at least monthly
They make the least sense for mixed-purpose merchants, people's names, round-number transfers and anything that comes in as income.
How HelloBooks handles this
In HelloBooks the workflow is built around suggestions you review. Transactions from your bank feeds or CSV imports land in a review list where you confirm or change the category. On Pro (A$30 a month), AI auto-categorisation suggests a category for each one; you still confirm it. The Free plan includes free AI credits to get started, and if they run out, AI categorisation pauses while the books keep working.
At month-end, the reconcile screen shows an AI match suggestion on each statement line with a confidence score and the reason it picked that match, so you can see why something was matched before accepting it. More on our bank reconciliation software and AI bookkeeping pages.
FAQs
Are bank rules the same as bank feeds?
No. A bank feed brings transactions in from your bank. A bank rule, in software that offers them, decides how some of those transactions get coded once they've arrived.
Can a bank rule handle GST?
In most tools that have rules, you can set a GST code as part of the action. That's helpful for consistent items, and risky for merchants that sell both taxable and GST-free products. Get the codes right; your BAS agent or accountant handles lodgement.
How do I find transactions a rule miscoded?
Run a report of the account the rule codes to, filter by the merchant name, and scan for anything that looks out of place: unusual amounts, weekend dates, odd descriptions.
Should I let rules post transactions automatically?
Only for very predictable payments, and only if someone reviews the results regularly. For anything mixed or variable, have the rule suggest rather than post.
What's a sensible number of rules?
There's no magic number. A dozen well-written rules beat a hundred vague ones. If you can't remember why a rule exists, check it and probably delete it.
A rule is only as good as the day you wrote it, so give yours a regular look.
Start free, no card needed. Try HelloBooks Free
