What is P2P Cycle in SAP? (12 Steps of Procure-To-Pay Process)

P2P stands for procure-to-pay. It is the complete chain of activity that starts when someone inside a company identifies a need and ends when the supplier who met that need has been paid. In SAP, that chain runs mainly through SAP MM (Materials Management), which is the reference system used throughout this guide.

You will also see the same process written as PTP, short for purchase-to-pay. Procure-to-pay and purchase-to-pay are the same cycle under two names, and SAP documentation and job descriptions use both, so a PTP cycle in SAP and a P2P cycle in SAP are not two different things to learn.

The cycle begins with requisitioning the goods or services, and closes when payment is posted against the supplier invoice.

Below: the 12 steps of the P2P cycle in SAP with the transaction code for each, what posts to the ledger along the way, what changes when you move from SAP ECC to S/4HANA, the KPIs procurement and accounts payable actually track, and the failure points specific to running P2P in SAP MM. Running a different ERP? See the dedicated guides for Oracle, NetSuite, and Infor.

Video Introduction

Steps of the P2P cycle

The P2P cycle SAP MM is taken as a reference in this post.

You can find the 12 steps of the SAP Procure-To-Pay Cycle details below.

The following infographic provides an overview of the steps involved in this procure-to-pay life cycle.

The Procure-to-Pay or P2P cycle process starts when a buyer needs some goods or services.

1. Requirement identification & purchase requisition

The first step in the p2p cycle is requirement identification. That happens whenever a shortage of raw materials, services, or other parts is needed to continue the operation.

The production department communicates with the stores’ department for the needed materials. If it is in stock, there is no need to raise the requisition.

However, if the stock is unavailable, the person responsible for this in the store’s department will create a purchase request internally and send it to the purchasing department.

The person responsible will submit the purchase request to the purchasing manager. Here accounts department does not come into the picture.

T-code for purchase requisition – ME51N

Below one is the created purchase requisition.

2. Authorizing the purchase requisition

The purchasing manager evaluates the purchase requisition and negotiates with different vendors. Here the purchase requisition can either be approved or rejected.

T-code for releasing purchase requisition – ME54N

T-code for purchase requisition display – ME53N

3. Shortlisting the vendors

Depending on the type of request, the procurement department will shortlist either a new list of vendors or the procurement department may directly approach the existing vendor for the material.

Vendor shortlisting depends on credibility, vendor rating, quality of the product or service, and pricing.

4. Taking quotations from the vendors

Here the buyer sends RFPs to all the shortlisted vendors to explain the requirements. The vendors are then asked to give their quotations.

T-code for creating the request for quotation – ME41

5. Vendor selection

The RFP response is evaluated, and the vendors negotiate terms and quotations.

The agreement will be signed for the vendor whose quotation and the buyer accepts terms are shortlisted.

6. Creation of purchase order

Once the purchase requisition is approved, the purchasing department finalizes the vendor depending on the importance and cost of the material or service and raises the purchase order.

Finally, the purchase order will be created, and the purchase manager will approve the PO and send it to the vendor with details like material description, price, quantity, payment terms, etc.

SAP supports several purchase order and agreement types: the standard PO for stock, service POs, consumption POs for items charged straight to a cost center, and stock transport orders (STO) for moving stock between plants, alongside outline agreements such as scheduling agreements and contracts. Firms also label spend as capital expenditure (capex) or operational expenditure (opex), but that is a budgeting distinction rather than a separate SAP document type.

T-code for purchase order creation – ME21N

7. Shipment notice

Once the agreement is signed, and the PO is confirmed, the vendor sends the shipment notification to the buyer. Notice informing about the goods or services that they are providing.

At this point, we are halfway through the procure-to-pay cycle. The shipment notice includes all the details, like a description of the goods and the shipment date.

8. Receiving the goods/Goods receipt

The company receives the goods from the supplier. The materials or services obtained are inspected to check the quality and quantity of the materials. Goods receipt will be raised against the PO.

The delivery team compares the PO with the shipment notice to validate if the two match. If they match, the company issues the goods receipt to the vendor.

However, if there are discrepancies, the company can contact the vendor and ask for a refund or replacement.

In this stage, the system generates two reports. One is the material document in MM, and another is the accounting document in FI.

T-code for goods receipt purchase order – MIGO

9. Recording the invoice

After the goods are received, the supplier sends an invoice for payment. Accounts payable enters this against the original purchase order, not as a standalone bill, so the system can match it automatically in the next step.

