Automated coding does not fail randomly. It fails in a handful of recognizable patterns, and each one shows up as a particular distortion in your reports. Once you know the shapes, you can check for them in a few minutes a month.
This matters because the errors are confident. A miscoded transaction does not look uncertain in a report. It looks like a fact.
It is consistent before it is correct
The core behavior to understand: the system matches new transactions against old ones. If the old ones were coded wrongly, the new ones inherit the error, faithfully, every month.
A human doing the same job wrongly gets bored and varies. The variation is annoying but it is visible. Automation applies the same wrong answer with perfect regularity, which produces a clean trend line that happens to be false. Clean trends are exactly what nobody questions.
A single miscoding is a small problem. A miscoding rule is a reporting problem that compounds quietly for as long as nobody looks.
The patterns, and how each one looks
| What goes wrong | How it shows up |
|---|---|
| Vendor who sells two different things | One expense category creeps up while another flatlines |
| Cost split across jobs, posted whole | One project looks unprofitable, its neighbor looks excellent |
| Deposit treated as revenue | A strong month followed by an unexplained weak one |
| Refund coded as a new expense | Both revenue and costs inflate; margin percentage drifts down |
| Owner spending coded to the business | Margin erodes slowly with no operational cause |
| Transfer counted as income | Revenue that the bank balance does not support |
Every row is a real pattern rather than a hypothetical. The last one is worth dwelling on, because moving your own money between accounts can read as income twice if both sides are coded independently, and it inflates the single number most people check first.
The timing problem
Cutoff is where automation is weakest, and it is invisible in any single month.
Whether a cost belongs to the period it was paid in or the period it was incurred in depends on what was agreed, which lives in a contract or in somebody's memory of a conversation. The transaction description carries none of that. So costs land in whichever month the payment cleared.
The effect is that each month looks plausible on its own while the comparison between them is noise. You conclude something changed in the business when the only thing that changed was when an invoice got paid. Decisions made on that comparison are made on nothing.
Checks that actually catch these
None of these take long, and they catch most of the list above.
- Scan the biggest movers, not the biggest balances. Any account that moved sharply against its own recent history deserves one look. The size of the account matters less than the size of the change.
- Read the top twenty transactions by value every month. Large and wrong is the combination that hurts. Twenty is usually enough to find it.
- Check revenue against cash collected. They should not match, but they should move together over a quarter. Persistent divergence means revenue is being recognized wrongly or transfers are being counted.
- Look at your five biggest vendors by category. A vendor appearing in three categories is either legitimately diverse or coded inconsistently, and it takes a minute to tell which.
- Review every new vendor's first entry. The first coding becomes the rule. Fixing it once is cheap; fixing it after twelve repetitions is not.
What this is not
None of this is an argument for coding transactions by hand. Automation is better than a person at the repetitive majority, and the consistency that propagates errors is the same property that makes it reliable when the rule is right.
The point is narrower: the output needs a reader. Somebody has to look at the result with enough context to notice that a category moved for no reason anyone can name. That is a short task when it happens monthly, and an expensive excavation when it happens annually because a lender asked a question.