Requisition to Pay: The Full Process, Step by Step

Requisition to Pay, Defined

Requisition to pay (R2P) is the operational process that carries an internal purchase request all the way through to paying the supplier. It begins when an employee or budget owner raises a requisition, runs through approval, purchase order issue, receipt of goods or services, and invoice matching, and ends when the payment clears. If the procurement life cycle is the strategy, R2P is the engine room — the repeatable transaction flow that turns approved demand into settled invoices.

Most teams care about R2P for one reason: it is where money actually leaves the building, and therefore where controls either hold or fail. A tight R2P process enforces budget at the approval gate, catches pricing errors at the match, and captures early-payment discounts at settlement. A loose one leaks through off-contract buying, duplicate payments, and invoices paid without a matching receipt.

This guide breaks the flow into its component steps, clarifies the perennial R2P-versus-P2P question, and shows where automation earns its keep. For the wider strategic arc that wraps around this transactional core, start with our procurement life cycle guide, and for the closely related framing read the procure-to-pay process explainer.

Step 1 — Raise the Purchase Requisition

The flow opens with a purchase requisition: an internal request to buy, capturing what is needed, the quantity, the estimated cost, the cost center, and ideally a preferred supplier or catalog item. Crucially, a requisition is a request, not a commitment — no obligation reaches the supplier until it is approved and converted to a purchase order. That distinction is what makes the requisition the organization's first and cheapest control point.

Good requisition design steers buyers toward pre-negotiated catalogs and contracted suppliers, which is how leading teams keep spend on-contract without policing every transaction. Guided buying and intake tools — profiled across our intake-to-procure AI category — increasingly turn the requisition into a conversational front door that routes requests to the right contract automatically.

Step 2 — Route for Approval

Once submitted, the requisition is routed for approval against the organization's authority matrix — typically by spend threshold, category, and cost center. This is the step that enforces budget discipline, and its design is a balancing act: too many approval layers and the business routes around procurement out of frustration; too few and spend escapes control. The aim is risk-proportionate routing, where a low-value catalog buy clears instantly and a high-value or off-contract request gets real scrutiny.

Because approval is so central, we treat its design as a topic in its own right — see the dedicated guide to the procurement approval workflow for threshold design, delegation of authority, and how to keep approvals fast without losing control.

Step 3 — Issue the Purchase Order

An approved requisition becomes a purchase order, the formal instruction to the supplier to deliver under agreed terms. The PO carries the structured data — line items, prices, delivery instructions, cost center — that every later step depends on. PO data quality is the quiet determinant of whether downstream matching succeeds; a PO missing line items or carrying stale prices guarantees exceptions at the invoice stage.

For organizations buying at scale, PO automation converts approved requisitions to dispatched orders without manual rekeying, and our coverage of the broader source-to-pay AI category profiles the platforms that handle this end to end. The PO is then transmitted to the supplier and the system tracks it through to delivery.

Step 4 — Receive Goods or Services

When the order arrives, the receiving function records a goods receipt confirming what was actually delivered against what was ordered. For services, this is an acceptance milestone tied to the statement of work. The goods receipt is the second of the three documents that the payment control depends on, and recording it promptly and accurately is one of the highest-leverage habits in the whole flow — late or missing receipts are a leading cause of invoices stuck in exception.

Partial deliveries, substitutions, and damaged goods all surface here, and capturing them cleanly prevents disputes later. The receipt record closes the loop between the commitment (PO) and the eventual bill (invoice).

Step 5 — Match and Approve the Invoice

The supplier's invoice is matched against the purchase order and the goods receipt — the classic three-way match. When all three align on quantity, price, and description, the invoice is cleared for payment; when they diverge, the exception is routed for review. This is the single most important payment control in accounts payable, the thing standing between the organization and duplicate payments, overbilling, and paying for goods never received.

It is also the most automatable step in R2P. AI-driven matching engines clear the clean majority automatically and surface only genuine exceptions for human judgment. Our analysis of AI three-way matching examines what those systems actually deliver versus the marketing, and the invoice and AP automation category compares the platforms that own this step.

Step 6 — Pay the Supplier and Close the Loop

