SAP Concepts: Procure-to-Pay: How MM Hands Off to FI (GR/IR, 3-Way Match, F110)

Every company spends money. And every company needs software that can answer two questions: what did we buy, and is it safe to pay the vendor? That's the entire point of the Procure-to-Pay process, or P2P, which in SAP is run by two tightly-coupled modules: Materials Management (MM) and Financial Accounting (FI).

This is the fourth episode of our SAP Concepts series, and we're going to walk through exactly how a purchase flows from the moment someone says "we need to buy something" through to the moment a bank transfer clears and the vendor's invoice is closed. Along the way you'll see why the so-called three-way match is the single most important control in any ERP's procurement process, and why it was invented.

The flow, from a distance

At the conceptual level, P2P in SAP has five steps.

1. Purchase requisition — someone inside the business says "we need this"
2. Purchase order — procurement converts that need into a formal commitment to a vendor
3. Goods receipt — the vendor delivers, and the warehouse records the arrival
4. Invoice verification — the vendor sends their bill, and the system checks it
5. Payment — finance clears the liability by transferring funds

MM drives the first four steps. FI is mostly passive until payment, but it receives postings at every stage. That's the characteristic rhythm of the MM-to-FI relationship: MM acts, FI records.

Let's walk through each step with the postings.

Step one: the purchase requisition

It starts inside the business. A production planner notices that stock of a raw material is running low. A department head wants to buy new laptops. A maintenance team identifies a replacement part they need.

They create a purchase requisition in MM. It's an internal request — not yet a commitment to any vendor, just a documented "we need this, approximately this much, by approximately this date". Purchase requisitions go through whatever approval workflow the company has configured. In a small firm that might be automatic. In a large firm it might take three approvers and several days.

No FI posting happens at this stage. A requisition is just a request — it doesn't obligate the company to anything yet.

Step two: the purchase order

Once the requisition is approved, someone in procurement — or the system itself, if the requisition is simple enough — converts it into a purchase order. This is the formal legal commitment to the vendor: we will buy these items, at these prices, and expect delivery by this date.

The PO has a vendor master reference, a list of line items with quantities and prices, agreed delivery terms, and payment terms (net 30, net 60, etc.).

Again, still no FI posting. The PO obligates the company, but in SAP terms the obligation is recorded as a statistical commitment — visible in reports for budget monitoring, but not yet a financial transaction in the general ledger.

Step three: the goods receipt

This is where it gets interesting. The vendor ships the goods, and they arrive at the warehouse. A clerk scans or enters the arriving items against the PO number — this is a goods receipt, and in SAP it uses movement type 101 (if you've heard someone say "we need to post a 101", this is what they mean).

Two things happen automatically at goods receipt:

MM increases inventory. Stock of the received material goes up by the quantity delivered, at the value dictated by the PO price (or the material's standard cost, depending on configuration).

FI creates a journal entry. This is the first financial posting in the process, and it's worth understanding in detail:

Dr  Inventory account                 €1,000
    Cr  GR/IR clearing account            €1,000

The inventory account is debited for the value of the goods (they arrived, so inventory is worth more). The GR/IR clearing account — "Goods Receipt / Invoice Receipt" — is credited for the same amount. GR/IR is an intermediate holding account: it represents the fact that we've received goods but haven't yet verified an invoice for them. We owe money to someone, but until the invoice arrives, we can't fully book it as Accounts Payable.

This intermediate account exists specifically because the goods often arrive before the invoice does, or vice versa. GR/IR is the accounting bookkeeping entry that says "we're in the middle of a purchase; let's park the value here until both sides reconcile."

Step four: the invoice verification (and the three-way match)

Eventually the vendor sends their invoice — maybe the same day as delivery, maybe a few weeks later. When the invoice arrives, procurement posts an invoice receipt in MM, referencing the original PO.

And this is where SAP does something genuinely powerful: the three-way match.

Before payment goes anywhere, the system checks that three things agree:

1. The PO — what we ordered (quantity and price)
2. The goods receipt — what actually arrived
3. The vendor's invoice — what they're billing us for

If all three agree, the invoice is released for payment. If they disagree — the vendor shipped fewer than ordered, or billed at a higher price, or the goods receipt is missing — the invoice is blocked, and a human has to investigate before payment can go out.

The three-way match is the single most important control in P2P. It's the reason companies don't overpay vendors, don't pay for goods they didn't receive, and don't get defrauded by invoice schemes. A huge amount of SAP's reputation for finance-grade rigour comes down to this single control.

When the invoice is verified, FI posts:

Dr  GR/IR clearing account            €1,000
    Cr  Accounts Payable — Vendor X       €1,000

Notice what happened. GR/IR — which was credited at goods receipt — is now debited, clearing that intermediate account. And Accounts Payable is credited: we now formally owe the vendor. The inventory value (from step three) stays put; we still have the goods.

Step five: payment

Finally, payment. Finance initiates a payment run — typically weekly or bi-weekly — and pays all verified invoices that are due. When the payment executes, FI posts:

Dr  Accounts Payable — Vendor X       €1,000
    Cr  Bank account                      €1,000

AP is cleared. Cash goes down. The cycle is complete.

If you trace the whole thing, here's what happened. We received €1,000 of goods. Inventory went up €1,000. We parked a €1,000 liability in GR/IR until the invoice came. The invoice cleared GR/IR and created €1,000 of AP. Payment cleared AP and reduced Cash. Net effect: inventory up €1,000, cash down €1,000, no unexplained intermediate balances.

That's the elegance of the GR/IR mechanic. Every purchase can be at any stage of completion, and the accounting always balances, because the intermediate state is explicitly modelled.

Why this matters

P2P is the single most-run process in most companies — a global enterprise might process tens of thousands of POs a month. If any step in the flow breaks, the downstream effects are immediate: invoices stuck in GR/IR clearing, AP balances that don't match what the vendor says is owed, goods that arrived but can't be used because they're not yet in stock.

Every SAP professional has spent time troubleshooting P2P edge cases. The common ones:

• GR/IR imbalances: a goods receipt was posted but no invoice ever arrived (or vice versa), leaving balances sitting in GR/IR for months. Year-end cleanup is a ritual.
• Blocked invoices from three-way match: the invoice doesn't agree with the PO or the GR. Requires human review — usually a price disagreement with the vendor, or a partial delivery that still needs to be fully received.
• Duplicate invoices: the vendor billed twice. SAP has controls to prevent this but configuration matters.
• Vendor master issues: wrong bank account, expired tax certificate, closed vendor — all common reasons payments fail.

The P2P process is stable and well-understood after five decades of ERP evolution, but it's also the process where most of the day-to-day operational work happens. A procurement-focused SAP consultant will spend the majority of their time in MM and the integration points with FI.

What's next

That's P2P. Purchase requisition to purchase order, goods receipt with its GR/IR bookkeeping, invoice verification through the three-way match, and finally payment. MM drives each step; FI records the financial consequence; and the Universal Journal (from episode three) captures every posting in one place.

Episode five is the mirror image: Order-to-Cash. Where MM is about buying, SD is about selling. Same structural shape — a process that walks across modules, ends in a finance posting, and has its own set of controls. See you there.