Automated GL coding: rules, models, and agents compared

Automated GL coding is software assigning the general ledger account, cost center, and other accounting dimensions to invoice lines without a person keying each code. Three generations run in production today: deterministic rule tables, machine-learning classifiers that suggest a code for a person to confirm, and AI agents that code from precedent and post within a confidence policy. The generations differ most in what happens when the system is unsure.

This wiki covers source-to-pay for a world in which AI agents carry the operational load and people keep the judgment calls. Vendor glossaries present coding automation as one feature with an accuracy percentage attached; this page separates the three generations, describes how each fails, and explains how to measure them without fooling yourself. GL coding itself, the classification of company spend into the chart of accounts, has its own GL coding page, and the line-level mechanics of coding a single invoice live in GL coding for invoices.

Rule tables are predictable, auditable, and decaying

The first generation of automated GL coding is a deterministic rule table: vendor defaults (every invoice from this supplier posts to this account), keyword maps (any line containing "license" goes to software), and requester defaults (anything bought by facilities lands in repairs and maintenance). The strength is total predictability: an auditor can read the table and reproduce every outcome.

The weakness is decay. Every reorg renames cost centers the rules still point at. Every new expense category ships with zero rules. Every new supplier arrives unmapped. The mappings that do exist go stale silently, because writing a rule takes a minute while retiring one requires noticing it has gone wrong, and nobody owns the noticing.

Take a rule written three years ago: Meridian Systems sells software subscriptions, so every Meridian invoice posts to account 6410, software licenses. Meridian has since added an implementation-training practice. A $14,200 invoice for a three-day workshop arrives, matches the vendor rule, and posts to 6410 untouched. The software budget owner sees a spike with no new contract behind it, and training spend is invisible in every category report. The rule fired exactly as written; the vendor changed underneath it.

Models produce suggestions, and a person still touches every line

The second generation trains a machine-learning classifier on years of historically coded invoices. For each new line it produces a suggested code and a confidence score, and a person confirms or corrects the suggestion before posting. On high-volume, repetitive spend this beats any rule table, because the model picks up patterns nobody wrote down, like a supplier whose "per diem" lines always land in travel.

Two weaknesses follow from the design. The first is novel spend. A first-time supplier, a new project, or a category the company has never bought has no history to learn from, so the model guesses from surface features. Its errors are confident-looking; a wrong suggestion at 91% is indistinguishable on screen from a right one. The second weakness is operational: because the model only suggests, the workflow still routes every line through a human click. The labor changed shape, from keying codes to reviewing suggestions, and at a few hundred lines a day reviewing collapses into clicking accept. That collapse matters for measurement, below.

Agents code with the precedent attached

The third generation, an AI agent, codes the way an experienced coder does: from precedent, with the evidence shown. Instead of emitting a bare code and a score, the agent attaches its basis – here are the three prior invoices this coding follows, and here is the correction that settled the fourth. It also reads context a classifier never sees: the contract behind the invoice, the PO line text, the requester's department. In practice that means the mixed Meridian invoice splits correctly. The agent reads "Q3 admin workshop, 12 seats" on line two, notes the requester sits in HR, finds two prior training invoices coded to 6530, and codes the line there with both cited, while the subscription lines stay in 6410.

An agent also behaves differently at the edges. It posts autonomously only inside a confidence policy that finance sets, and when it hits genuine novelty it routes the case as a policy question instead of producing a plausible guess. Designing that policy is the next two sections. Coding across multiple entities, charts of accounts, and shared-service structures adds a further layer, covered in GL coding in complex operations.

How do you measure automated GL coding accuracy honestly?

One metric survives scrutiny: the correction rate at month-end close. Count the reclassification journals – the entries accountants post to move an expense from the account it hit to the account it belonged in – and trace each one back to the originally coded document. If 40,000 lines posted in a quarter and 220 reclasses trace back to automated codings, the honest error rate starts at those 220, plus whatever miscodings nobody caught.

Everything else commonly reported is softer. Acceptance rate measures deference: a reviewer confirming 96% of suggestions under volume pressure tells you how often people click accept, and says nothing about whether the codes were right. An unaudited "99% accuracy" claim usually counts every untouched line as correct, so a miscoded line nobody re-examined scores as a success. The Meridian workshop invoice was "100% accurate" by that arithmetic for as long as nobody looked.

At 98% the agent posts; at 80% it asks one question

A confidence policy is a small table that finance owns, and three rows do most of the work. At 98% with consistent precedent – the same supplier and spend type coded the same way across a run of prior invoices – the agent posts and logs its basis. Asking a person to confirm the four-hundredth identical case buys no accuracy and spends a reviewer.

Around 80%, the precedent is mixed or the invoice is unusual, and the right escalation is a one-question ask sent to the budget owner: "Meridian invoice 4471, line 2 – is the 12-seat workshop training (6530) or part of the software rollout project (capitalizable)?" One question, two options, ten seconds to answer, and the answer both posts the line and becomes precedent. The ask goes to the budget owner because the budget owner knows what the spend was for; an AP reviewer would have to go ask them anyway.

With no precedent at all, the agent has found a policy gap: the company is buying something it has never classified. That decision goes to the controller once, and the answer covers every future instance. Lines that stall in these bands surface as coding and approval exceptions; a well-designed policy keeps that queue short and genuinely novel.

Accuracy compounds, so judge the curve

The property that separates the generations shows up over time. A rule table is at its best the day it is written and decays from there. A classifier is as good as its last training run and drifts between retrains. An agent improves in production, because every correction and every answered question joins the precedent base it codes from: the Meridian correction in March means every Meridian training invoice from April onward codes itself. Measured by month-end correction rate, the first generation's curve slopes up, the second's holds flat between retrains, and the third's slopes down. A spec-sheet accuracy number describes one point on one of those curves; the slope is what a controller is actually buying.

Fragment builds AI agents that do GL coding the third way – coding from your own precedent inside SAP or Ariba, posting within a confidence policy your finance team sets, and escalating novelty as a single question to the budget owner, with every answer compounding into next month's accuracy. See how the workflows run or request a demo.