# Rules vs Machine Learning Categorization for Client Books

- Author: AutoBankConvert (https://www.autobankconvert.com)
- Published: 2024-11-22
- Updated: 2024-11-22
- Category: Statement automation
- Canonical: https://www.autobankconvert.com/blog/rules-vs-machine-learning-categorization

> Rules vs machine learning categorization for client bank transactions: what each gets right, where each fails, and how a review queue combines the two.
In the rules vs machine learning categorization choice, client books do best with both. Rules give exact, explainable answers for vendors you already know. Machine learning suggests accounts for new or messy lines by learning from past coding. Let rules post the predictable lines, let the model propose the rest, and send uncertain proposals to a person.

## What do rules and machine learning categorization each decide?

Rules and machine learning categorization both assign an account to a bank line, but they reach the answer differently. A rule applies a condition you wrote: if the description contains this text, use this account. A machine learning model estimates the likeliest account from lines already coded, even for a line no rule covers.

A rule is a statement of policy. It encodes a decision a bookkeeper made once, and it repeats that decision exactly. QuickBooks Online is a familiar example: Intuit's guide to [setting up bank rules in QuickBooks Online](https://quickbooks.intuit.com/learn-support/en-us/banking/how-to-set-and-use-banking-rules-for-downloaded-transactions/00/262188) describes rules with up to five conditions on description, bank text or amount, using tests such as contains, doesn't contain and is exactly. When two rules could fit, the one with the higher priority applies first. Nothing in that system guesses. If no rule fits, the line simply has no rule.

A machine learning model is a statement of likelihood. It looks at features of the line, such as words in the description, the amount, the direction of the money and the day of the month, and compares them with lines the practice has coded before. Its output is a suggestion with some measure of how sure it is. It can be right about a vendor it has never seen, because the words resemble other vendors. It can also be wrong with no visible reason.

The comparison below summarises how the two behave on client work. It describes typical behaviour, not any one product.

| Trait | Rules | Machine learning |
| --- | --- | --- |
| Setup | You write each rule | Needs coded history to learn from |
| Known vendor, one purpose | Exact and repeatable | Usually right, occasionally drifts |
| New vendor | No answer until you write a rule | Offers a guess from similar lines |
| Shared vendor, many purposes | Forces one account unless you add conditions | Guesses, often from the most common past use |
| Explaining a result | Point at the rule | Harder; the reason is a pattern, not a line of policy |
| When banks change text | Breaks if the pattern no longer matches | Often still close, because similar words remain |
| Failure mode | Silent misfire on a too-broad pattern | Confident wrong suggestion |

## Where rule-based categorization gets client books right

Rule-based categorization is the right tool wherever the answer is a fixed policy. Rent goes to rent, payroll debits go to wages, a loan payment splits between principal and interest. These lines recur and their accounts never change. A rule gives the same answer every month and can be read and checked by anyone on the team.

Rules are strongest for:

- **High-value recurring payments.** Rent, loan repayments, insurance and payroll. Errors here move the numbers that lenders and owners read first.
- **Transfers between the client's own accounts.** A transfer is never income or expense. A rule keyed on the account reference keeps it on the balance sheet.
- **Lines with a split.** A phone bill with an agreed business share, or a rent payment that includes a fixed parking fee, needs the same split every month. A [split transaction rule for recurring mixed payments](/blog/split-transaction-rules) handles that more reliably than any suggestion.
- **Anything the client has a stated policy for.** If the owner says all fuel is a vehicle expense, write that down as a rule rather than hoping a model infers it.

Rules also suit predictable timing. A charge that should arrive once a month at a known amount is a good candidate both for a rule and for a check that it actually appeared. The post on [recurring transaction detection on client statements](/blog/recurring-transaction-detection) shows how that list catches a missed or doubled charge.

The weakness of rules is coverage. Every rule exists because someone wrote it, and a new client may have dozens of vendors on the first statement. Writing a rule for each is slow, and most of those vendors will appear only once or twice a year.

## Where machine learning categorization earns its place

Machine learning categorization earns its place on the long tail: vendors that appear rarely, new payees, and descriptions too irregular for a clean pattern. In those cases there is no policy to encode yet, and a sensible first guess saves a bookkeeper from coding every line from a blank. The value is speed on unfamiliar lines, not certainty.

Useful situations include:

- **The first statements for a new client.** A model trained on the practice's other clients can suggest plausible accounts for common vendors such as software subscriptions or office supply stores. A practice should check that its tool keeps one client's data out of another's books before relying on this.
- **One-off purchases.** A single hotel stay or conference fee rarely deserves a rule.
- **Descriptions that change shape.** When a processor rewrites its prefixes, a pattern rule can stop matching overnight. A model that learned from the words of the vendor name may still land close.

A model's suggestion should be read as a starting point. The post on [what an AI bank statement converter actually does](/blog/ai-bank-statement-converter) covers which parts of a converter rely on learned models and how to check their output.

## Failure modes of rules and of machine learning side by side

Rules and machine learning fail in opposite directions. A rule fails by being too broad or too narrow: it either catches lines it should not, or it misses lines it should catch. A model fails by being confidently wrong: it proposes a plausible account that does not fit this client. Both failures are quiet unless your workflow looks for them.

### How a rule misfires

A rule written as "contains AMAZON goes to office supplies" will post a client's inventory restock, a new laptop and the owner's personal order to the same account. Nothing flags it, because the rule did exactly what it says. The fix is narrower conditions or leaving that vendor in review. Rules also decay: when a bank changes how it prints a vendor, the rule stops matching and lines fall back to uncategorized.

### How a model misfires

A model learns from what it has seen. If most practices code a particular software vendor to subscriptions, it will suggest that even for a client who resells that software and should code it to cost of goods sold. Models also amplify history. A line that was miscoded for six months becomes strong evidence for the wrong account in month seven.

### A worked routing example

The example below shows how five lines from one fictional client might be handled. Amounts and accounts are illustrative.

| Description | Amount | Handled by | Outcome |
| --- | --- | --- | --- |
| LANDLORD PROPERTIES RENT | -3,200.00 | Rule | Rent, posted |
| TRANSFER TO SAVINGS 4471 | -1,000.00 | Rule | Transfer, posted |
| NORTHWIND CONF REGISTRATION | -450.00 | Model | Suggests training, sent to review |
| AMZN MKTP US*2K41Z | -189.99 | Rule says review | Held for a person |
| BLUEPEAK SOFTWARE | -89.00 | Model | Suggests subscriptions, sent to review |

The rules settle the two lines where policy is clear. The model gives a head start on two unfamiliar vendors. The marketplace line is held on purpose, because neither a rule nor a guess can know what was bought.

## When should a machine learning suggestion never post on its own?

A machine learning suggestion should never post without review when a wrong answer changes the client's tax position, balance sheet or owner relationships. Large amounts, possible capital purchases, payments to related parties and anything that might be personal fall in that group. In those cases a fast guess costs more than the minute it takes to look.

Keep these in review regardless of how sure the model is:

- Amounts above a threshold the practice sets per client.
- Lines from vendors that sell both business and personal goods.
- Any credit that could be a loan, an owner contribution or a refund rather than revenue.
- Lines in the first month for a new client, before you have checked the model's habits against that business.
- Lines for clients in regulated or unusual industries, where common coding patterns do not apply.

The same caution applies at the end of an engagement. When a client leaves, the rules and coding history you built are part of what you hand over or retire, and the [bookkeeping client offboarding checklist](/blog/bookkeeping-client-offboarding-checklist) covers what to export and what to delete.

## Combining rules and machine learning through a review step

Rules and machine learning work best together when a review step sits between them and the books. Rules post the lines they match. Everything else receives a suggestion and waits for a person. Each approval then becomes either a new rule or added history, so the share of lines needing review falls month by month.

A practical setup for one client:

1. **Write rules for the top recurring vendors.** Rent, payroll, loans, transfers and the five or ten suppliers that appear every month.
2. **Mark shared vendors as review-only.** Make it a rule that these lines never post automatically.
3. **Let suggestions fill the rest.** Treat each one as a draft.
4. **Approve in groups by vendor.** One decision per vendor, not per line.
5. **Promote repeated approvals to rules.** When you have approved the same vendor to the same account three months running, write it down as a rule.
6. **Review the rule list each quarter.** Remove rules for vendors that have gone, and tighten any that caught the wrong lines.

AutoBankConvert follows this shape: rules you write once and each client's past coding assign accounts, and lines the rules are unsure about go to a review queue with a suggested category. Approving one teaches that client's rules. To see it on your own statements, [get started with AutoBankConvert](/get-started).