Exception routing: why holds land on the wrong desk, and what agents change
Exception routing is the step in accounts payable where a stalled invoice gets an owner: when an invoice fails a validation check and goes on hold, a routing rule decides which person or queue must resolve it. In most ERP and procure-to-pay systems that decision comes from a routing table – a rulebook that reads the hold code, often alongside department or dollar value, and picks a desk. How well the table guesses determines whether an exception is resolved on first touch or spends weeks being forwarded by people who each conclude it belongs to someone else.
This wiki defines source-to-pay terms for operations where AI agents do the operational work – matching invoices, pulling receipts, reading contracts – and people keep the calls that need judgment. Routing is usually documented as workflow plumbing, a diagram of queues and escalation arrows. This page treats it as a diagnostic act performed before anyone has investigated, because that is the step agents change.
Exception routing is a bet on a diagnosis
Every routing decision predicts what a case will turn out to be, and a routing table makes that prediction from the hold code alone. A hold code records which check failed in the three-way match (the line-by-line comparison of invoice, purchase order, and goods receipt): a price outside tolerance (the variance band a company accepts before requiring review), a billed quantity above the goods receipt (the warehouse's record of what physically arrived), a tax amount that will not reconcile. Which check failed is a symptom. What caused the failure is a separate question, answered nowhere on the invoice, and the two diverge constantly. Whenever they diverge, the bet loses, and the case lands on a desk that can see the symptom clearly and cannot touch the cause at all. The checks themselves and the holds they produce are covered under invoice exceptions; this page is about what happens in the moments after the hold fires.
The bet loses whenever cause and symptom diverge
Take a hold coded as a price mismatch. A purchase order covers 150 cases of packaging film at $58.80 per case; the supplier invoices 3,600 rolls at $2.45 per roll. A case holds 24 rolls, so both documents describe the same $8,820 of film, but the matching engine compares unit prices, sees $2.45 against $58.80, and fires a hold for a price variance. The routing table reads the code and assigns the pricing specialist, who pulls the contract, confirms the negotiated price is exactly what the supplier charged, and has nothing left to do. The real defect is a missing unit-of-measure conversion on the supplier's item record, which belongs to the master data team – a team the routing table cannot reach from a price code.
Or take a quantity hold. A PO orders 1,000 safety valves; the supplier ships 600 now with 400 to follow in three weeks, and invoices all 1,000 up front. The goods receipt shows 600, the system fires a quantity mismatch, and the table routes it to receiving. The receiving clerk investigates and reports, accurately, that 600 valves arrived and no more. The report resolves nothing, because the invoice is early rather than wrong. The case needs a scheduled wait until the second delivery posts, and no routing table has a rule for assigning work to three weeks from now.
The slowest version is the hold two teams can each half-see. A supplier charges 6.25% state sales tax on equipment the buyer's coding marks as exempt. The tax hold routes to AP, where the analyst believes exemption determinations belong to the tax team and forwards it. The tax team's queue view shows an invoice still marked as awaiting AP review, so they send it back. Each side's dashboard shows only its own slice, so each sees work that reads as someone else's, and the invoice ping-pongs for two weeks over a determination that takes ten minutes once one party assembles the whole picture.
Every wrong desk adds a re-triage cycle
A misroute costs far more than the forwarding click. Each new owner has to notice the case in their queue, reconstruct why it landed there, investigate far enough to rule themselves out, and guess at the next desk – a full triage cycle repeated at every stop, none of it moving the case toward resolution. The case also re-enters each successive queue at the back of the line, behind work that arrived correctly addressed.
That compounding is why re-routed cases age worst of all. Pull the oldest decile of a hold queue and forwarded cases dominate it; the routing loop is one of the main feeders of the exception aging tail. It stays invisible in standard metrics because each individual hop looks like ordinary queue time, and no single desk held the case long enough to look responsible for the total.
Agents investigate first and route second
An AI agent changes exception routing by moving the investigation ahead of the assignment. Before anyone is asked to own the case, the agent reads across the ERP, the contract repository, the receiving system, and the supplier's correspondence, and diagnoses the cause instead of trusting the code. On the film invoice it compares extended totals, spots the 24-to-1 quantity ratio, and identifies the conversion gap. On the split shipment it finds the advance shipping notice – the supplier's document announcing what is on the truck – showing the second delivery date. On the tax hold it retrieves the exemption certificate and the equipment's use code in one pass, the combined view neither team's queue offered.
Whatever the evidence supports, the agent resolves. It posts the film invoice with the conversion documented and raises the master-data correction so the mismatch never recurs; it parks the early invoice and re-matches automatically when the second goods receipt posts. Worked this way, most cases never route at all – that is the substance of autonomous exception resolution, and it removes the bulk of the traffic the routing table existed to direct.
What still routes is the residue: the genuine judgment calls. Those go out one at a time, to the one person whose input is needed, phrased as one answerable question with the workup attached – "this press is coded exempt under the manufacturing exemption; the supplier charged 6.25% sales tax; does the exemption cover this installation?" The recipient makes a call in minutes instead of opening an investigation, the handoff standard covered under exception escalation best practices. The routing table shrinks accordingly, from an org-chart-sized rulebook mapping every hold code to a queue down to a short list of decision owners: who signs off on price overrides, who rules on tax exemptions, who approves paying ahead of a receipt.
Two numbers reveal how much exception routing is re-triage
To find out whether your exception routing works, measure first-touch resolution and re-route count. First-touch resolution is the share of exceptions resolved by the first party assigned, whether that party is an analyst or an agent. Re-route count is the number of times a case changed owners before it closed. Neither appears on a standard AP dashboard, which is why routing loops persist unexamined. Together they tell you what percentage of your routing is actually re-triage: assignments that produced another guess for someone else to redo. A table that scores poorly on both is distributing triage work and calling it assignment.
Fragment builds AI agents that work holds in exactly this order – diagnosing the cause across a company's existing SAP or Ariba environment, its contracts, receiving records, and supplier emails, resolving what the evidence supports, and routing only the judgment calls, each one arriving as a single answerable question with the investigation attached. Explore the workflows Fragment agents run, or book a demo to see the routing table shrink.