Coding and approval exceptions: the judgment calls agents learn
Coding and approval exceptions are the two invoice holds that originate inside the buying company. A coding exception stops an invoice from posting because its general ledger account, cost center, plant, or project code is missing, wrong, or ambiguous; an approval exception stops it from paying because the person required to authorize it has left, is away, or is unclear under the company's delegation of authority – the matrix of who may approve what dollar amount. In both cases the supplier's document is usually accurate, and the stalled step is the company's own bookkeeping about where the cost belongs and who signs for it.
This wiki writes source-to-pay definitions for how the work is now divided: AI agents carry the operational load of accounts payable while people keep the judgment calls. A conventional glossary treats these two exceptions as tasks for a clerk with the chart of accounts in one window and the org chart in another; this page defines them for a queue where an agent does the lookup work and a person sees only the genuine decisions.
Coding and approval exceptions fail on the buyer's side of the paperwork
Most of the types of invoice exceptions begin as a disagreement between documents: a price contradicts the purchase order, a billed quantity exceeds the goods receipt, a tax line refuses to reconcile. Coding and approval exceptions share a different anatomy: the documents agree, the arithmetic is clean, and the invoice would sail through a three-way match – the line-by-line comparison of invoice, purchase order, and goods receipt. What failed is internal metadata: the accounting dimensions that say where the cost lands in the financial statements, or the authorization trail proving someone with the right authority accepted the spend.
That anatomy explains why both families cluster on non-PO invoices. A PO-backed invoice inherits its coding and much of its approval history from the purchase order; those decisions were made when the order was cut. A non-PO invoice for legal fees, a facilities repair, or a marketing retainer arrives carrying none of that, and someone has to supply it after the fact. The shared trait matters to an agent because everything needed to resolve these cases already sits inside the company: years of coding history, the delegation-of-authority policy, current org data. Resolution is an inside job, and the skill is reading the company's own records well.
GL coding is a set of conventions, and conventions live in history
GL coding assigns each invoice line to the dimensions accounting runs on: a general ledger account, a cost center, and where relevant a plant, project, or internal order. The chart of accounts reads like a rulebook. In daily use it behaves like a dialect. Written policy says software subscriptions belong in account 6420; every experienced coder knows the unwritten rider: marketing software goes to 6420 unless it supports an event, which sends it to 6455 with the event's project code. Plant 2100 books maintenance materials to a cost center no other plant uses. The facilities team splits any repair above $5,000 between maintenance expense and capital improvement, a ratio that traces back to a conversation with the controller two years ago.
Conventions of this kind live outside the ERP configuration, which is why coding exceptions have survived every wave of rules-based automation. They are written down in exactly one place: the coding history itself. An agent learns a company's dialect the way a careful new hire would, across a far larger sample: it reads years of coded invoices in SAP or Coupa, clusters them by supplier, line description, requester, and amount, and pays particular attention to correction patterns. An entry a controller reclassified at month-end close is the strongest signal in the dataset, because it marks the spot where the obvious answer was wrong.
In practice, take a $9,600 invoice from a software vendor with the line description "annual user conference booth package". A vendor-level rule codes it to 6420; that vendor has always meant software. The coding history shows two earlier invoices from the same vendor with event language in the description, both coded 6420 at first and reclassified to 6455 at close. The agent codes this one to 6455 with the event's project code, attaches the two precedents as rationale, and the correction that used to surface at month-end never has to happen. The automated GL coding page covers the mechanics in depth.
An approval exception is a routing question, and the answer is on file
An approval exception arises when authorization routing breaks down in practice. The named approver left the company and the workflow keeps emailing the ghost. The amount crosses a delegation-of-authority threshold and needs sign-off at a level the requester never anticipated. The budget owner is on leave with no delegate configured, so the invoice enters an out-of-office black hole where reminders fire and nothing moves. The invoice itself may be flawless the whole time it sits; the delay is administrative, and it compounds as late-payment penalties accrue, early-payment discounts expire, and the supplier starts calling.
Consider a $62,400 invoice for a consulting retainer, routed in June to a director who resigned in March. The workflow tool has retried the same dead mailbox for three weeks. An agent resolving the case works three sources. The delegation-of-authority matrix says spend above $50,000 in that cost center requires sign-off at VP level. The org data shows which manager absorbed the departed director's cost centers. The invoice history shows the same monthly retainer approved four times under an active statement of work. The agent reroutes the case to the current authority holder and sends it with the context assembled: the nature of the spend, the statement of work, the four prior approvals, and the remaining budget on the line. The approver's part shrinks to a two-minute confirmation. If the case still sits, the agent nudges on the cadence the policy allows and escalates along the same matrix it used to route.
Assembling that context is most of the value. Approvers sit on invoices because approving blind feels risky and reconstructing the background takes an hour they do not have. A request that arrives with the case already built gets answered.
Coding and approval exceptions clear fast once agents keep the record current
Coding and approval exceptions resolve at the speed of the internal record, and an agent's lasting contribution is keeping that record live. Coding stays consistent because every new invoice is measured against the full weight of precedent instead of one clerk's memory of it. Routing stays accurate because the agent checks the delegation matrix and org data at resolution time, so a reorganization surfaces in the first affected invoice and is absorbed from then on.
People keep the calls that are genuinely calls. A repair invoice that could split across two cost centers, with precedent pointing both ways, should reach the budget owners with the options laid out. A new spend category with no history needs a policy decision, since the first coding becomes the precedent every later invoice inherits. An approval is a real transfer of accountability: the agent's job ends at putting the right case in front of the right person, and the signature stays human wherever the delegation policy requires it. What agents take off the table in both families is the lookup work, which accounts for nearly all the time these invoice exceptions spend in the queue.
Fragment builds AI agents that resolve coding and approval exceptions this way, inside a company's existing SAP, Ariba, or Coupa environment – learning the coding dialect from the company's own history, routing approvals from the live delegation matrix, and leaving the judgment calls with the people who own them, with no rip and replace. See the workflows in detail or book a demo.