The P2P process end to end
The procure-to-pay process is five steps: requisition, purchase order, receiving, invoice, payment. Each step turns a real-world event into a record, and each handoff between steps either keeps those records aligned or quietly lets them drift. The drift is what accounts payable later meets as exceptions.
Walking the steps in order shows where the process protects itself and where it leaks.
A requisition turns a need into a record
Someone needs a thing, and the requisition captures what, how much, for which cost center, with what approval. Skipped requisitions become non-PO invoices later, arriving with no promises attached. Discipline here is cheap prevention.
The purchase order is the contract the match trusts
The approved requisition becomes a purchase order: the formal statement of items, quantities, prices, and terms. Every downstream check treats the order as truth, which is why an order that goes stale after a renegotiation manufactures price variances from perfectly correct invoices. Maintain orders like the reference documents they are.
Receiving proves delivery, and late receipts stall payment
The goods receipt is the buyer's own evidence that something arrived. Post it late or skip it and the match believes nothing came, stopping correct invoices cold, the pattern covered in quantity and receipt mismatches. Receiving discipline is an accounts payable metric wearing a warehouse badge.
Invoice capture feeds the match
The supplier's invoice arrives by portal, EDI, email, or paper, gets captured into the system, and meets three-way matching. Capture quality decides whether the match runs on real data. From here, the invoice either flows through untouched or joins the exception queue.
Payment closes the loop, and the data should improve the next cycle
Approved invoices go to the payment run, discounts get taken or missed, and the cycle ends. The records the cycle leaves behind are the context the next cycle needs: pricing history, supplier behavior, coding precedent. A P2P process that resolves its exceptions autonomously compounds that context instead of burying it in closed tickets.
Fragment reads the records every step leaves behind and clears the exceptions the handoffs create. See how it works or request a demo.
