August 5, 2026 · 4 min read
Why Bank Rules Break (the Quiet Failure Mode of Automated Bookkeeping)
August 5, 2026
Every bookkeeping tool offers the same seductive feature: write a rule once — "this payee goes to this account" — and never categorize that transaction again. And every experienced bookkeeper has the same scar: the rule that was right in January and silently wrong by June.
This is the quiet failure mode of automated bookkeeping. It deserves a plain explanation.
What is rule drift?
Rule drift is what happens when a categorization rule stays frozen while the world it describes moves. The rule "Amazon → Office Supplies" was a correct observation the day it was written. Then the same payee shipped a laptop, a birthday gift, and resale inventory — three different accounts, one rule, applied silently to all of them.
The rule didn't break. Reality changed underneath it. The books, meanwhile, kept looking perfectly normal.
Why is drift so expensive when each error is so small?
Because rules apply automatically and repeatedly. A one-time miscode is one wrong line. A drifted rule is a subscription to that mistake: $200 a month in the wrong account is $2,400 by year-end — from a single rule, with zero warnings along the way. Multiply by however many rules a set of books carries, and by however many months since anyone audited them, and you have the raw material of a tax-season cleanup.
The damage profile is uniquely bad: small enough per-instance that no one notices, systematic enough that it compounds.
Why don't rules scale across clients?
Because every client needs their own — the same payee legitimately means different things in different businesses — and each client's rules decay independently. Practitioners consistently describe the same ceiling: somewhere around fifteen to twenty-five clients, the rules library becomes its own unpaid maintenance job. You're no longer doing bookkeeping; you're gardening a thicket of frozen guesses, and pruning it honestly would take the time you were saving.
Most people resolve this the quiet way: they stop auditing the rules and hope. Which is how drift wins.
Are rules just bad? Should automation be turned off?
No — the alternative to bad automation isn't manual data entry; it's accountable automation. Rules fail for three specific, fixable reasons:
- They're static. A rule is one frozen decision; the payee's behavior is a moving distribution.
- They're silent. No rule announces "I just matched something unusual." Confidence and correctness look identical.
- They're unattributed. Six months later, nobody remembers why the rule exists or whether its assumption still holds.
Flip those three properties and automation stops being dangerous: categorize from the client's history rather than a frozen rule, so new patterns register as new; flag the matches that don't resemble that history instead of processing them silently; and attach evidence to every decision, so review means reading a reason, not reverse-engineering one.
How often should you audit the rules you have?
If you're running on rules today: quarterly, minimum — and immediately for any rule touching a payee where amounts vary a lot. The five-minute version that catches most drift: pull each recurring rule's matches for the last quarter and scan the amounts. Anything that jumped an order of magnitude, or started matching a different-looking description, gets a human decision.
If that audit sounds like time you don't have, that's not a personal failing. It's the argument that rules were the wrong abstraction for this job.
Where Nalo fits, stated plainly
Nalo doesn't use frozen rules. It categorizes each transaction against that client's own history, shows the evidence for every decision, and sends anything that doesn't resemble the past to review instead of guessing — so an unusual $4,500 charge from a routine payee gets a human look the week it happens. What you teach it on one client never leaks into another. See how it works at nalo.app.