What is AP automation, when agents do the resolving?
AP automation is software that receives supplier invoices, extracts their data, matches them against purchase orders and goods receipts, routes approvals, and executes payment with as little manual handling as possible. The term covers a stack of technology built up over roughly three decades – capture, matching, workflow, payment – and, in its newest layer, AI agents that take on the investigative work every earlier generation left behind.
This wiki defines source-to-pay terms for companies where AI agents carry the operational load – reading documents, matching records, chasing evidence – while people keep the judgment calls. Most glossaries treat AP automation as a software category; this page tells it as a history of what actually got automated, because the history shows precisely what agents change.
Capture was the first layer of AP automation to mature
For most of the twentieth century, an invoice entered the ledger through a person's fingers. A clerk read the paper and keyed header and line data into the ERP, and data entry was the cost everyone could see, so it got attacked first. OCR – optical character recognition, software that converts a scanned or emailed invoice image into structured data – automated that reading, first with rigid templates that broke whenever a supplier redesigned its invoice, later with machine-learning models that generalize across formats. E-invoicing went further by removing the document altogether: the supplier transmits structured invoice data through a network such as Ariba, or a government clearance platform where mandates require it, and there is nothing left to read because nothing was ever on paper. The specifics of extraction and validation live at OCR invoice capture, and the anatomy of how capture sits under matching, workflow, and payment lives at the AP automation stack.
What capture automated was the reading. A perfectly extracted invoice that disagrees with its purchase order is a perfectly extracted problem, and finding out why the two documents disagree stayed a person's job.
Matching engines automated the comparison
The second generation automated the checking. Matching engines inside the ERP run three-way matching – a line-by-line comparison of the invoice against the purchase order and the goods receipt, the warehouse record confirming what physically arrived – and apply tolerances, the variance bands a company allows before requiring review. A comparison that once meant a clerk laying three documents side by side now runs in seconds across every line of every invoice, and it runs consistently: the engine never waves through a 6% price variance because it is Friday afternoon.
What matching automated was the verdict. The output is a pass or a hold code, and an engine that finds the invoice price above the PO price writes the hold code and stops, because the reason for the disagreement appears in none of the three documents it compared.
Workflow moved the invoice, and payment closed the loop
The third generation automated the movement. Workflow tools took the held invoice out of the desk folder and put it into a routed queue: the price hold goes to the buyer, the quantity hold goes to receiving, reminders fire when a case sits untouched for three days, and dashboards show aging by hold code and dollar value. Approval chains for non-PO spend – invoices with no purchase order behind them, such as legal fees or facilities work – got the same treatment. At the far end, payment runs were scheduled, remittances were generated automatically, and virtual cards – single-use card numbers issued per payment – automated the disbursement itself. The share of invoices that travel from arrival to payment with nobody touching them is the touchless rate, and touchless invoice processing covers how that number is measured and raised.
What workflow automated was the waiting room. A reminder makes a delay visible and assigns it an owner; the owner still has to do the investigation the reminder is nagging about.
The same invoice has been stuck for twenty years
To see the residue clearly, follow one held invoice through the generations. A plant orders 4,200 steel brackets on a PO priced at $4.20 each. The supplier invoices them at $4.50. In every era the cause is identical: the buyer agreed to a raw-material surcharge by email and never updated the PO, so an $18,900 invoice sits on hold over a $1,260 variance.
In 2005, the invoice arrives by post and a clerk keys it into SAP. The price mismatch surfaces at posting, the invoice is printed and clipped into a folder, and resolution happens whenever the folder gets worked and the buyer answers the phone. The elapsed time runs to weeks.
In 2015, OCR captures the invoice within minutes and the matching engine blocks it automatically with a price-variance hold. Workflow routes it to an analyst's queue and sends escalation reminders. The analyst opens the PO history, searches an inbox, emails the buyer, and waits. The elapsed time runs to days.
In 2025, the supplier submits structured data through a network, the match fails within a minute of arrival, and a dashboard shows the case aging in real time. The investigation itself is unchanged from 2005: a person finds the buyer's email, confirms the surcharge, and decides whether to post with an override or request a credit.
Every generation shortened everything around the hold, and none of them touched the work inside it: establishing why two records disagree and whether the invoice is safe to pay. That residue is the standing population of invoice exceptions, and it is the main reason AP programs plateau after a strong first year, a pattern examined at where AP automation stalls.
Agent-era AP automation includes the resolving
Historically, AP automation meant automating the flow around the work: reading the document, running the comparison, moving the case, executing the payment. The definition is now widening to include the work itself, because AI agents can carry out the investigation that lived inside the hold. Give an agent the bracket invoice and it works the case the way an analyst would: it pulls the PO history from SAP, searches the buyer's correspondence, finds the surcharge email, checks whether the supplier's contract permits raw-material adjustments, checks whether the same supplier repriced this way before, and either posts the match with a documented override or drafts the credit request, with the evidence chain attached either way. Doing that well requires context that is scattered by nature – ERP records, contract clauses, inbox threads, and the tribal knowledge an experienced analyst carries, such as which supplier always bills freight as a separate line.
This is a different capability from the rules-based automation AP has bought before. RPA scripts a fixed path through known screens, and a held invoice is by definition the case the script never anticipated; the comparison is drawn out at RPA vs agentic AI in procurement.
The dividing line is worth stating precisely. Agents take the investigation and the resolution: evidence gathering, arithmetic, precedent lookup, audit-trail assembly, and posting within policy. People keep the judgment calls: a supplier asserting a verbal agreement no record supports, an ambiguous contract clause, a variance above the sign-off threshold policy reserves for a manager. When an agent reaches one of those, it escalates with the workup already complete, so the person's contribution is the decision itself. Under the older definition, AP automation succeeded when the invoice moved fast; under this one, it succeeds when the question inside the hold gets answered.
Fragment builds AI agents for this newest layer of AP automation. They work the held invoices inside a company's existing SAP or Ariba environment, using the same emails, contracts, and receiving records an analyst would, and they escalate the genuine judgment calls with the evidence attached. Browse the source-to-pay workflows they cover or see them run on your own invoices.