The context problem: the wall agents cross in exception resolution

The context problem is the reason exception resolution resists automation: the facts needed to clear a held invoice are spread across systems that do not share data – the ERP, the contract repository, the receiving log, the tax engine, the email archive – and across the heads of the people who work the queue. Detection was solved decades ago; any matching engine flags a price variance. Resolution means assembling the scattered context into an explanation, and that step has defeated every generation of AP automation.

This wiki describes source-to-pay work the way AI agents now perform it – matching invoices, reading contracts, chasing evidence – while people keep the decisions that need judgment. A standard glossary files the context problem under IT integration; this page treats it as the wall an agent has to cross to close a case on its own.

Every wave of automation stopped at the same wall

Three technology generations have taken aim at exception resolution, and each stalled at the same spot. OCR and e-invoicing digitized capture; the invoices that failed validation still went to a person. ERP matching engines ran three-way match – the line-by-line check of invoice against purchase order and goods receipt, the receiving record confirming what arrived – at scale; the lines outside tolerance, the variance band a company allows before requiring review, still went to a person. RPA automated the clicks around the queue; the case itself still went to a person. Each wave raised touchless rates, the share of invoices posting untouched; the hold queue survived all three.

Every wave hit the same wall. An invoice exception exists because records disagree, and why invoice exceptions happen almost always traces to something the AP system cannot see: a price renegotiated over email, a shipment split at the dock, a clause the PO never encoded. Software living inside one database can detect the disagreement; explaining it takes context from outside.

One ordinary case needed six facts from four systems

The cleanest way to size the context problem is to walk one routine case: a fastener supplier invoices 9,000 zinc-plated hex cap screws at $2.02 each plus a $310 freight line, $18,490 in total, against a purchase order written at $1.94 with freight included. The variance is 4.1% against a 2% tolerance, and the freight line has no PO counterpart, so the invoice goes on hold. Clearing it took six facts:

1. The PO's price and terms. PO 4500612387 in SAP: $1.94 per unit, incoterms DDP – delivered duty paid, meaning freight rides inside the unit price. Lived in the ERP.
2. The current contract price. A June 1 amendment reset the item to $2.02 under an annual steel-surcharge review. Lived on page 14 of a PDF in the contract repository.
3. Proof the goods arrived. Receiving posted 9,000 pieces across two deliveries nine days apart. Lived in the plant's warehouse management system.
4. The buyer's agreement. A thread where the buyer agreed the June price could apply to open orders. Lived in the buyer's inbox.
5. The supplier's billing habit. This supplier prints freight as its own line regardless of incoterms, and the standing practice is to short-pay that line rather than dispute $310 monthly. Lived in an analyst's head.
6. The line-description dialect. The invoice reads "HXCS M8X30 ZP"; the PO line reads "hex cap screw, M8 x 30mm, zinc plated." That these name the same item also lived in an analyst's head.

That is six facts from four systems, two of them recorded nowhere at all. An integration project can wire the first four together; items five and six offer nothing to integrate.

The unwritten half is specific, load-bearing knowledge

Every AP team runs on a private layer of facts like items five and six. In practice that looks like: plant 2100 books maintenance materials against a cost-center scheme it kept from a 2019 acquisition, so a coding wrong at every other plant is correct there. A line reading "BRKT ASSY LH" means a left-hand bracket assembly, because that is how one supplier's item master abbreviates it. The controller splits capital from expense at $5,000, so a $4,800 fixture posts to expense while the $5,200 version becomes an asset – a different GL account, a different approval path, a possible coding and approval exception if the split is missed. An analyst with five years of tenure carries hundreds of these, and each one decides real dollars.

The obvious response is a runbook. Three forces keep the knowledge in heads. First, it changes: suppliers get acquired, the freight arrangement moves into the next contract revision, plant 2100 migrates its cost centers, and any document describing the old state becomes a trap. Second, nobody owns it: the freight habit spans AP and procurement, the capitalization split belongs to the controller, the plant convention to a site 400 miles away; knowledge that crosses departments has no natural author. Third, it only matters at resolution time: each fact is worthless until a case needs it, and documenting everything in advance means thousands of entries that may never fire. No team under queue pressure makes that trade, which is why the runbook never gets past page six.

Agents cross the wall with precedent, retrieval, and correction

Agentic exception resolution attacks the context problem from three directions, none of which requires writing the knowledge down first. The first is resolution history. Years of cleared exceptions – hold codes, override reasons, credit memos, short-paid lines, analyst notes – form a corpus of precedents in which the tribal knowledge is latent: every short-paid freight line and reversed plant-2100 "correction" left a record. An agent that reads the corpus inherits the pattern without anyone authoring a rule. The second is retrieval at case time: an autonomous exception resolution agent queries the ERP, the contract repository, the receiving system, and the mail archive while the case is open, the way an analyst opens four windows. The third is correction as training signal: a person reversing an agent's call creates precedent for the next hundred similar cases, so the private layer finally accumulates somewhere software can reach.

The honest caveat: an agent's first months on a queue are an apprenticeship. It will escalate cases a veteran would clear, query the freight line before it has seen the pattern enough, and misread "HXCS" until corrected – a new hire's dialect-learning curve, compressed but real. During that period exception routing still earns its keep: cases the agent cannot yet clear must land with the right person, carrying the evidence already gathered.

A rule encodes one answer; context finds the right record

The distinction from rule-based automation is worth stating precisely. A rule encodes a single answer decided in advance: if the variance is under 2%, post; if supplier 30417 bills freight, short-pay line 99. Rules work until the world shifts under them – the next contract folds freight into the unit price, and the short-pay rule now underpays a compliant supplier every month. Context is the ability to identify which record answers the case at hand: reading the current contract to see where freight belongs today, and checking whether the precedent still applies. The manual vs automated exception resolution page compares the two paths step by step; the one-line version is that context decides which side of the wall a technology sits on, and agents are the first software on the analyst's side.

Fragment builds AI agents that work the context problem directly: reading resolution history as precedent, retrieving contracts, receipts, and correspondence from the systems where they already live, and treating every correction as context for the next case – inside SAP or Ariba, with no rip and replace. See the workflows they run, or book a demo to watch an agent assemble all six facts.