T-code for invoice verification – MIRO (Logistics Invoice Verification). MIRO is the correct code for a PO-based vendor invoice, since it ties the invoice to the purchase order and goods receipt for matching. FB60 is a separate transaction for a vendor invoice with no PO reference (for example, a utility bill), and FB70 is unrelated to this step entirely, it posts an outgoing customer invoice on the sales side, not a supplier bill.

10. Three-way match

The three-way match is the control the whole cycle is built around, and the three documents it names are the purchase order (what was agreed), the goods receipt (what actually arrived), and the supplier invoice (what is being charged). SAP runs the check automatically when the invoice is posted at MIRO, comparing quantity and price across all three.

If the three agree within the configured tolerance, the invoice posts and is available for payment. If they do not, SAP sets a payment block and the invoice waits until someone reviews and releases it. What counts as agreement is a configuration decision rather than a fixed rule, and getting it wrong in either direction is the single most common source of accounts payable workload. That is covered under invoice matching exceptions below.

A two-way match, by contrast, compares only the invoice against the purchase order and is used where there is no goods receipt to compare against, typically for services.

11. Making a payment to the supplier

Suppose the accounting department finds a match between the price, quantity, and terms and conditions within documents, it will pay the vendor (vendor payment) as per the agreed terms depending on the invoice due date.

T-code for vendor payment – F-53 (post a manual, one-off outgoing payment) or F110 (the automatic payment run, used to pay many due invoices in a single batch by company code and payment method).

Before either of those will run, the supplier record itself has to carry the right settings, which is what the screens below show rather than the payment posting. Bank details and the reconciliation account determine whether the supplier can be paid at all. Payment terms drive the due date the payment run selects on. And the check double invoice flag, visible on the company code payment screen, is the setting behind the duplicate payment gap described later: it is maintained per supplier, so a record created without it has no duplicate protection.

12. Reporting

Once the vendor receives the payment, the complete process is documented, and accounting reports are created in FI.

SAP P2P transaction codes at a glance

The whole SAP MM procure-to-pay flow comes down to a short, predictable set of transaction codes. Here they are in the order you use them, along with the document each one creates, so you can keep this as a quick reference:

Step	Transaction code	What it creates in SAP
Create purchase requisition	ME51N	Purchase requisition (table EBAN)
Release (approve) the requisition	ME54N	Released requisition
Create request for quotation	ME41	RFQ sent to vendors
Create purchase order	ME21N	Purchase order (tables EKKO and EKPO)
Release (approve) the purchase order	ME29N	Released PO sent to the vendor
Post goods receipt against the PO	MIGO	Material document plus an FI accounting document
Verify the vendor invoice	MIRO	Invoice document plus an FI accounting document
Release a blocked invoice	MRBR	Released invoice, cleared for payment
Pay the vendor	F-53 (manual) or F110 (payment run)	Payment document

Display and change variants exist for most of these: ME53N and ME23N display a requisition and a PO, and ME22N changes a PO. ME54N releases one requisition at a time, while ME55 handles the collective release when a buyer needs to approve a batch at once.

What posts to the ledger at each step

Only three of the twelve steps generate a financial accounting document, and seeing them together explains why the GR/IR account behaves the way it does at month-end.

Step	Transaction	Debit	Credit
Goods receipt	MIGO	Stock, or a consumption account where the purchase is charged straight to a cost center	GR/IR clearing
Invoice receipt	MIRO	GR/IR clearing	Vendor (accounts payable)
Payment	F-53 or F110	Vendor (accounts payable)	Bank

Read the GR/IR column downwards and the purpose of the account becomes obvious. The goods receipt credits it, the invoice receipt debits it, and when both sides carry the same quantity and value the account nets to zero for that purchase order line. GR/IR exists because goods and the invoice for them almost never arrive on the same day, and something has to hold the liability in between.

That is also what makes the GR/IR balance a useful report rather than an accounting nuisance. A line still open weeks after the goods arrived means the invoice never came, or came and failed the match. A line open in the other direction means an invoice posted against goods nobody ever receipted.

Two qualifications worth knowing. Where a material is valued at standard price, a difference between the purchase order price and the standard price does not sit in stock value, it posts to a price difference account, which is what the purchase price variance reports on. And where the purchase is consumed immediately rather than stocked, the debit at goods receipt goes to the consumption account on the purchase order account assignment instead of to inventory.

