Bank rules done right: automation with judgement built in

What a rule is actually promising

Creating a bank rule means making a standing promise: every future transaction matching these conditions gets this exact account, this GST treatment and this contact, without a person ever looking at it again. That promise is safe for anything genuinely uniform, the monthly software subscription that's always the same supplier, same amount, same GST treatment. It's unsafe for anything that merely looks uniform, and telling those two apart is the entire skill in rule design.

Where rules earn their keep

• Fixed subscriptions and utilities: rent, software, insurance instalments and telco bills, where the supplier and treatment never move
• Bank fees and merchant charges: small, frequent, and identical in treatment every time, making them ideal candidates
• Transfers between your own accounts, coded the same way each time so they never masquerade as income or expense
• Payroll clearing transactions that follow an identical pattern every single cycle
• Recurring loan repayments, split correctly between principal and interest, provided you keep maintaining the split

Where rules go wrong

Rule failures follow a small number of repeatable patterns, and almost every damaged file we review has at least one of them lurking.

The overbroad match is the classic mistake. A rule keyed on a description containing a common word, or a supplier name that happens to appear inside other suppliers' names, starts swallowing transactions it was never built for. Mixed purpose suppliers set the next trap: a rule that codes every hardware store purchase to repairs will happily miscode job materials, capital purchases and the odd private spend, all with the same straight face.

GST is the quiet failure. A rule fixes the treatment at the moment it's created, and the world keeps moving underneath it: a supplier registers or deregisters for GST, a product mix shifts, a subscription moves from an overseas biller to a local entity. The rule keeps applying yesterday's treatment regardless, and the error repeats monthly until a BAS review eventually catches it. Rules also happily fire on refunds and reversals that match the pattern, coding money coming in as if it were the usual money going out.

Design principles that keep rules safe

Match on the most specific conditions available, combining payee and description rather than leaning on one loose keyword. Prefer rules that suggest rather than auto confirm wherever the stakes are higher, so a person still clicks through with eyes on the line. Never build a rule for a supplier whose purchases vary in purpose, however frequently they show up; frequency isn't the test, uniformity is. And keep the rule list short enough to actually review, because fifty rules nobody remembers is a liability, not a system.

Then close the loop. Once a quarter, ideally before each BAS, list every active rule and check whether its coding and GST treatment are still correct. Skim a sample of transactions each rule has captured. Fifteen minutes, and it turns rules back from a slow moving risk into genuinely reliable automation.

Rules with a review layer

This is the pattern behind everything we automate at NextEra: let the machine handle whatever's genuinely uniform, and route everything else to a person trained to judge it. Our CPA led team builds and audits rule sets as part of the Strategic Finance Review, and rule misfires are some of the most common, and most fixable, problems we find in the files that land on our desk.