You Are Not Categorizing Expenses. You Are Categorizing Descriptors.
Here is the transaction your ledger sees: SQ *ACME AUTO PARTS 4471. Here is the vendor that exists in your vendor list: Acme Auto Parts. Here is the same company on last month's statement: ACME AUTOPARTS #44. And here is the same company the month before: ACME AUTO PARTS INC.
Three strings. One vendor. If your categorization logic treats them as three, then it builds three separate rule sets, learns three separate patterns, and produces three separate sets of errors, all for a company you buy from every single week. This is why your rules feature worked beautifully for two months and then started asking you the same question it asked you in January.
The fix is not a better model. The fix is resolving the descriptor to a real vendor first, before any categorization logic runs at all. Strip the processor prefix, strip the store number, strip the terminal identifier, normalize the spelling, and match against the vendor list you already maintain. That one step converts three problems into one, and it is the reason a vendor with sixteen identical prior codings can finally have its pattern recognized instead of being rediscovered as a stranger every month.
And once the vendor is known, the real point becomes visible. Most miscoded expenses are not mysteries that need to be guessed. They are facts that live somewhere the ledger cannot see. The parts purchase that belongs to a specific repair order is recorded on the parts order. The materials purchase that belongs to a job is recorded on the purchase order. The ledger has the bank line and nothing else, which is exactly why it keeps asking you a question that has already been answered in another system.
This is a reconciliation problem wearing the costume of a prediction problem. Treat it as the former and the accuracy goes up while your effort goes down.
How Many Transactions Actually Get Settled
This model is deliberately conservative. It assumes deterministic matches and historical patterns never fully cover your spend, because in the real world they do not. Nothing is submitted and no contact information is required.
Bank and card feed lines. A four-truck shop sits near four hundred.
Share of lines carrying a processor prefix, store number, or spelling variant.
Share of spend with a purchase order, parts order, or receipt on file.
Nothing below this is proposed for a batch approval. Deterministic matches are never held.
This is time returned from re-deriving decisions the evidence had already made. It is not a claim about headcount.
Push the threshold to its maximum and watch the exception count climb rather than the error rate. That is the honest tradeoff: a stricter bar does not make the system smarter, it moves more decisions to a person.
Illustrative estimate from the inputs on the left. Your own numbers will differ; this is not a measured result.
One Transaction, Six Stages, No Guessing
Follow a single card settlement from the moment it enters the feed to the moment it is approved. Each stage names the system that decides it and where the pipeline stops when it cannot.
Descriptor Arrives
What Happens
A card settlement lands in the feed as SQ *ACME AUTO PARTS 4471 for 412.88. At this moment the transaction has no vendor, no category, and no context. It is a string, an amount, and a date. Everything downstream exists to turn that into an accounting fact.
Transaction Record
Sample record and figures for illustration only, not client data.
The Order Is the Accuracy
Anyone can build a categorizer that consults four sources. The accuracy comes from consulting them in the right order and stopping at the first one that produces a fact. Run the model first and you will get confident answers that a purchase order on the same transaction would have contradicted.
Deterministic Document Match
A purchase order, a parts order, or a receipt that ties the bank line to a job. This is not an inference, it is a record of what was bought and why, and it outranks everything else in the pipeline.
Canonical Vendor Resolution
Resolving the descriptor to a real vendor has to happen before either of the next two steps, because both of them depend on knowing which vendor this actually is. A rule built on a raw descriptor is a rule that expires.
Historical Coding Pattern
What this vendor has been coded to before, weighted by how consistent and how recent that history is. Useful, explainable, and still weaker than a document, which is why it runs after the document match and never before.
Model-Assisted Proposal
Descriptor, amount, timing, and vendor category fed to a model only when the first three sources produced nothing. This class carries the lowest confidence, is held most often, and should never be the thing that settles a transaction on its own.
Five Transactions That Break Naive Categorization
These are not edge cases. They show up in almost every service business, and a system that mishandles them is not eighty percent right, it is quietly wrong in the places an owner is most likely to trust.
Split Transactions
One bank line covers materials for two different jobs, or a supply run covers both a job and shop stock.
The output should be a split across two classes or accounts with the amounts separated. A system that forces one account onto the whole line is wrong in a way that quietly distorts both jobs' costing.
Payment Processor Descriptors
A card payment settles as STRIPE TRANSFER or SQUARE INC. The descriptor tells you that money moved and nothing whatsoever about what was purchased.
These cannot be coded from the descriptor at any confidence. They require receipt matching or they belong in the exception queue, and pretending otherwise produces a category that is confidently wrong.
Owner Draws and Transfers
A transfer between the operating and savings account, an owner distribution, or a loan payment appears in the feed as an outflow and looks like an expense.
These are not expenses at all. Coding them to an expense account understates profit and misstates the balance sheet, so transfer and distribution detection has to pull them out of the expense queue entirely.
Annual and Prepaid Charges
A single annual software charge or insurance premium lands in one month and distorts that month's overhead by a multiple.
The correct handling is a prepaid asset with monthly amortization, not a lump into expense. The agent should flag prepaid candidates rather than code them, because the amortization schedule is a judgment call.
Sales Tax on Purchases
Where the business pays sales tax on purchases, the tax is frequently a separate account and frequently gets swept into the materials total.
Coding the gross amount to materials overstates materials cost and loses the input tax figure. The agent should separate the tax line where the document supports it and flag the transaction when it cannot.
Two Things We Will Tell You To Buy Elsewhere
Not an AP automation platform, and sometimes you should have one
If you are processing thousands of vendor documents a month, running a real procurement function with controlled spend and approval hierarchies, and paying through a platform with fraud controls, then a mature AP automation platform is the right purchase and we will say so. Those platforms earn their cost at that scale, and much of what they cost sits in payment execution. The businesses this fits are the ones where that platform is priced for a finance team that does not exist, and where the real gap is between the ledger's rules feature and something that consults the systems the ledger cannot see.
Not a replacement for your bookkeeper or your CPA
Category structure, chart of accounts design, depreciation schedules, tax positions, and the annual review all belong to a human professional who is accountable for them. This work makes their job easier by handing them a ledger where the transactions were coded from evidence and the exceptions were surfaced by name. It does not decide how your business should be accounted for, and it should not.
Where the Line Sits on Every Transaction-Adjacent Action
Straight Answers
Measure Your Real Exception Rate
In thirty minutes we will look at your actual bank feed and vendor list, count how many transactions a month go unresolved, and show you what the settled rate would look like. You keep the analysis whether or not you hire us.
