Automatic Transaction Categorization With Client Rules

Automatic transaction categorization assigns each statement line to an account in a client's chart without you picking it by hand. You get reliable results by writing a rule for each recurring vendor once, letting the client's past coding fill in the rest, and sending every line the rules are unsure about to a review queue.

How do categorization rules match a transaction?

A categorization rule matches a transaction by comparing the text of its description, and sometimes its amount or direction, against a pattern you wrote. When the pattern fits, the rule assigns the account attached to it. Rules are only as good as the description text they read, so matching starts with how banks print descriptions.

Banks add noise to the vendor name. A single supplier can appear as "SQ *FLOUR SUPPLY CO 03/13" one month and "SQ *FLOUR SUPPLY CO 04/09" the next, with a different date or store code each time. A rule that expects the full string will match once and never again. A rule that looks for the stable part, "FLOUR SUPPLY", matches every month.

Four ideas decide how well a rule behaves:

• Pattern: the stable text to look for, usually the vendor name without dates, store numbers or reference codes.
• Specificity: a longer, narrower pattern wins over a short, broad one when both fit the same line. "AMAZON MKTPLACE" should beat "AMAZON" if you have written both.
• Conditions: an optional amount range or a debit or credit direction, used when the same vendor needs different accounts in different situations.
• Order: when two rules still tie, the one checked first wins, so the order of your rules is part of the rule set.

The rule table below shows how a small rule set for one client might read. Every value is an example.

The last three rows are the tricky cases, and each gets its own treatment later in this post. A rule table that handles only the easy vendors will categorize most lines and still produce wrong books, because the wrong ones are always among the hard few.

Why a pattern beats an exact string

An exact-string rule feels safe because it cannot match the wrong thing, but it stops working the first time the bank changes a date format or adds a trailing code. A pattern built on the stable core of the name keeps working across months. The cost is that a loose pattern can catch lines you did not intend, so the habit to build is to write the shortest pattern that is still unique to the vendor.

Writing a vendor categorization rule once per client

A vendor rule is a saved pairing of a description pattern and an account, scoped to one client. You write it the first time a vendor shows up uncategorized, and from then on every statement for that client uses it. The scope matters: a rule that lives in one client's workspace cannot change another client's books.

Per-client scope exists because the same vendor means different things in different books. A hardware store is supplies for a contractor and a personal expense for a sole proprietor who mixes them. Two clients can also run different charts of accounts, so "Office Supplies" in one set of books may be "Office Expense" in another. A rule names an account in a particular chart, so it belongs to that client.

A routine for the first month

For a new client, the first month does most of the work. A short routine keeps it efficient:

1. Convert the statements and sort the uncategorized lines by vendor, not by date.
2. Pick the vendors that appear most often and write a rule for each.
3. Rerun the categorization and look at what remains. The leftovers are the one-off purchases and the shared vendors.
4. Decide the account for each remaining one-off by hand, and write a rule only if you expect the vendor to return.

Writing a rule for a vendor you will see once is a common mistake. It clutters the rule set, and a rule set you cannot read at a glance is one you stop trusting. The guide to sorting uncategorized lines by vendor or by amount covers how to clear a backlog before the rules exist.

Naming and keeping the rule set small

Keep the account names exactly as they appear in the client's chart, and keep one rule per vendor where you can. When you find yourself writing three rules for one vendor, the vendor probably needs a condition on amount or direction instead.

Whether to share rules across clients or keep every set separate is a practice-level decision. Shared versus per-client rules in a practice lays out the trade-off.

Using past coding history to categorize new transactions

Past coding history is the record of how you or the client's earlier bookkeeper categorized the same vendors in earlier periods. A tool can reuse that record: if "FLOUR SUPPLY" went to Cost of Goods Sold in every earlier month, the same line this month probably goes there too, even if you never wrote a rule.

This is the part that makes onboarding a client with existing books faster. AutoBankConvert's homepage describes this as rules you write once plus each client's past coding assigning every transaction to an account. Rules are explicit and predictable. History is a fallback that covers the long tail of vendors you did not write rules for.

What history is good at

History works best on vendors with a consistent past. A landlord, a utility, a software subscription or a regular supplier was almost certainly coded the same way each month, so a new line from the same vendor has an obvious home.

What history cannot tell you

