Written and maintained by CASRAI Editorial Board
Last updated
Procure to pay (P2P) is the end-to-end purchasing cycle that runs from an internal request for goods or services, through approval, ordering, receiving and invoice matching, to paying the supplier. It is a process, not a software product: IBM’s own overview states that “P2P is a process, not a technology”. Its value in a lab or clinic is the document trail it leaves, from requisition to payment.
Definition and scope
Procure to pay (also called the procure-to-pay process or purchase-to-pay cycle) joins two halves of purchasing that are often handled by different people: procurement (deciding what to buy, from whom, and placing the order) and payables (confirming the order arrived and the invoice is right, then paying). IBM’s overview notes that the cycle was originally paper-based; many institutions now run it inside an ERP or finance system, but the steps are the same on paper or on screen.
For a lab, a clinic or a supply room, the cycle covers consumables, equipment and services alike. The steps below describe the cycle itself; they say nothing about prices, suppliers or what to buy.
The steps, and who owns each one
Published descriptions split the cycle into different numbers of steps. IBM’s overview lists seven; the University of Arkansas at Little Rock (UALR) procurement office lists eight, and it names who is responsible for each. The two lists describe the same journey, cut at different points.
| Stage | IBM overview (7 steps) | UALR purchasing life cycle (8 stages) | Owner at UALR |
|---|---|---|---|
| Request | Need identification; requisitioning and approval | Create and submit requisition; requisition approved by all approvers | Requestor; approvers |
| Sourcing | Sourcing | Source goods or services | Central finance |
| Order | Purchase order | Create and issue purchase order | Central finance |
| Receipt | Receiving | Create a receipt | Requestor |
| Invoice | Invoicing and matching | Create supplier invoice; match invoice to purchase order and receipt | Central finance (matching) |
| Payment | Payment | Pay supplier | Central finance |
The practical point in the UALR version is ownership: the person who asked for the goods is the one who records that they arrived. Central finance cannot match an invoice to a receipt that the requestor never created. See the guides on purchase requisitions versus purchase orders and PO numbers for the first half of the cycle.
The document trail: what each step must produce
A useful way to read P2P is as a chain of documents, each one tied to the next. Two public rules show what the chain has to carry.
Receiving report and invoice (federal contracts)
FAR 32.905 governs payment documentation for federal contracts. It says a proper invoice must include, among other items, the invoice date and invoice number, and the contract number or other authorization for the supplies delivered or services performed. It also says the receiving report or other documentation authorizing payment must meet stated minimum content requirements and that the receiving official should forward it by the 5th working day after Government acceptance or approval. A defective invoice is returned to the contractor within 7 days after receipt (shorter periods apply to meat, fish and perishable agricultural items). These are federal-contract rules, but they show why the order number on the invoice and a timely receipt matter in any version of the cycle.
| Document | Created by (UALR model) | Link to the next document | Related CASRAI page |
|---|---|---|---|
| Requisition | Requestor | Approved, then converted into an order | Requisition vs purchase order |
| Purchase order | Central finance | Its number is the authorization the invoice must cite (FAR 32.905 refers to a “contract number or other authorization”) | PO number |
| Receipt / receiving report | Requestor | Records what was actually accepted | Goods receipt note |
| Supplier invoice | Supplier (not assigned to a group on the UALR page) | Matched to the order and the receipt | Three-way match |
Where it matters for labs, clinics and grants
For work paid from federal awards, the Uniform Guidance procurement standards at 2 CFR 200.318 apply to the recipient or subrecipient. Three of its requirements describe what a P2P process has to be able to show:
- Section 200.318(a): the recipient or subrecipient “must maintain and use documented procedures for procurement transactions”.
- Section 200.318(i): the recipient or subrecipient “must maintain records sufficient to detail the history of each procurement transaction”.
- Section 200.318(c)(1): the recipient or subrecipient “must maintain written standards of conduct covering conflicts of interest”.
Put together, a lab or clinic that buys under a grant should be able to produce the full chain for any purchase: who requested it, who approved it, the order, the receipt, the invoice and the payment. A cycle that keeps these linked answers audit questions from the records alone. Related CASRAI pages cover blanket purchase orders, P-cards and standard POs, the procurement card, electronic data interchange, vendor onboarding documentation and the hospital supply chain.
Common misunderstandings
Procure to pay is not a software category
Systems automate the steps, but IBM’s overview is explicit that P2P is a process. An institution that buys with email and spreadsheets still has a procure-to-pay process; it just has a weaker trail.
The match is a control, not a legal requirement in itself
Matching the invoice to the order and receipt is how institutions check that they pay for what they ordered and received. The legal and award rules above ask for documented procedures and complete records; how an institution meets them is its own procedure.
A receipt is not the supplier’s paperwork
In the UALR model the receipt is created by the requestor inside the institution’s system. It records acceptance on the buyer’s side, which is why FAR 32.905 speaks of Government acceptance or approval.
FAQ
What is the procure to pay process?
It is the sequence of steps from identifying a need and raising a requisition, through approval, sourcing, ordering and receiving, to invoice matching and payment of the supplier.
What are the steps in procure to pay?
IBM lists seven (need, requisitioning and approval, sourcing, purchase order, receiving, invoicing and matching, payment). UALR lists eight, separating requisition creation from approval and invoice creation from matching. The table above lines them up.
Is procure to pay a software product?
No. IBM’s overview says “P2P is a process, not a technology” and that it originally evolved as a paper-based manual process, with automation added gradually.
Sources
- FAR 32.905, Payment documentation and process: acquisition.gov/far/32.905 (checked 2026-10-29).
- 2 CFR 200.318, General procurement standards: ecfr.gov, 2 CFR 200.318 (checked 2026-10-29).
- University of Arkansas at Little Rock, Purchasing life cycle: procure-to-pay requisition process: ualr.edu/procurement (checked 2026-10-29).
- IBM, Procure to pay overview: ibm.com/blog/procure-to-pay (checked 2026-10-29; used for the definition and step list only).
