Mostly, yes. An AI agent can code routine transactions to the right accounts at depth 3 when your chart of accounts and coding rules are written down and the supplier or merchant has a coding history. Transactions that change tax treatment, could be capital rather than expense, or cross entities are drafted and sent to a named management accountant.
What decides whether coding is safe to hand over?
Three things. The first is a clear chart. If two accounts mean nearly the same thing, the agent will split transactions between them as inconsistently as people do, and no amount of model quality fixes an ambiguous chart. Tidy it first.
The second is written coding rules: which supplier types go where, which cost centre owns which spend, and the thresholds for capitalisation. Rules that live only in an experienced clerk's head are not rules the agent can follow.
The third is a reversible window. Coding a transaction before the period closes is easy to correct. Coding that has already fed a filed tax return or a closed period is not. The agent should only code at depth 3 inside the open period.
Which transactions can the agent code, and which need review?
| Transaction type | Agent's depth | Who reviews |
|---|---|---|
| Recurring supplier with a stable coding history | 3: codes and posts within rules | Sample review by the management accountant |
| New supplier or merchant | 2: proposes a code with its reasoning | AP or management accountant confirms |
| Possible capital item above the threshold | 2: proposes capital or expense | Financial controller decides |
| Mixed tax treatment, such as part-recoverable tax | 2: proposes the split | Tax or finance lead |
| Intercompany charges | 2: proposes both sides | Group accountant |
| Anything the agent scores as uncertain | Codes to a review queue, not suspense | Named reviewer clears the queue |
The last row matters. An agent that drops uncertain items into a suspense account hides them. A review queue with an owner and an age limit keeps them visible.
An illustrative example
Take a regional services firm reviewing its company card spend at month end. One transaction is 2,400 at a hardware supplier.
The agent's history says this merchant is usually coded to repairs and maintenance. But the amount is ten times the usual, and the card holder's receipt lists a pressure washer. That could be a capital item if it is above the firm's capitalisation threshold, which it is. The agent does not guess. It proposes capital equipment, notes that the history points the other way, attaches the receipt and routes the item to the financial controller. The controller confirms capital. The agent codes it and adds it to the fixed asset additions list.
The other 300 card transactions that month follow established patterns, and the agent codes them directly. The management accountant samples 20 of them.
Where must a named approver sign off?
Wherever a coding choice changes a number someone else relies on. Capital or expense changes profit and the balance sheet. Tax coding changes what the business pays or reclaims. Intercompany coding changes what the group eliminates. Each has a named owner, and the agent's proposal goes to them with the evidence attached.
Auditors will test this split. They will want to see which transactions the agent coded alone, the rule it followed, and the reviewer's sign-off for the rest. The approach is covered in how auditors treat transactions prepared by an AI agent.
What controls make it safe?
- A locked chart. The agent cannot create accounts or cost centres. New codes are a person's decision.
- Rules in the policy library. Coding rules are versioned, so you can show which rule applied on which date.
- Confidence below a threshold goes to review. The threshold is set per account type, tighter for tax and capital.
- Sampling of depth 3 coding. A person reviews a sample of agent-coded items every period and records the result.
- Drift checks. If the agent's split between two accounts shifts sharply, someone looks at why.
The practical set-up for supplier invoices is in how to code supplier invoices to accounts and cost centres, and for cards in how to reconcile corporate card transactions. The wider finance controls sit in AI agents for finance: books you can audit.
Questions people ask
Does the agent need access to the whole ledger to code well?
It needs read access to coding history for the suppliers and accounts it handles, and the chart itself. It does not need balances, payroll or other entities' data to code a supplier invoice.
Can the agent recode transactions that people coded wrongly?
It can propose reclassification journals at depth 2. A person posts them, because recoding someone else's work in a past period is a correction, not routine coding.
What about sales-side coding?
The same approach works for revenue and accounts receivable, though revenue coding often touches recognition rules and deserves tighter review.