In S/4HANA procure-to-pay, an invoice isn't paid because it exists — it's paid because three documents agree. Understanding that one idea is the difference between an accounts-payable team that keeps the process moving on go-live day and one that stalls at the first blocked invoice.
The three documents
- Purchase Order (PO) — what you agreed to buy, and at what price.
- Goods Receipt (GR) — what actually arrived, posted at MIGO or the receiving app.
- Invoice — what the supplier is charging you, entered at MIRO (Logistics Invoice Verification).
The match
SAP compares quantity (PO vs GR vs invoice) and price (PO vs invoice). If all three line up inside your configured tolerances, the invoice posts and flows to Finance for payment. No human intervention needed — the control simply passes.
When they don't agree
The invoice is posted but blocked for payment — not deleted, not lost. It waits. A price over tolerance, a quantity mismatch, a missing goods receipt — any of these trips the block.
This is the moment untrained teams misread. Nothing is broken. The system is doing exactly what it was configured to do: hold the payment until the discrepancy is resolved.
Releasing a blocked invoice
Someone with the right role reviews the blocked invoice and releases it at MRBR — or the underlying discrepancy is corrected. Payment only runs after the block clears. That's the control working as designed, not a system fault.
Why it matters for training
On day one, an AP clerk who has never seen a blocked invoice panics. The one who was taught that the block is normal — and knows the exact next step keeps the process moving.
That's the difference finished, role-accurate training makes: not "here's the screen," but "here's what happens, here's why, and here's exactly what you do next."