Letting AI code your general ledger transactions

Nobody lists "coding transactions" as a major workload, because each decision takes two seconds. Multiply by four thousand transactions a month and it is one of the largest consumers of finance time in the business, performed under time pressure, by whoever is available.

Which is also why coding is frequently inconsistent — and inconsistency in coding quietly destroys the usefulness of every report built on top of it.

What coding automation actually does

The system proposes an account for each transaction based on what you have done before: the supplier, the words in the description, the amount, the timing, the cost centre it usually carries.

Crucially it also reports how confident it is. High confidence posts automatically. Lower confidence surfaces for a decision. That split is what makes the automation safe, and it is why a system that cannot express uncertainty is doing something less useful than it appears — see rules versus machine learning in accounting.

Where it is reliably good

Recurring supplier spend. The telco bill, the rent, the freight company. After a few instances these need no attention indefinitely.

Categories with distinctive language. Invoices mentioning cartons, pallets and stretch film are packaging. The vocabulary is a strong signal.

Anything with an upstream reference. A purchase order already carries the account and cost centre. Matching the invoice to the PO makes the coding a lookup rather than a judgement — which is why PO discipline pays back twice.

Where it goes wrong

Suppliers who sell across categories. A general hardware supplier could be repairs, capital items or stock. The invoice frequently does not say, because the distinction lives in why the purchase was made.

Anything capital versus revenue. The single most common automated coding error, and the one with the largest consequence. Whether a RM 8,000 spend is an expense or an asset depends on intent and on your capitalisation policy, and no amount of pattern-matching reliably infers it.

Costs that should be split. A single invoice covering three departments. Automation proposes one account; the correct treatment is an allocation somebody has to specify.

Anything near a period boundary. Coding and period allocation get confused. An invoice dated the 2nd for work done in the previous month is a cut-off decision, not a coding one.

Keeping control of your own analysis

Here is the risk nobody warns about.

Your chart of accounts encodes how you understand your costs. If automation is left to code everything and nobody reviews the pattern, the analysis drifts to whatever the model finds statistically easiest rather than what you find useful.

Concretely: two categories you deliberately keep separate for margin analysis start collecting each other's transactions, because the descriptions are similar. Nothing is obviously wrong. The trial balance balances. But the report you use to make pricing decisions is quietly less meaningful each month.

The defence is a periodic review of the pattern, not the transactions. Once a quarter, look at what went where in aggregate and ask whether it still reflects the distinctions you care about. That takes an hour and is almost never scheduled.

Rules where policy applies

Some coding decisions are not judgements to be learned — they are policy, and should be enforced as rules the model cannot override:

• This supplier always to this account, regardless of description
• Anything above the capitalisation threshold requires human classification
• This category always carries this cost centre
• These accounts may never be posted to automatically

The correct division: learning where the answer depends on the case, rules where the answer is mandated. Systems that only offer one of the two force you into a bad trade.

What good looks like in practice

• New suppliers surface on the first invoice, then stop needing attention
• Capital-versus-revenue calls always reach a person
• Split allocations are proposed but confirmed
• Coding accuracy is sampled periodically, not assumed
• Someone reviews the aggregate pattern quarterly against the analysis you actually use

The preparation that determines the outcome

Automated coding applied to a messy chart of accounts produces mess faster.

If you have four hundred accounts of which a hundred are used, duplicates that mean the same thing, and twelve months of transactions coded inconsistently by three people, the system will learn the ambiguity and reproduce it faithfully.

Cleaning that up first — closing dead accounts, merging duplicates, writing one line defining what belongs in each — is a day or two of work that changes the result more than the software choice does. How AI learns your chart of accounts goes into the mechanism.

Common questions

How does AI decide which account a transaction goes to?

It proposes an account based on patterns in your own history — the supplier, the wording of the description, the amount range, the timing and the cost centre usually applied — and reports a confidence level with the proposal. High-confidence proposals can post automatically while lower-confidence ones surface for a person, which is what makes the automation safe to run at volume.

What is the most common automated coding error?

Capital versus revenue. Whether a spend is an expense or an asset depends on intent and on your capitalisation policy, neither of which reliably appears in the invoice, so it is not something pattern-matching can infer. The usual safeguard is a rule requiring human classification for anything above the capitalisation threshold rather than trusting a proposal.

Can automated coding make my reports less useful over time?

Yes, and it is an under-recognised risk. If nobody reviews the aggregate pattern, categories you deliberately keep separate can start collecting each other's transactions because their descriptions are similar — nothing looks wrong and the ledger still balances, but the analysis you rely on becomes gradually less meaningful. A quarterly review of what went where in aggregate, rather than transaction by transaction, is the defence.

Should some coding decisions be hard rules rather than learned?

Yes. Anything that is policy rather than judgement should be enforced as a rule the model cannot override — a specific supplier always to a specific account, mandatory human classification above the capitalisation threshold, accounts that may never be posted to automatically. Learning is the right mechanism where the answer depends on the case, and rules are right where the answer is mandated.

Related: how AI learns your chart of accounts · data quality is the real constraint · AI and the trial balance