SAP Procure-to-Pay Process:
Complete 8-Step Guide — Every T-Code, Every Document

SAP Procure-to-Pay (P2P) is the end-to-end business process covering everything from identifying a material or service requirement through to paying the vendor — entirely within SAP. The process lives primarily in SAP MM (Materials Management) for the procurement, inventory, and invoice verification steps, and hands off to SAP FICO (Financial Accounting) for the final vendor payment step.

What makes SAP P2P powerful is the connected document chain it creates at every step. The purchase requisition number flows into the purchase order. The PO number flows into the goods receipt material document and into the MIRO invoice document. Every document references the previous one — giving procurement, finance, and auditors a complete, traceable audit trail from need identification to bank payment.

Unlike a simple invoice-and-pay workflow, SAP P2P enforces financial controls at every step: purchase requisitions require internal approval; purchase orders may require management release; goods must be formally received before an invoice can be matched; and invoices are automatically checked for price and quantity accuracy before any payment can be made. This is the 3-way match — the defining financial control of the entire P2P process.

The eight steps of SAP procure-to-pay follow a fixed sequence — each step creates a SAP document that the next step references. The flow moves from internal procurement request through to external payment, with approval gates and financial controls at key junctions.

Step 1: Create Purchase Requisition — ME51N

A Purchase Requisition (PR) is the first document in the SAP P2P chain. It is an internal request to procure a material or service — it has no legal standing with any vendor, cannot be sent externally, and does not commit any budget. The PR simply says: "we need this, by this date, at this plant."

PRs can be created in three ways: manually by the end user via ME51N; automatically by MRP when MD01N (S/4HANA MRP Live) or MD01 (ECC) runs and detects a material shortage; or from a production order or project system. MRP-generated PRs are by far the most common in manufacturing environments — the buyer converts them to POs rather than creating them. In service or indirect procurement, ME51N manual creation is more common.

A PR contains: material or short text description, quantity required, unit of measure, required delivery date, plant and storage location, account assignment category (cost centre, project, internal order), and optionally a preferred vendor or pre-selected source of supply.

Step 2: Release (Approve) the Purchase Requisition — ME54N

If a release strategy is configured (SPRO → MM → Purchasing → Purchase Requisition → Release Procedure), the PR must be formally approved before proceeding to PO conversion. Release strategies trigger on PR characteristics — typically total value, plant, or material group. A PR worth $500 might auto-approve; one worth CA$50,000 might require VP-level sign-off.

Approvers release PRs via ME54N in SAP GUI, or via the Fiori "Approve Purchase Requisitions" workflow app in S/4HANA. Once all release levels are approved, the PR status changes to "Released" and becomes available for source assignment and PO creation via ME57 or directly in ME21N.

After the PR is approved, the buyer must determine who to buy from and at what price. SAP MM handles this in two ways depending on whether a vendor relationship is already established.

When a vendor and price are known: A Purchase Info Record (ME11) or an existing Contract (ME31K) covers the material-vendor combination. The buyer uses ME57 (Assign and Process Requisitions) to assign the vendor and convert the PR directly to a PO. The price defaults automatically from the info record into ME21N — no manual price entry required.

When no vendor or price is established (RFQ process): The buyer creates a Request for Quotation in ME41, sending it to multiple vendors. Vendors respond with prices entered in ME47. The buyer runs ME49 (Price Comparison List) to see all quotes side by side and select the best. The winning quotation is converted to a purchase order; losing vendors receive rejection notices. The ME01 source list can restrict which vendors are approved for a material, and MEQ1 quota arrangements can split procurement across multiple vendors.

The Purchase Order (PO) is the binding legal commitment to the vendor — the document that says "deliver this, by this date, and we will pay you this price." Once the vendor acknowledges the PO, both parties are contractually committed. The PO is created in ME21N (Create Purchase Order — Enjoy single-screen interface) by referencing the approved PR.

ME21N handles all SAP PO types: standard PO (NB) for regular stock-based purchasing; subcontracting PO (30) where you send components to a vendor for processing; consignment PO (K) where vendor stock sits at your premises until consumed; stock transport order (UB) for plant-to-plant transfers; and service POs for professional services confirmed via service entry sheet (ML81N). Each type has different account assignment and invoice verification behaviour.

