Quartz 4

P2P_Procure_to_Pay

3 min read

Procure to Pay (P2P)

What is this?

Procure-to-Pay (P2P) is the end-to-end business process of purchasing goods or services and paying the supplier.

It connects:

  • Procurement (MM)
  • Inventory / Operations
  • Finance (FI)

In simple terms: → Company needs something → buys it → receives it → pays for it

Why it exists?

Organizations need a controlled way to:

  • Buy from approved suppliers
  • Track what was ordered vs received
  • Ensure correct payments
  • Maintain financial accuracy

SAP enforces this through a structured process instead of ad-hoc data entry.

High-Level Flow

The P2P process follows a strict sequence:

  1. Requirement identified
  2. Purchase Order created
  3. Goods received
  4. Invoice verified
  5. Payment made

This is the core backbone of procurement in SAP S/4HANA. :contentReference[oaicite:0]{index=0}

Detailed Flow (Real System View)

1. Purchase Requisition (PR)

  • Internal request for goods/services
  • Created by business or automatically (MRP)
  • NOT sent to vendor

Purpose: → “We need something”

2. Purchase Order (PO)

  • Formal document sent to supplier
  • Contains price, quantity, delivery terms

Purpose: → “We are officially buying this”

3. Goods Receipt (GR)

  • Confirms material/service received
  • Updates inventory
  • Creates accounting impact

Purpose: → “We received what we ordered”

4. Invoice Verification (IV)

  • Vendor sends invoice
  • SAP performs 3-way match:
    • PO vs GR vs Invoice

If mismatch: → Invoice is blocked

5. Payment

  • Finance processes payment
  • Clears vendor liability

Purpose: → “We paid the supplier”

Key Concept: 3-Way Match

SAP enforces:

PO ↔ Goods Receipt ↔ Invoice

If these don’t match:

  • No payment
  • Process stops

This is one of the biggest differences from loosely controlled systems. :contentReference[oaicite:1]{index=1}

Business Objects Involved

→ Business_Partner (Supplier role)
→ Material
→ Purchase_Order
→ Invoice

Process Characteristics (Important)

  • Sequential and dependent
  • Strong validation at each step
  • Integrated across modules (MM + FI)
  • Errors propagate downstream

Translation: → If master data is wrong, payments break

In Oracle

Typical flow:

  • Purchase request / requisition
  • Purchase order
  • Receipt
  • Invoice
  • Payment

BUT:

  • Less tightly enforced
  • Matching may be flexible
  • Data often stored separately

In S/4HANA

  • Fully integrated process
  • Strict validation rules
  • Real-time accounting impact
  • Mandatory master data alignment

Mapping Impact

→ PO_Mapping
→ BP_Mapping

Key idea:

  • You are mapping process states, not just data

Validation

→ Transactional_Validation

Critical checks:

  • PO vs GR vs Invoice consistency
  • Vendor correctness
  • Quantity and price matching

Common Issues

→ Cross_System_Issues

Typical failures:

  1. Missing GR → Invoice blocked
  2. Price mismatch → Payment delayed
  3. Wrong vendor → FI errors
  4. Incorrect unit conversions
  5. Duplicate transactions

Key Takeaway

P2P is NOT: → A set of tables

It is: → A controlled lifecycle of a purchase

If you treat it like data mapping: → SAP will reject your data → Finance will hate you

Backlinks