The Procure-to-Pay Cycle in SAP MM, Step by Step

Procure-to-Pay (P2P) is the single most important process to understand in SAP MM — almost every t-code, config setting, and troubleshooting scenario you'll encounter connects back to one stage of this cycle. Once you can trace a document through all six stages, the rest of the module becomes a lot easier to reason about.

1. Purchase Requisition (PR) — ME51N

A PR is an internal request — "we need this material" — created either manually by a requester or automatically by MRP (Material Requirements Planning) when stock drops below a threshold. It has no external visibility yet; nothing has been sent to a vendor.

2. Request for Quotation (RFQ) — ME41

Optional but common when sourcing from multiple vendors. An RFQ goes out to one or more vendors asking for pricing, and their responses are recorded and compared before a PO is created. Skip this stage entirely if you already have a fixed contract or info record with the vendor.

3. Purchase Order (PO) — ME21N

This is the binding document sent to the vendor — quantity, price, delivery date, and payment terms are all locked in here. A PO can be created directly, or converted from an approved PR. This is also where a release strategy (approval workflow) typically kicks in for POs above a certain value.

4. Goods Receipt (GR) — MIGO

When the material physically arrives, the warehouse confirms receipt against the PO. This is the moment stock actually increases in the system, and it triggers an accounting entry — this is why GR is one of the most-watched steps for inventory accuracy.

5. Invoice Receipt (IR) — MIRO

The vendor's invoice arrives and gets matched against both the PO and the GR — this is the 3-way match (PO, GR, invoice all need to agree on quantity and price). If they don't align within tolerance, the invoice is blocked for payment.

6. Payment

Once the invoice clears the 3-way match, it moves into Finance (FI) for payment processing. MM's job in the cycle ends here — payment execution itself is an FI transaction, not MM.

Where this cycle typically breaks

• PR to PO: missing or incorrect release strategy configuration blocks approval silently
• PO to GR: quantity or delivery tolerance mismatches trigger warnings that get ignored
• GR to IR: price or quantity variance beyond tolerance blocks the invoice — the most common "why won't this invoice post" ticket

If you only remember one thing from this cycle: every document carries forward references to the one before it. A PO references its PR, a GR references its PO, an IR references both the PO and GR. When something's stuck, trace it backward one document at a time rather than guessing.