With a clean match, the invoice is approved and paid according to the contracted terms. Smart payment timing matters here: paying too early forgoes the use of cash, paying too late risks the relationship and any discount, and the sweet spot often captures an early-payment discount that beats the cost of capital. After payment, the transaction feeds supplier performance data — on-time delivery, invoice accuracy, dispute frequency — that informs the next buying decision.

That feedback is what connects R2P back to strategy. A supplier that consistently triggers exceptions or disputes becomes a candidate for re-sourcing; one that performs cleanly earns more wallet. To quantify what automating these steps is worth in your environment, our ROI calculator models the labor and cash-flow impact.

R2P vs P2P: Is There Really a Difference?

The honest answer is mostly no. Requisition to pay and procure to pay describe the same operational arc from request to payment, and many practitioners use the terms interchangeably. Where a distinction is drawn, R2P emphasizes the internal starting point — the requisition and its approval — while P2P is sometimes mapped from the purchase order onward. The label your ERP vendor uses matters less than ensuring the flow has a clear demand origin, a real approval gate, and a disciplined match before payment.

Both sit underneath the broader source-to-pay picture, which adds upstream sourcing and contracting. If you are mapping where one process ends and the next begins, our explainer on the source-to-pay process draws the full boundary, and the procurement life cycle guide shows how the transactional and strategic halves connect.

The KPIs That Tell You R2P Is Working

Measuring R2P keeps it honest. The metrics below are the ones most teams watch; treat the figures as typical directional ranges from our analysis of published benchmarks, not promises, and baseline against your own data.

• Requisition-to-PO cycle time: how fast an approved request becomes a dispatched order — automation can pull routine buys under a day.
• Touchless invoice rate: the share of invoices that match and pay without human intervention, the headline measure of AP automation.
• First-time match rate: invoices that pass three-way matching on the first attempt — a direct read on PO and receipt data quality.
• On-contract spend: the proportion of requisitions placed against pre-negotiated catalogs and contracts.
• Early-payment discount capture: the value of discounts taken versus available.

Best Practices for a Clean R2P Flow

The teams with the smoothest R2P do three things consistently. They push demand into guided, catalog-first requisitions so on-contract buying is the path of least resistance. They design approval routing by risk, not by reflex, so low-risk spend clears fast and scrutiny is reserved for what warrants it. And they treat data quality as a first-class concern, because clean PO and receipt data is what makes downstream matching automatic rather than manual.

Automation amplifies whichever process you already have, so fix the workflow before you tool it — automating a broken approval chain only produces faster bad decisions. When you are ready to compare platforms, our independent reviews in the source-to-pay AI category and the foundational explainers on the procurement AI blog are the place to start.

Frequently Asked Questions

What is requisition to pay?

Requisition to pay (R2P) is the operational process that runs from an internal purchase request through to paying the supplier. It covers requisition creation, approval, purchase order issue, goods or service receipt, invoice matching, and payment. R2P is the day-to-day buying engine that sits inside the wider procurement life cycle.

What is the difference between requisition to pay and procure to pay?

The two terms are often used interchangeably, but R2P emphasizes the internal starting point — the requisition and its approval — while procure-to-pay is sometimes drawn from the purchase order onward. In practice most organizations treat R2P and P2P as the same end-to-end request-to-payment flow.

What are the main steps in the requisition-to-pay process?

The core steps are: raise a purchase requisition, route it for approval, convert it to a purchase order, send the PO to the supplier, receive the goods or services, match the invoice against the PO and receipt, and release payment. Supplier and catalog setup precede the flow, and performance review follows it.

Why automate requisition to pay?

Automating R2P shortens cycle time, enforces spend controls at the approval gate, and removes manual data entry from invoice matching. The result is fewer errors, less maverick spend, captured early-payment discounts, and staff time redirected from processing to exception handling and sourcing.

What is a purchase requisition?

A purchase requisition is an internal request to buy something, submitted by a budget owner or employee for approval before any commitment is made to a supplier. It captures what is needed, the quantity, the estimated cost, and the cost center, and becomes a purchase order only after it is approved.