What is procure-to-pay (P2P), when AI agents run the process?
Procure-to-pay (P2P) is the transactional cycle a company runs every time it buys something: a requisition requests the purchase, a purchase order commits to it, receiving confirms that the goods or services arrived, the supplier's invoice is checked against those records, and payment settles the obligation. The cycle begins when someone decides to buy and ends when the supplier has been paid and the ledger reflects it. Sourcing and contract negotiation happen upstream, inside the broader source-to-pay process.
This wiki explains procurement and AP terms for companies where AI agents carry the operational load – verifying records, chasing missing documents, resolving mismatches – while people hold the decisions that carry accountability. A vendor glossary presents P2P as a sequence of tasks assigned to teams. This page defines it as a chain of records that has to stay consistent from end to end, because that is the version an agent actually works with, and the version that explains why the process stalls where it does.
Procure-to-pay is a chain of proofs
Each step in procure-to-pay exists to create a record, and each record exists so the next step has something to verify. The requisition proves intent: someone with a budget stated a need and an approver accepted it. The purchase order proves agreement: a price, a quantity, and terms that both the buyer and the supplier committed to. The goods receipt – the posting that confirms what physically arrived – proves delivery. The three-way match, a line-by-line comparison of invoice, purchase order, and goods receipt, proves consistency: the supplier is claiming exactly what was agreed and delivered. Payment closes the loop and leaves the trail an auditor follows years later.
Every record in the chain is consumed by the step after it. An invoice cannot be verified without the purchase order, and the purchase order cannot be trusted without the approved requisition behind it. That dependency is the most useful thing to understand about P2P, so this page stays at the level of the chain. The step-by-step walk through each handoff, document by document, lives at the P2P process end to end, and three-way matching covers the verification step in detail. Where P2P stops and its parent process begins is its own question; the comparison of P2P vs S2P vs source-to-settle draws those boundaries.
The chain breaks where a record is missing, late, or wrong
A process built on records fails the way a chain fails: at a single link, with everything downstream of it stopped. In practice, that looks like this. A plant orders 600 valve actuators on PO 4500128846 in SAP at $118 each, $70,800 in total. The supplier ships in two lots. The warehouse posts a goods receipt for the first 400 units; the second lot of 200 arrives three days later during a shift change and sits received in fact but unposted in the system. The supplier, having shipped everything, invoices the full $70,800. The match runs, finds proof of delivery for only 400 units, and fails on quantity. The invoice goes on hold over $23,600 worth of parts that are already sitting in the building.
Nothing in that story involves a bad purchase. The supplier delivered, the plant needs the parts, and the price is exactly what was agreed. One record is late, so the chain cannot close. Multiply that pattern across price masters that lag contract amendments, POs cut after the work already started, units of measure that disagree between systems, and freight lines that appear on invoices but never on orders, and you get the standing queue of invoice exceptions every AP team manages. Where those queues form, and why they cluster at the handoffs between systems and teams, is mapped at P2P bottlenecks. Some purchases even enter the chain with a link absent by design: non-PO invoices for legal work or facilities services have no purchase order to match against, so their proof has to be assembled from approval chains and statements of work instead.
The cost structure of P2P follows directly from this. Creating the records is cheap and mostly automated already. The expensive work is what happens when a record fails: someone has to establish which link broke, find the evidence that repairs it, and get the chain moving again. That investigation is labor, and it lands on whoever owns the queue.
What changes when AI agents run procure-to-pay?
The chain itself keeps its shape. Requisition, order, receipt, match, and payment survive because auditors, tax authorities, and suppliers all depend on the records they produce. What changes is who keeps the records true, and how fast.
An agent verifies a record at the moment it appears rather than at the moment the match runs. The valve-actuator invoice above would be worked the hour it failed: the agent reads the hold, checks receiving history in SAP, sees a 400-unit receipt against a 600-unit shipment notice, queries the warehouse team about the unposted lot, and either gets the receipt posted or confirms a genuine short shipment. That is the same investigation a strong analyst would run, finished before the analyst would have opened the queue. Missing records get chased the day they go missing. Wrong records get flagged while the person who can fix them still remembers the transaction.
The measurable result is a higher touchless rate. Touchless invoice processing – the share of invoices that post and pay with no human touch – is the cleanest single health metric for a P2P operation, and agents raise it by repairing the chain case by case. That distinction matters, because the other common route to a better touchless number is widening tolerances, the variance bands a company accepts without review. Widened tolerances buy the appearance of efficiency by giving up control. Repaired records buy the real thing.
Approvals and the loading dock stay with people
Two links in the chain keep a person in them regardless of how capable agents become. The first is approval, because approval is accountability. When a manager approves the $70,800 commitment, the point of the click is that a named person answers for the spend, to finance and to the auditors after them. An agent can assemble everything up to that moment: confirm budget availability, check the supplier's standing, flag that the unit price runs 9% above the last three orders for the same part. The decision stays with a person because the organization needs someone to own it.
Physical receiving is the second. Somebody walks the dock, counts pallets, checks for damage, and signs. An agent can make sure that count becomes a posted goods receipt the same day instead of after a shift change, and it can reconcile the count against the packing slip and the PO. The counting itself is boots-and-clipboard work, and it anchors the entire chain, since every downstream proof depends on the receipt describing reality.
That division is the honest summary of procure-to-pay with agents in it: machines keep the records complete and current, and people put their names on intent and on reality.
Fragment builds AI agents that do the record-keeping half of that division – investigating holds, repairing the mismatches that stall procure-to-pay, and closing the chain inside the SAP or Ariba environment a company already runs, while people approve whatever needs a name on it. See how the workflows operate or request a demo.