Running P2P in SAP S/4HANA: what changes from ECC

Almost every P2P walkthrough available online, including the transaction codes listed above, describes SAP ECC. That still matters in practice, because SAP has set mainstream maintenance for SAP ECC 6.0 on enhancement packages 6 to 8, and for Business Suite 7, to end on 31 December 2027, with optional extended maintenance available to the end of 2030. Anyone learning the cycle now is learning it on a platform with a published end date, so it is worth knowing which parts carry across unchanged and which do not.

The reassuring part is that the flow itself does not change. The twelve steps above are the same twelve steps, and the core transaction codes survive: ME51N, ME21N, MIGO, MIRO, F-53 and F110 all still work. Three areas do change, and they are the ones that catch people out.

Area	SAP ECC	SAP S/4HANA
Supplier master record	Vendor master, created and maintained with XK01, MK01 and FK01	Business Partner is mandatory. Those transactions redirect to transaction BP, and the object is referred to as a supplier
Goods movements	A range of specialized transactions: MB01, MB1A, MB1B, MB1C, MB31 and others	Consolidated into MIGO. The classic MB transactions are obsolete, and several refuse to run rather than redirecting
Request for quotation	ME41 through ME49	ME41 still works, but the strategic path is the Manage RFQs Fiori app

Business Partner is the change that alters how you think about a vendor. In ECC, a vendor master and a customer master were separate records, so a company that both supplied you and bought from you existed twice. S/4HANA makes Business Partner the single object, with supplier and customer as roles held on it, and Customer Vendor Integration is mandatory rather than an option you can defer.

It is worth being precise about what that does and does not fix. It removes the split between a vendor record and a customer record for the same real-world company. It does not, on its own, merge duplicate suppliers created independently in two separate systems, which is a different problem and the one described under master data quality below.

On the RFQ side, the picture is more nuanced than most summaries suggest. Secondary sources frequently state flatly that ME41 is obsolete in S/4HANA. SAP’s own knowledge base is more specific: the classic RFQ transactions can still be used, while SAP’s stated direction is the Manage RFQs Fiori app. If you are documenting a process for a team running S/4HANA today, that distinction matters, because building a procedure around a transaction that still works is very different from building one around a transaction that has been removed.

Where the P2P cycle sits in the supply chain

P2P is the inbound half of a company’s supply chain: everything from recognizing a need through to paying the supplier who met it. It sits between two processes it is regularly confused with.

• Upstream is sourcing, often packaged commercially as source-to-pay (S2P). Sourcing decides who the supplier should be and on what commercial terms; P2P executes against that decision. The request for quotation at step 4 is the seam where the two meet, which is exactly where source-to-pay platforms such as Ariba and Coupa attach.
• Downstream is order-to-cash, described below, which is the same shape of process pointed at customers rather than suppliers.

For a supply chain planner, this cycle is where a plan becomes a commitment and then becomes cash leaving the business. A material requirements planning run proposes what to buy and when, and in most SAP installations the purchase requisition at step 1 is generated directly by that run rather than typed by a person.

That connection explains something that otherwise looks like an accounts payable problem. When the material master carries the wrong lead time, unit of measure or lot size, MRP inherits it, the requisition inherits it from MRP, and the purchase order inherits it from the requisition. By the time it surfaces it looks like a purchasing error, but the defect entered the chain several steps upstream.

Procure-to-Pay vs Order-to-Cash

People searching for the P2P cycle often land on order-to-cash (O2C) content by mistake, since the two terms get used together in finance and ERP training material. They describe opposite sides of the same transaction. Procure-to-pay is what happens on the buying side: a company identifies a need, orders from a supplier, and pays that supplier. Order-to-cash is the mirror process on the selling side: a company receives an order from a customer, fulfills it, and collects payment.

In practical terms, if you work in accounts payable or purchasing, you live in the P2P cycle. If you work in sales operations, billing, or accounts receivable, you live in the O2C cycle. A single ERP instance runs both processes at once, since one company’s outbound purchase order is frequently another company’s inbound sales order.

Advantages of procure-to-pay cycle

A well-run P2P cycle in SAP pays off in a few concrete ways, not just general efficiency.

Fewer invoice exceptions and less manual matching

Because every purchase runs through a PO before the goods arrive, SAP can run the 3-way match automatically at MIRO instead of accounts payable staff checking each invoice by hand. Organizations that run tight P2P processes typically see the majority of invoices clear the match on the first attempt. The remainder is where the actual staff time goes, so this is usually the biggest real cost saving, not the process itself.

