What is autonomous exception resolution?

Autonomous exception resolution is the standard a system meets when it takes an invoice exception – an invoice that failed a validation check and went on hold – and closes the case end to end: it investigates the evidence, decides the outcome, acts on the ERP by posting the match, raising the dispute, requesting the missing document, or routing the payment, and documents the trail behind the decision. The defining condition is that no person touches the case between the hold and the close. A system that performs three of the four steps and hands the last to a person is assisting, and should be described that way.

This wiki covers source-to-pay for companies where AI agents carry the operational load and people hold the judgment calls. In most vendor decks, "autonomous" is decoration; this page pins the word down so a reader can test any product against it.

Autonomous exception resolution has four parts, and most tools sell one

The four steps deserve unpacking, because each is a separate engineering problem. Investigating means reading across the records that hold the answer: the purchase order, the goods receipt (the warehouse's record that goods arrived), the contract and its amendments, prior resolutions of the same mismatch. Deciding means reaching a defensible conclusion from that evidence – the invoice is correct, the invoice is wrong, or the case needs a person. Acting means writing to the ERP: posting a match with an override code, generating a debit memo, releasing or extending a payment block, sending the supplier a document request. Documenting means attaching the reasoning – which records were checked, what each showed, which policy permitted the action – so the resolution survives an audit two years later.

The step vendors most often skip is the third. Reading systems is safe; writing to a production SAP or Ariba environment carries consequences, so many products investigate and recommend while a person keys the actual transaction. That design can be useful. By the definition above it is manual resolution with better research support, and the manual vs automated exception resolution page walks through the difference in daily operation.

An autonomy ladder places any vendor claim on one of four rungs

Claims of autonomy become testable once you ask two questions of a specific case: whose hands touch the ERP, and what happens when nobody responds. Take a price variance – the exception raised when the invoice price disagrees with the PO price beyond tolerance, the variance band a company allows before requiring review. A corrugate supplier invoices 40,000 shipping boxes at $0.92 each against a PO written at $0.88. The 4.5% gap breaks a 2% tolerance, and a $36,800 invoice goes on hold over $1,600. The supplier is right: a contract addendum resets the unit price each July against a containerboard index, and this year's reset produced $0.92. The price variance exceptions page covers this failure mode in depth; here it is the test case for each rung.

1. Level 0 – routing. The system reads the hold code and moves the case to the right queue: price variances above $1,000 to the senior analyst, the rest to the shared inbox. A person does all four steps. If nobody responds, the case ages exactly as it would have; routing changed whose queue it ages in. Most workflow modules that ship inside ERPs operate here.
2. Level 1 – suggestion. The system investigates and drafts an answer: "Addendum 3, clause 2.1 reprices to $0.92 effective July 1; recommend override." A person confirms every case, and the person's hands are on the ERP for every posting. If nobody clicks approve, nothing posts, and the drafts expire alongside the holds they explain. Throughput stays capped by human attention, the same constraint the queue had before.
3. Level 2 – supervised resolution. The agent posts the override itself; the ERP write is the agent's, under its own service account. People review a sample of closed cases, or everything above a threshold such as $25,000, after the fact. If nobody reviews for a week, the cases are already closed; supervision shapes the agent's future behavior instead of gating each resolution. This is the first rung that changes cycle time, because closure no longer waits on a person.
4. Level 3 – autonomous resolution with escalation. The agent closes cases where the evidence supports a conclusion and escalates the rest, with the full workup attached. On the corrugate case, it verifies the addendum math, finds the identical reprice approved last July, posts the match, and files the rationale. A case where the supplier claims a verbal side agreement goes to a person carrying everything the agent assembled. If nobody responds to an escalation, only the judgment calls wait; the evidence-backed volume keeps clearing underneath.

The difference between levels 2 and 3 is where the boundary of the agent's authority lives. At level 2 it is a fixed policy set by an administrator. At level 3 the agent itself distinguishes cases it can prove from cases that require judgment, which demands the operational context – supplier quirks, plant-specific practices, cryptic line descriptions – that the context problem in exception resolution page describes.

Some decisions should stay with people on every rung

An honest definition includes its boundaries. Three classes of decision belong to humans regardless of how capable the agent is. Recovery decisions on paid duplicates: once money has left the company, choosing whether to demand repayment, offset future invoices, or absorb the loss is a supplier-relationship call. Formal supplier disputes: rejecting a supplier's position in writing changes a negotiating posture, and an agent should prepare the case file rather than sign it. Policy-mandated sign-offs: where a delegation-of-authority matrix requires a controller's approval above a threshold, the requirement exists so a named person is accountable, and automating the signature defeats it. On all three, the agent's job ends at a complete workup, and the exception escalation best practices page covers what a good handoff looks like.

Autonomous exception resolution leaves the arrival rate where it was

Autonomous exception resolution changes how fast cases close after they arrive. The rate at which they arrive is set upstream, by stale price masters, suppliers who invoice before goods ship, and POs cut after the work started. An agent working the queue touches none of those causes, so a company running one should expect a permanently fast queue rather than a shrinking one. A vendor who promises that autonomy will cut the exception rate is describing a prevention project and calling it a resolution product; the why exceptions never go to zero page works through the root causes.

In a proof of concept, count the cases nobody touched

The definition converts directly into a test. During a proof of concept, take every exception that entered hold in the window and count how many reached posted or closed with zero human events in between: no queue assignment, no draft approval, no manual keying, no ticket. ERP change logs and workflow histories make this auditable, since every posting carries a user ID and the agent's actions sit under its service account. That count, as a share of arrivals, is the system's real autonomy level. Then read a sample of its escalations and check that each arrives with the workup attached. If the vendor's headline metric is instead the acceptance rate of its recommendations, you are being shown level 1 and invited to call it level 3.

Fragment builds AI agents that operate at the top of this ladder: they investigate, decide, post, and document exceptions inside a company's existing SAP or Ariba environment, and escalate the genuine judgment calls with the evidence already assembled. See how the workflows run or request a demo and apply the zero-touch count to what you watch.