How AI learns your chart of accounts

Your chart of accounts is a private language. "Consumables" means something specific in your business, drawn from a distinction somebody made years ago and possibly never wrote down. No model arrives knowing it.

So how does software end up coding transactions the way your accountant would? Understanding the mechanism tells you what to expect in week one versus month three — and what you have to do for it to work at all.

It starts from your history, not from a standard

The first thing a well-built system does is read what you have already done: past transactions, the accounts they went to, the suppliers involved, the descriptions, the amounts, the timing.

From that it infers relationships. Not "office supplies go to 6200" as a written rule, but a statistical association between features of a transaction and the account it ended up in — supplier identity, words in the description, the amount's typical range, which part of the month it falls in.

This is why history is the most valuable thing you bring to an implementation, and why a business with two years of consistently coded transactions gets a usable system far faster than one starting fresh.

What it does with a supplier it has never seen

It reasons by resemblance. A new supplier whose invoice mentions cartons and pallets, at an amount consistent with your other packaging purchases, gets proposed as packaging — and, crucially, flagged as a lower-confidence proposal.

You correct it or accept it. Either way the system now has a data point tying that supplier to that treatment, and the second invoice arrives with much higher confidence.

The practical shape of this: the first invoice from each new supplier needs a glance. The rest do not.

Corrections are the training signal

Every time you change a proposed code, you are teaching. This is the part people underuse.

Two habits make a large difference in the first few months:

Correct rather than override at the last moment. Changing the code inside the workflow teaches the system. Changing it later with a manual journal fixes this month's number and teaches nothing, so the same wrong proposal comes back forever.

Be consistent about genuinely similar things. If the same category of cost is coded three ways depending on who processed it, the system learns that the correct answer is ambiguous — and will keep asking, because from its point of view it genuinely is.

Where it needs a rule instead

Learning is the wrong mechanism for some decisions, and a good system lets you say so.

Anything that must hold regardless of what history suggests should be a hard rule: a specific supplier always to a specific account, everything above an amount requiring second approval, a cost centre mandated for a category. These are policy, not pattern, and you do not want a model having opinions about them.

The division that works: models propose where judgement is involved, rules govern where policy is. More on this in rules versus machine learning in accounting.

The thing that breaks it

A chart of accounts that has grown without pruning.

The common condition: four hundred-odd accounts, of which perhaps a hundred are used regularly; several pairs that mean nearly the same thing; a few whose meaning drifted when a manager left; accounts created for a one-off situation in 2019 and never closed.

Automation applied to that will be inconsistent, and the inconsistency is not the software's fault — it is faithfully reproducing an ambiguity you already had. Manual processing hid it, because a person unconsciously resolved it each time.

Before you automate coding, it is worth doing the unglamorous work:

• Identify accounts unused in the last two years and close them
• Merge pairs that mean the same thing, and decide which survives
• Write one sentence for each account that stays, saying what belongs in it
• Check that the last twelve months are coded consistently with those sentences

That exercise takes a finance team a day or two and does more for the outcome than any feature comparison. Data quality is the real constraint goes further into why.

A realistic timeline

Week one. Proposals on familiar suppliers are good; anything unusual needs review. Expect to correct a fair amount.

Month one. Recurring spend is largely handled. The exception queue is mostly genuinely new suppliers and unusual purchases.

Month three. Coding is no longer a task anybody thinks about. What remains is a short list of things that are exceptions for good reasons.

Ongoing. Review the coding periodically — not because the system drifts, but because your business changes, and a category that made sense last year may need splitting.

Common questions

How does AI know which account a transaction belongs to?

It infers the relationship from your transaction history, associating features such as supplier, description wording, amount range and timing with the accounts you have used, then proposes the most likely account with a confidence score. It is reasoning by resemblance to what you have done before rather than applying a standard chart, which is why your own history is the most valuable input to an implementation.

How much history does it need?

Broadly, more is better and about a year of consistently coded transactions gives a strong starting point, though even a few months produces useful proposals on recurring spend. Consistency matters more than volume — twelve months coded the same way each time teaches far more than three years of transactions coded three different ways by different people.

What happens with a brand new supplier?

The system proposes a treatment by resemblance to similar transactions and marks it as lower confidence so it surfaces for review. Once you accept or correct that first invoice, subsequent invoices from the same supplier are handled with high confidence, so in practice only the first document from each new supplier needs attention.

Should I clean up my chart of accounts first?

Yes, and it is usually the single highest-return preparation step. Automation reproduces whatever ambiguity already exists, so duplicate accounts, accounts whose meaning has drifted and years of inconsistent coding will produce inconsistent automated coding — closing unused accounts, merging duplicates and writing a one-line definition for each remaining account takes a day or two and materially changes the result.

Related: data quality is the real constraint · preparing your data before automating · AI in accounting