Bank rules for bookkeeping: how rules should work

Bank rules for bookkeeping should be created from the bookkeeper's first categorization of a payee, not written by hand in a settings screen, and they should carry the vendor as well as the account so every coded line has a name on it. The close then audits the rules, by running a report of what each rule coded that month, before anyone trusts the P&L. A rule built that way codes the next two years of a payee's transactions correctly. A rule built wrong codes them all wrong, just as fast.

We run an accounting firm, and rules are how a bookkeeper carries thirty clients instead of twelve. They're also how one of our clients ended up with $69,000 in the wrong account for four months. Both stories are below.

Payee-sort: why the same payee gets the same account

Open any client's Uncategorized list and sort it by payee instead of by date. The list collapses. Four hundred transactions become sixty payees, and for fifty of them the account is obvious from the name: the utility is Utilities, the fuel station is Auto, the payroll provider is the payroll clearing account, the landlord is Rent. The same payee gets the same account, almost every time, for years.

That's the whole case for rules. The bookkeeper decides once, and the decision applies forward. What's left after rules is the genuinely new: a payee never seen before, a known payee at an unusual amount, a transfer that needs its other side. That residue is a tenth of the pile and it's the part that deserves a person.

The mistake most firms make is treating rules as a setup task. Someone sits down, writes thirty rules by hand, and stops. Then the client adds a new vendor every week and the rules never catch up, so the bookkeeper is back to coding line by line with thirty exceptions. The rule has to be created at the moment the bookkeeper codes a payee for the first time, as a side effect of the work, or it doesn't get created.

Rules that carry the vendor so every line has a name

A rule that says "anything containing SHELL goes to Auto Fuel" is half a rule. The other half is the vendor: this line is a payment to Shell, the vendor record, with its 1099 status, its payment history, its W-9 if it needed one, and its own line on the vendor report.

Lines coded to an account with no vendor are the reason a client's Office Expense is $14,000 and nobody can say to whom. They're the reason 1099 totals are wrong, because payments to a contractor got coded to Repairs with no name and never made the vendor's total. And they're the reason a duplicate-vendor cleanup finds eleven versions of one utility: each bookkeeper who touched the file typed the name slightly differently instead of letting the rule assign it.

So the rule carries both. Payee pattern, account, vendor, and where it applies, the class or location or property, so the dimension the CFO reports depend on gets set at the same moment. Every line coded by rule has an account and a name, and the vendor list stays clean because the rule is the only thing that assigns it.

The $69,000 lesson: auditing rules against categories

A rule is a machine that codes without asking. That's the value and the risk.

One of our clients, a contractor, had a rule that coded a supply house to Materials. Correct. The supply house then started running the client's equipment financing through the same merchant account, so the monthly finance payment, about $4,300, arrived on the feed with the same payee string. The rule coded it to Materials. For four months. By the time the loan sub-ledger showed the note's balance hadn't moved, $69,000 of loan principal and interest was sitting in cost of goods, job margins were understated across every job, and the owner had priced two bids off the wrong number.

The fix was a five-minute reclass. The lesson was structural: a rule that's right today can be wrong next month because the payee changed what it sends, and nobody watches a rule after they write it.

So the close audits the rules. One report, every month: each rule, the count and total of what it coded, the account it coded to. A rule that coded twelve lines last month and thirteen this month is fine. A rule whose total jumped from $8,000 to $12,300 gets opened. A rule that coded to Materials at an amount that looks like a loan payment gets opened. It takes ten minutes and it's the step between "the rules ran" and "the P&L is right."

The audit also catches the rule that was wrong from day one: the new bookkeeper who coded the merchant processor's fees to Bank Charges when the client tracks them as a cost of sales, and the rule that faithfully repeated the mistake for a quarter.

Rules versus AI suggestions: who decides

Suggestion engines have gotten good at guessing what a transaction is. They're useful for the residue: the new payee, the odd amount. They are not a replacement for rules, for one reason. A rule is a decision the firm made and can audit. A suggestion is a guess the software made and the bookkeeper accepted, and if it was accepted for 400 lines without review, nobody can say later why any of them landed where they did.

The way we run it: rules code deterministically, from the bookkeeper's own first choice. Suggestions appear only on what rules didn't catch, and a person confirms each one. When a confirmed suggestion is for a payee that will recur, it becomes a rule, so the next occurrence is a decision rather than a guess. The bookkeeper decides. The software remembers. We wrote about where the line sits in can AI do your bookkeeping.

Rules across a firm's client list

A firm with sixty clients has sixty rule sets, and most of them overlap. Every client pays the same payroll provider, the same handful of software subscriptions, the same fuel stations and office suppliers. The account each lands in may differ by client (one tracks software as Overhead, another by department), so rules are per client. But the pattern for recognizing a payee, and the vendor it maps to, can be shared, so a new client onboarded on Tuesday starts with the firm's knowledge of a hundred common payees rather than a blank list.

The other cross-client view is the audit. A partner should be able to see, across every client, which rules coded the most dollars this month and which changed the most from last month, without opening sixty files. That's the difference between rules being a productivity feature and rules being a control.

Where the platform comes in

Woven is our product, and rules in it work the way this article describes because we needed them to. The bookkeeper's first categorization of a payee becomes the rule, and the rule carries the account, the vendor, and the class or location or property together, so every coded line has a name and a dimension. The close includes the rules-by-category report, so the $69,000 kind of drift is caught in the month it starts. Suggestions appear only on what rules didn't catch, a person confirms each one before it posts, and a confirmed choice for a recurring payee becomes the next rule. To see rules being learned on a live feed, book a demo.