Real-time visibility instead of email chasing

Once a requisition exists in the system, anyone with access can see exactly which stage it’s at: awaiting approval, converted to a PO, goods received, invoice posted, or paid. This replaces the older pattern of purchasing staff emailing vendors or other departments to ask where an order stands, and it’s the same data both buyer and finance are looking at, so there’s no separate spreadsheet to reconcile.

Cleaner spend data for negotiating with vendors

Since every purchase is tied to a vendor and material master record, procurement can pull actual historical spend by vendor or category instead of estimating from invoices. That’s what gives a buyer real leverage in a renewal conversation: showing a supplier the exact volume and price history rather than negotiating from memory.

Audit trail built in, not bolted on

Every step, requisition, approval, PO, goods receipt, invoice, and payment, is a separate document linked back to the others. When an auditor asks why a payment was made, the full chain from original requisition to payment is already there rather than requiring someone to reconstruct it from paper files or email threads.

Procure-to-Pay Cycle KPIs to Track

You cannot tell whether a P2P process is actually working from a process diagram alone. Procurement and accounts payable teams typically track a handful of metrics to catch bottlenecks before they show up as late payments or missed early-payment discounts.

• PO cycle time: the time from purchase requisition to an approved purchase order. Long cycle times usually point to an approval bottleneck, not a procurement team problem.
• First-time match rate: the percentage of invoices that pass the 3-way match (PO, goods receipt, invoice) on the first attempt without manual intervention. Teams with a mature P2P process commonly get this well above 80 percent; a rate stuck below 50 percent signals data quality or vendor-compliance issues upstream.
• Invoice exception rate: how often an invoice does not match its PO or goods receipt and has to be routed for manual review. Every exception costs staff time, so this is one of the clearest automation ROI metrics.
• PO compliance rate (maverick spend): the share of purchases made without going through a proper PO first. High maverick spend usually means the requisition process is too slow or too rigid, so people route around it.
• Cost per invoice processed: total AP processing cost divided by invoice volume. This is the metric most often cited to justify P2P automation software, since manual processing typically costs several times more per invoice than an automated match.

What are the challenges of a procure-to-pay cycle?

Most write-ups of P2P challenges stay at the level of “communication problems” and “change management.” The real failure points in a SAP P2P cycle are more specific than that, and they show up as blocked invoices, messy month-end closes, and payments that go out twice.

Invoice matching exceptions at MIRO

The 3-way match runs against tolerance keys configured in transaction OMR6, per company code. PP covers price variance, DQ covers quantity variance, and DW blocks an invoice outright when there’s no matching goods receipt for a PO line. If a variance falls inside the configured tolerance, SAP posts it automatically and routes the difference to a price-difference account. If it doesn’t, the invoice gets a payment block and sits until someone releases it manually through MRBR.

The practical problem is tuning these tolerances correctly. Set too loosely, and a genuine pricing error slips through and posts automatically. Set too tightly, and ordinary rounding differences generate a payment block on nearly every invoice, which buries accounts payable in exceptions that have nothing to do with real risk.

The GR/IR clearing account never quite reconciles

Goods receipt and invoice receipt post to a transitional GR/IR account that should clear itself once both sides match. In practice it rarely does cleanly. Goods can arrive in one posting period and the invoice in the next, leaving an open balance sitting on the books at month-end close.

A specific and less obvious failure mode: when one clearing document covers several goods receipts and a late invoice then arrives matching only one of them, SAP has to reverse the entire clearing document to isolate that single GR, then the clearing has to be rerun on what’s left. Every late invoice after that repeats the same reversal-and-rerun cycle instead of resolving anything, which is a large part of why GR/IR is consistently one of the most time-consuming accounts to close.

Maverick spend around the PO process

SAP MM records a transaction once it’s created, but it doesn’t stop someone from buying outside the process in the first place. If getting a PO approved through the release strategy takes days, and posting a direct invoice through FB60 with no PO reference takes minutes, the incentive runs the wrong way. FB60 is a legitimate transaction for genuinely PO-less purchases like a utility bill, but it’s also the standard route by which off-contract spend enters the books without ever touching the 3-way match.

Vendor and material master data quality

