MIGO vs MIRO: The #1 Confusion New Consultants Have

If you're new to SAP MM, this is almost always the first real point of confusion — both transactions post against a purchase order, both feel procedurally similar, and both show up constantly in the same conversations. Here's the actual difference, in plain terms.

MIGO — Goods Movement

MIGO handles the physical side of receiving. When a delivery arrives at the warehouse, MIGO is used to post the goods receipt (GR) — confirming that the material actually showed up, in what quantity, and against which PO. This is the step that increases your stock quantity in the system.

MIGO isn't only for goods receipts, either — it's a general movement transaction, also used for goods issues, stock transfers, and reversals. But in the P2P cycle, its main job is the GR step.

MIRO — Invoice Verification

MIRO handles the financial side. When the vendor's invoice arrives, MIRO is where you post it against the PO and match it with the GR that MIGO already created. This is the 3-way match: PO, GR, and invoice all need to agree on quantity and price within tolerance.

MIRO doesn't touch physical stock at all — it's purely about verifying and posting the financial document that triggers payment.

Why this trips people up

Both transactions reference the same PO number, both use similar-looking entry screens, and both are usually run close together in time — so from the outside, they look like two versions of the same step. The distinction only clicks once you separate the two things the P2P cycle is actually tracking: physical quantity (MIGO's job) and financial value (MIRO's job).

A quick sequencing rule

In a standard 3-way match setup, order matters: PO → MIGO → MIRO. You generally can't post an invoice in MIRO for a quantity that was never received in MIGO — the system will either block it or flag a variance, depending on your tolerance settings. If you're debugging a stuck invoice, checking whether the GR exists at all is usually the first thing to look at.