What is GL coding, when AI agents keep the books?

GL coding is the translation step in accounts payable. Every purchase arrives described in operational language – a "booth package" from an events vendor, an invoice line reading "BRKT ASSY LH", a quarterly retainer from a law firm – and must be restated in accounting language before it can post. The restatement is a code string: a general ledger account drawn from the chart of accounts, a cost center, and where relevant a project or internal order. Those few fields decide which budget absorbs the cost, how the spend rolls up in every report, and how the expense is treated for tax.

This wiki explains source-to-pay concepts for companies where AI agents carry the operational load – coding invoices, matching documents, running down discrepancies – while people keep the decisions that set policy. A standard glossary treats GL coding as a data-entry field; this page treats it as institutional knowledge an agent has to learn.

GL coding translates operational language into accounting language

GL coding exists because a business speaks two vocabularies about the same event. The supplier writes the invoice in the vocabulary of what was sold: part numbers, service descriptions, milestone names. The ledger accepts only the vocabulary of what the purchase means financially: which account, whose budget, which undertaking. Someone, or something, performs that translation on every invoice line, and the translated version is all the CFO, the auditors, and the tax authority ever see.

Where the translation happens varies by document. On purchase order invoices much of the answer travels with the order; GL coding for invoices covers the mechanics of inheriting and splitting codes across lines. On non-PO invoices – the retainers, utilities, and professional services that never had a purchase order – coding is done from scratch when the invoice arrives, so non-PO spend is where coding quality is won or lost. A code that is missing, contested, or rejected at posting time stalls the invoice as a coding and approval exception.

Each dimension of the code answers a different question

A coding block stacks dimensions, and each one exists because someone downstream asks a different question of the ledger.

1. The GL account answers "what kind of cost is this?" The chart of accounts is the company's fixed taxonomy of cost types: 641200 might be trade shows and events, 652100 software expense, 121000 machinery under construction. The account also carries the accounting treatment: an expense account hits this period's income statement, while an asset account capitalizes and depreciates the cost over years.
2. The cost center answers "whose budget absorbs it?" Cost centers map to the org chart: center 4310 means field marketing in EMEA owns the cost, sees it in monthly actuals, and answers for it at budget review.
3. The project or internal order answers "which undertaking is this for?" Routine departmental spend needs no project; a trade fair or plant expansion does, because someone wants the whole undertaking's cost across every supplier who billed into it.

In practice, that means the $18,400 booth package codes as account 641200, cost center 4310, internal order 900412 for the Hannover fair. Each dimension can be wrong independently. Right account and wrong cost center produces financial statements that are perfectly accurate while the wrong manager's budget quietly takes an $18,400 hit.

Policy covers the easy 80 percent; the rest runs on convention

Every controller maintains a chart of accounts and usually a coding policy with account definitions and capitalization thresholds. The written layer handles the recurring, obvious spend. The remainder is decided by conventions – the dialect the company's coders actually speak, which appears in no manual and often contradicts a literal reading of the one that exists.

Take software. The written policy says licenses under $5,000 are expensed to 652100, software expense. The convention sends all engineering SaaS to 652140, cloud tooling, whatever the amount, because the CFO wants cloud spend on one line she can watch. A new hire who codes an $840 monitoring subscription to 652100 has followed the manual exactly and still gotten it wrong.

Or take the patent firm's quarterly retainer. The chart offers both legal fees and professional services, and either is defensible. The house convention sends patent-prosecution work to legal fees with an R&D project code, because tax wants research-related legal costs separable for the credit. Nothing on the invoice says so.

Freight is a third case. The policy is silent. The convention codes inbound freight on raw materials into material cost, part of what the goods cost to land, and freight on everything else to its own expense account. Ask why and the honest answer is a plant controller decided it years ago and consistency has ruled since.

Conventions like these are learned by apprenticeship: a senior coder corrects a junior one until the dialect sticks. The knowledge lives in a handful of people and in years of coded history, and it leaves when they do.

Miscoding passes every check and sends the bill later

A miscoded invoice posts cleanly. The system checks that the account exists and the cost center is open, with no opinion on whether they are right. The cost arrives downstream, in four familiar forms.

Budget variance noise comes first. A $40,000 facilities recharge lands in an R&D cost center, and the R&D director spends an afternoon reconstructing a phantom overrun before anyone traces it to a coding slip. Multiply that across every manager who reviews monthly actuals and miscoding becomes a standing tax on management attention.

Category spend reports degrade next. When one MRO supplier's invoices sit scattered across five accounts, the category manager walks into a renegotiation quoting 60 percent of the real volume, and the supplier knows the true number.

Tax treatment is the expensive miss. A $32,000 machine rebuild expensed in the period, when policy says capitalize and depreciate, misstates income in both directions over the asset's life. Research-related costs coded to generic accounts fall out of the credit calculation entirely.

Audit is where a single thread gets pulled. An auditor samples sixty invoices, finds three coded against the company's own policy, and expands the sample, because a control that fails five percent of a sample stops being a control. What began as sloppy coding ends as a management letter comment.

To an agent, GL coding is a precedent-retrieval problem

The dialect turns out to be written down after all, in the one place nobody reads: the transaction history. Three years of coded invoice lines record how this supplier, this description, this plant was actually coded. The month-end reclass entries are the most instructive records, because each one says the first answer was wrong and shows the corrected one. An AI agent learns the conventions from this corpus, the way a new hire learns them from a mentor, and applies them consistently: retrieve the precedent, check it against written policy, code the line, cite the precedent in the audit trail. The approaches are compared on automated GL coding, and GL coding in complex operations covers the harder cases where precedents conflict across plants, entities, and charts of accounts.

The escalation line falls out of the same logic. Novel spend with no precedent – the company's first carbon-offset purchase, say – is a policy decision wearing an invoice's clothing. It belongs with a person, because the controller's decision becomes the precedent every future offset purchase inherits. A well-run agent brings the case with candidate treatments laid out, the controller decides once, and the dialect gains a word.

Fragment builds AI agents that code spend this way – reading your coding history and correction patterns in place across SAP, Ariba, and neighboring systems, applying established precedent autonomously, and escalating genuinely novel spend with the analysis attached. See how the workflows run or request a demo.