Duplicate vendor master records are a known problem in landscapes running more than one SAP instance, since each system can issue its own vendor number for the same real-world supplier with no automatic cross-system dedup. That matters directly for P2P because SAP’s duplicate-invoice check runs per vendor code. If the same supplier exists under two different vendor numbers, an invoice posted against each one looks like two separate, legitimate payments to the system, not a duplicate.

On the material side, wrong units of measure, valuation class, or procurement type on the material master feeds directly into PO pricing errors and incorrect stock postings, since the PO and goods receipt both inherit whatever is set on the master record.

Release strategy misconfiguration

SAP’s release strategy for PRs and POs is a condition-based rules engine built around release groups, codes, and characteristics like purchasing org or total order value, not a flexible approval-chain builder. A release code mapped to the wrong user, or a characteristic combination that doesn’t match any defined strategy, means the document never reaches an approver’s worklist and gets no visible error. It just sits there. The common workaround, ME28 mass release, forces documents through and is useful for clearing a genuine backlog, but becomes a control bypass if it turns into a routine habit instead of a fix for the underlying configuration.

Duplicate payments slip past the standard check

SAP’s duplicate invoice check is not a blanket safety net. It’s a flag set individually on each vendor master record, so any vendor created without it enabled has no protection at all. It also only scans invoices posted through MIRO, not FB60 or FB65, so a duplicate entered through the non-PO path is invisible to it and usually only surfaces during bank reconciliation. And passing the 3-way match says nothing about whether an invoice is a duplicate. They’re two independent checks, not one guarantee covering both.

Integrating SAP P2P with Ariba or Coupa

When a company layers a separate procurement platform like SAP Ariba or Coupa on top of SAP for the requisition and sourcing side, the two systems don’t speak the same protocol. Ariba’s native format is cXML, not SAP’s own IDoc or SOAP messaging, so master data like vendors and cost centers has to pass through a translation layer to stay in sync, and mapping errors there cause the two systems to drift apart. Coupa goes further: its architecture doesn’t allow a PO to be created in SAP and loaded into Coupa. The PO has to originate in Coupa itself, which raises a real question of which system is the actual source of truth for procurement documents once both are in play.

How to deal with the challenges?

Each of the challenges above has a specific, testable fix rather than a general call to automate more.

Tune tolerance keys by material category, not globally

A single PP or DQ tolerance applied across every material category is what causes both silent overpayment and exception overload. Review OMR6 tolerance settings against actual variance patterns per category, tighter for high-value or high-risk materials, looser for low-value consumables where a manual review costs more than the variance itself.

Close the non-PO invoice gap

Since FB60 and FB65 bypass the PO process and the standard duplicate check entirely, restrict who can post through them and require a documented reason code for any non-PO invoice. This directly addresses both maverick spend and the duplicate-payment gap in one control, since most of the risk in each comes from the same transaction path.

Deduplicate the vendor master on a schedule

Run a vendor master dedup pass regularly, not just at go-live, and enable the duplicate-invoice check flag on every vendor record as standard practice rather than something set inconsistently at creation. This is what actually closes the gap where the same real-world supplier under two vendor codes defeats the built-in check.

Test release strategy against real purchasing scenarios

Before go-live and after any change to purchasing org structure, walk through actual purchase scenarios against the configured release strategy to confirm every characteristic combination resolves to a defined strategy. A PR that matches no strategy doesn’t throw an error, it just never gets released, and that failure mode is easy to miss until someone notices a stuck requisition weeks later.

Decide the source of truth before integrating a procurement platform

If Ariba or Coupa sits in front of SAP, settle up front which system owns PO creation and which one is downstream for financial posting, rather than letting that get decided implicitly by whichever integration gets built first. This avoids the master data drift that comes from both systems assuming they’re authoritative.

Conclusion

The procure-to-pay cycle is the same underlying process everywhere: identify a need, get it approved, order it, receive it, match the invoice, and pay for it. SAP MM breaks that into 12 discrete steps with its own transaction codes, but Oracle, NetSuite, and PeopleSoft run the same logic with different screens.

Where most companies actually lose money in this process is not the process design itself but the exceptions: invoices that fail the 3-way match, purchases made outside the approved PO workflow, and approvals that sit in someone’s inbox for days. That is also where most of the current investment in P2P automation is going, using AI-assisted invoice matching to flag exceptions automatically instead of routing every mismatch to a person. If your first-time match rate or PO compliance rate is weak, that is a better place to start than a full platform replacement.

[You are free to copy and distribute materials in this article.]