Bank rules are one of the most useful automations in a manual ledger and one of the quietest sources of BAS error, for the same reason: they apply a coding decision automatically, at scale, without asking again. A rule matches a transaction on something like a keyword in the bank narration, then applies a predefined account code, GST treatment, and contact, and offers it up for one-click reconciliation. For recurring, predictable transactions that is genuinely efficient. The catch is that a rule does not update itself when the business changes, so a decision that was correct the day it was made keeps running long after it stopped being right, and it takes every matching transaction with it.
Why a rule that was right becomes wrong
The failure is not that rules break, it is that reality moves and the rule does not. A rule created three years ago coding a supplier to advertising expense still fires today, even if that supplier now provides IT services, so every transaction from them lands in the wrong account. A rule set to GST-free for an overseas subscription keeps applying GST-free treatment even after the supplier has registered for GST in Australia and started charging it, quietly denying a credit the client is now entitled to. A rule built on a loose keyword to catch fuel expenses will also catch any transaction from a business whose narration happens to start with the same letters, coding unrelated payments to the fuel account. In each case the rule is doing exactly what it was told. The instruction is simply out of date, and nothing in the software flags that the world has changed underneath it.
What makes this dangerous rather than merely untidy is that none of it looks like an error in the day-to-day view. The transaction matches, it reconciles, the bank account shows no outstanding items, and everything appears clean. The wrong GST code sitting behind the match is invisible until the quarter closes and the figures are read by treatment rather than by bank balance. By then the same wrong code has been replicated across every matching transaction for three months, so a single stale rule does not produce one error, it produces the same error dozens of times, which is what turns a small oversight into a material BAS movement.
The errors that compound fastest
Wrong GST treatment is the highest-risk outcome. A rule applying GST-free to a taxable purchase quietly forgoes input tax credits quarter after quarter, while a rule applying GST-on-expenses to a supplier who is not registered claims credits the client is not entitled to, which is the more serious direction because it overstates the refund or understates the liability. Both are invisible until someone runs a transaction-level GST review. Account miscoding causes a different kind of damage: transactions flowing to the wrong expense category distort the client's profit and loss, so any management decision made on those reports is made on bad data, and at year-end the accountant has to unpick and recode a volume of transactions that should never have been miscoded. The third pattern is the over-broad condition, where a rule built on a short or partial string matches transactions it was never meant to, running silently in the background until an account balance looks wrong at quarter end and someone has to work out why. All three share the same signature. They are created by a rule, applied without review, and surfaced only when the BAS or the P&L finally forces a proper look.
The quarterly review that prevents it
The fix is not to abandon bank rules, which would throw away their real efficiency, it is to treat them as instructions that need periodic review rather than permanent truth. Most ledgers list every active rule in one place, and a quarterly pass over the ten to fifteen most active rules takes about twenty minutes and catches the large majority of problems before they reach the BAS. For each rule, three checks do the work. Does the supplier or payee still do what the rule assumes, because a changed business relationship usually means the account code or GST treatment needs to change too. Is the GST code still correct, because a supplier changing their registration status, or the nature of an expense shifting, silently invalidates the rule and any affected transactions in the current quarter should be corrected before lodgement. And is the condition specific enough, because a rule matching on a short or generic string is a standing risk of catching the wrong transactions and tightening it to a longer, more unique narration prevents that. For a firm managing large client books, this is one of the highest-return twenty minutes in the whole quarterly workflow, because it converts a silent, compounding error into a caught one while the context is still fresh.