History is a pattern of past decisions, not a statement of what is correct. If the previous bookkeeper coded a client's owner draws as an expense for three years, history will happily repeat that mistake. Treat the first review of a new client's history as an audit of the habits you are about to inherit, and fix the rules that encode a mistake before they categorize another year.

History also thins out for a new vendor, a new account or a client whose business changed. In those cases the honest answer from the tool is "unsure", and the line should go to review rather than receive a guess dressed as an answer.

What happens to transactions a categorization rule is unsure about?

Transactions that no rule matches clearly, and that history cannot settle, go to a review queue instead of being posted to a guessed account. The queue shows the line with a suggested category, and you accept it or change it. This is the safeguard that keeps automation from creating silent errors.

The homepage describes the behavior this way: uncertain transactions go to the review queue with a suggested category, and approving one teaches the client's rules, so the same vendor is categorized automatically next month. The first time you see a vendor costs you a decision. Every later month costs you nothing for that vendor.

What to look at in the queue

A queue is faster to clear when you read it in a consistent order:

1. New vendors first. These are the lines that will become rules.
2. Large amounts next. A wrong account on a large line moves the reports more than ten wrong small lines.
3. Suggestions you disagree with. If a suggestion is wrong, the rule or history behind it is probably wrong too, and fixing that source prevents a repeat.
4. Everything else last, usually small recurring items you can approve in bulk.

Approving versus correcting

Approving a suggestion confirms the pairing and makes it stick. Correcting a suggestion should also update the rule behind it. If you change the account and leave the old rule in place, the same mistake returns next month. A good habit is to ask, each time you correct a line, whether this is a one-off or a change to the vendor's standing treatment.

A healthy queue shrinks. In month one you review many lines. By month three the queue should hold mostly new vendors and the shared vendors that no rule can settle. If your queue is not shrinking, your rules are probably too specific or too many.

Categorization rules that misfire on shared vendors

A shared vendor is one where the same payee text can belong to different accounts, such as a marketplace used for both business and personal purchases. A rule on the vendor name cannot tell the purchases apart, so it will categorize some lines wrongly. The fix is to stop forcing a single answer.

Here are the three tricky cases from the rule table, with the treatment for each.

A marketplace vendor used for personal and business

A client buys packaging and a pair of shoes from the same large marketplace, and both lines read "MKTPLACE" with an order code. A rule that maps the vendor to supplies books the shoes as a business expense. A rule that maps it to owner draws books the packaging as personal.

Do not write a fixed-account rule for this vendor. Send every line to review, and let the client explain the ones you cannot judge from the amount. If a pattern emerges, such as business purchases always arriving in orders over a set amount, a condition on amount can take the common case. Expect to keep a human decision on the rest.

A transfer between the client's own accounts

A line reading "TRANSFER TO SAV" moves money between two accounts the client owns. It is neither income nor an expense, and categorizing it as either overstates both. Map it to a transfer account, and check that the matching deposit appears on the other account's statement in the same period. If one side is missing, a statement is missing, which is worth knowing before month end.

A refund that reverses an earlier purchase

A credit from a vendor is not income. It cancels part of an earlier expense, so it belongs in the same account as the purchase it reverses. A rule that maps every credit from the vendor to income would overstate revenue. Use the credit direction as a condition so refunds go back to the original expense account, and keep them visible in review until you trust the rule.

Spotting a misfiring rule

Misfires rarely announce themselves. Three checks find most of them:

• Sort a month by account and look for lines whose vendor does not belong in that account.
• Look for a vendor that appears in two accounts across the year.
• Compare an account's total with its usual range, and investigate any large swing.

When one rule produces repeated corrections, narrow it with a condition or replace it with a review-only rule.

Where categorization sits in a monthly batch

Categorization sits between conversion and export. Statements are converted and checked first, because there is no point categorizing lines from a statement that did not balance. Rules then assign accounts, the review queue collects the unsure lines, and the export carries the finished categories into the client's books. The AI side of a statement converter explains how suggested categories differ from fixed rules, and pulling statements by API versus uploading them covers the intake step that comes before all of this.

In AutoBankConvert, each client has their own workspace with their own accounts, rules and history. To run a batch with rules and a review queue on your own clients, request a spot through get started.

A last check before export

Before sending a categorized batch to the books, look at three numbers per client: how many lines were categorized automatically, how many wait in the queue, and the count of lines in each account that you did not expect. A clean batch has an empty queue, or a queue you have deliberately left for the client to answer. Anything else is an unfinished close, however tidy the export file looks.