Once created, the PO may go through its own release strategy via ME29N if PO release is configured. The PO is then transmitted to the vendor via ME9F (output processing — print, email, EDI, or fax). In S/4HANA, the "Manage Purchase Orders" Fiori app (F1048A) provides an equivalent browser-based interface.

When the vendor delivers goods, the warehouse or receiving team posts a Goods Receipt (GR) in MIGO against the purchase order using movement type 101. This is one of the most important postings in the entire P2P process — it does three things simultaneously:

1. Updates physical inventory: The received quantity is added to unrestricted-use stock at the specified storage location. MMBE (Stock Overview) immediately reflects the change. 2. Creates a material document: A goods movement record is created in MATDOC (S/4HANA) or MKPF/MSEG (ECC) — the formal record of what was received, when, and from which PO. 3. Creates a financial posting: SAP debits the inventory account and credits the GR/IR clearing account — a temporary balance sheet account that holds the liability until the vendor invoice is verified in MIRO.

A partial goods receipt is possible — if the PO was for 100 units and only 60 arrive, the team posts MIGO for 60 (movement type 101). The PO shows 60 received and 40 still outstanding. MIRO can then only match against the 60 received — the 3-way match prevents invoice posting for units not yet physically in hand. When the remaining 40 arrive, a second MIGO posting closes out the PO.

Invoice verification is where the 3-way match happens — the most important financial control in the entire procure-to-pay process. The AP team posts the vendor invoice into SAP using MIRO, entering the PO number as the reference. SAP then automatically compares three data points:

The tolerances that determine "pass" vs "fail" are configured per company code in OMBR (tolerance keys). Common keys: BD (small amount differences), PP (percentage price variance per unit), DW (quantity variance). If the vendor invoices $1,020 against a PO for $1,000 and the tolerance is 2%, the invoice passes. At 3% it blocks.

When MIRO posts successfully, two things happen automatically: (1) a MM invoice document is created recording the invoice in Materials Management; (2) an FI accounting document is created — debiting the GR/IR clearing account (completing the circle from MIGO) and crediting the vendor account as an open item. In S/4HANA, MIRO posts to ACDOCA (Universal Journal) in real time, making the liability immediately visible in FI reports like FAGLL03H.

Step 7 (Conditional): Release Blocked Invoice — MRBR

If MIRO blocked an invoice, an authorised AP user reviews it in MRBR (Release Blocked Invoices). MRBR shows all blocked invoices with the specific blocking reason for each. The AP user can: release the invoice after verifying the variance is acceptable; cancel the posting via MR8M and repost at the correct amount; or hold it pending a vendor credit memo. Once MRBR releases the invoice, it becomes eligible for the F110 payment run. If MIRO posted cleanly with no block, Step 7 is skipped entirely.

Step 8: Automatic Payment Run — F110

F110 (Automatic Payment Program) is the final step in SAP P2P — it selects all eligible open vendor invoices, groups them by vendor and payment method, creates payment documents, clears the open items, and initiates bank transfers or cheque generation. F110 is typically run weekly by the finance team. For manual one-off payments, F-53 posts an outgoing payment directly to a specific vendor item.

When F110 runs for a vendor invoice, three things happen: the payment document is created in FI, the open vendor line item (created by MIRO) is cleared, and the bank account is debited. The P2P cycle is complete — the need identified in ME51N has resulted in a bank transfer to the vendor.

The 8 SAP Documents Created in P2P

All P2P T-Codes by Function

For the complete SAP MM transaction code reference — including all movement types, physical inventory, MRP, and period-end closing — see the SAP MM T-Codes: Complete ECC vs S/4HANA Guide. For the FICO/AP side of invoice processing and payment, see SAP FICO T-Codes — Accounts Payable.

The good news for anyone transitioning from ECC to S/4HANA: the P2P process is structurally identical. The same 8 steps, the same logical flow, the same financial controls. What changed is mostly underneath the hood — the database architecture — plus vendor master management. Here is the complete picture: