The P2P process end to end: one order, every record agents keep true
The P2P process, short for procure-to-pay, is the sequence a company follows from identifying a need to paying the supplier who filled it: requisition, purchase order, receiving, invoicing, payment. Each step turns a real-world event into a record, and the final invoice pays without intervention only if all of those records agree. A single routine order creates a dozen or more distinct documents between the first request and the remittance advice.
Every page in this wiki is written for companies where AI agents carry the operational load – transmitting orders, checking confirmations, matching invoices – while people decide the questions that need judgment. A glossary written for clerks lists the five steps and stops. This page follows one order through all of them and names every record it leaves behind, because those records are what an agent reads, checks, and repairs.
Take a concrete purchase: a maintenance planner at a manufacturing plant needs 20 replacement hydraulic hoses at a quoted $148.50 each. At each step of that order we will name the record created, who authors it, and the exception a defect here seeds weeks later.
The P2P process opens with two records, and the first defect can already be planted
The planner creates purchase requisition 10047321 in SAP: material number, quantity 20, unit of measure, plant, cost center 4420, need-by date. She authors it herself, and the field she is most likely to get wrong is the unit of measure. The hoses are stocked as single units, but this supplier also sells them in boxes of five; a requisition written as 20 boxes becomes an order for 100 hoses, and three weeks later a goods receipt for 100 will collide with a planner who expected 20. A quantity mismatch born in a dropdown menu.
Her manager approves the requisition against the maintenance budget, and that approval posts as its own record: a release entry with an approver ID and timestamp, the evidence auditors will ask for a year from now. Purchases that skip this step entirely resurface later as non-PO invoices, arriving with no upstream records to check against at all.
The purchase order becomes the version of truth every later check trusts
A buyer converts the requisition into purchase order 4500128816: line 10, quantity 20, $148.50 each, $2,970 total, Net 45, deliver to Plant 2200. The PO is the buyer's formal offer and, once accepted, the reference document every downstream comparison treats as correct. Its transmission is a record too: the Ariba network entry, EDI 850, or emailed PDF that establishes exactly what the supplier was told and when.
The classic defect here happens off the record. The supplier calls about a stock issue, the buyer agrees to $141.00 on substitute hoses, both sides note it in email, and nobody amends line 10. The invoice will arrive at the agreed price and fail the match anyway, because the match only reads the PO. That phone call becomes a price variance with a three-week delay fuse.
The supplier now authors records of its own, starting with the confirmation
The order confirmation – an EDI 855 or a portal acknowledgment from the supplier's customer service team – confirms items, quantities, prices, and a ship date. It is the first document in the chain written outside the buyer's walls, and the first place divergence becomes visible. If the confirmation shows $152.75 or a substituted part number and nobody compares it to the PO, the divergence rides along silently until payment time.
When the order ships, the supplier's warehouse issues an advance shipping notice (ASN, typically an EDI 856): carton contents, carrier, tracking number, expected arrival. Suppose it says 18 hoses shipped and 2 backordered. Read, that is useful warning; unread, the dock expects 20 and the disagreement starts when the truck arrives.
Receiving converts a physical delivery into the buyer's own evidence
The driver hands over a delivery note, the supplier's record of what left the warehouse. The receiving clerk then posts the goods receipt – the buyer's own record that goods arrived, and one of the three documents the match will compare. In SAP that is a movement type 101 posting against PO line 10, creating goods receipt document 5000456712 for quantity 18.
Two defects live at this dock. The clerk can key 20 because the carton label says 20, leaving a two-hose gap between record and reality that surfaces at the next cycle count. Or a busy dock posts the receipt three days late, so the invoice arrives before any receipt exists and a correct invoice stalls unpaid. Both patterns are covered under quantity and receipt mismatches; both are authored in receiving and billed, in effect, to accounts payable.
The three-way match is where the P2P process grades its own records
The supplier's billing team issues invoice INV-88231 for 18 hoses at $148.50, $2,673.00. Capture creates the next record: the invoice as OCR, EDI 810, or portal entry renders it in the buyer's system. Capture is authorship too, and a misread line item or a freight charge keyed as product is a defect contributed by software.
Now every earlier record gets tested at once. Three-way matching compares invoice, PO, and goods receipt line by line, within tolerance – the variance band the company allows before requiring review. If the chain is clean, the invoice posts and pays untouched, which AP teams call touchless processing, and the posting itself creates an accounting document with GL lines. Every defect walked above surfaces here instead: the unamended phone price as a price variance, the unit-of-measure error as a quantity mismatch, the late dock posting as a missing receipt. Each failure becomes an invoice exception, a hold that inherits a defect some other step authored weeks earlier.
Payment and remittance are records too, and defects here land on the supplier
The approved invoice enters a payment run, which produces a payment proposal, a payment document, and a bank file. The last record in the chain is the remittance advice, authored by the buyer's AP team, telling the supplier which invoices the payment covers. Skip it and the supplier's cash application team cannot tie $2,673.00 to INV-88231, the account shows past due, dunning starts, and the supplier may re-bill, seeding a duplicate invoice next cycle.
An agent treats the chain as checkpoints and repairs it in flight
Count the inventory for one order: requisition, approval record, purchase order, transmission log, order confirmation, ASN, delivery note, goods receipt, invoice, capture record, match result, accounting document, payment document, remittance advice. Fourteen records, five or six authors, two companies. Every handoff between them is a comparison that can run the moment the later record appears. An agent checks the confirmation against the PO on day one and catches $152.75 before anything ships. It reads the ASN before the truck arrives, so receiving expects 18 and posts 18. It flags the unamended line 10 while the buyer's phone call is still fresh enough to fix with one message.
A matching engine runs a single check at the end of the chain and files the failures. An agent monitors the chain step by step and repairs defects at the step that authored them, where the fix is cheapest. The why invoice exceptions happen page traces causes backward from the exception queue; the forward walk shows the same defects at the moment of birth, weeks before they cost anything. People stay in the loop for the genuine judgment calls, such as whether the substitute hoses are acceptable and whether the phone price stands.
Fragment builds AI agents that watch this record chain inside the SAP and Ariba environments that already run it, verifying each handoff as it happens and resolving the exceptions that slip through to the match, with no rip and replace. See how the workflows run or request a demo.