MIGO — Post goods movements

MIGO records what physically happened to stock. Whether goods arrive from a supplier, are issued to a cost centre or an order, move between storage locations, or change from blocked to unrestricted, the movement is entered here and results in a material document. For valuated material the posting also produces an accounting document, so inventory value and the offsetting account move at the same moment. That dual effect is why goods movements are audited so closely: a movement posted against the wrong reference or the wrong movement type is both a stock error and a financial error.

In procure-to-pay the goods receipt against a purchase order is the middle of the three-way match, and it is what makes an invoice postable in a goods-receipt-based invoice verification design. In production it records component issues and the receipt of finished goods. Warehouses running warehouse management or EWM handle physical movements in their own documents, so in those designs this transaction is used for the ERP-side postings rather than for picking work. Support teams also use it for corrections, reversals and stock-type changes after a quality decision.

You select the action, such as goods receipt or transfer posting, and the reference, such as a purchase order or a material document, then let the system propose items and quantities. The movement type carries most of the behaviour: it decides the direction of the movement, the stock type affected and how the posting is valuated. Enter the plant and storage location, batch and any required detail such as delivery note or bill of lading, then check the quantity actually received rather than accepting the proposal. Item OK flags control what is posted. Save creates the material document, and the document number is what you keep for any later reversal or reconciliation.

After a MIGO posting, verify the material document and quantities using the S/4HANA material-document model (MATDOC or released material-document CDS views such as I_MaterialDocumentItem_2). Follow the reference PO, order, delivery or reservation and, for valuated movements, reconcile the linked accounting document. MKPF/MSEG are ECC-era names exposed through compatibility mechanisms in S/4HANA, not the primary persistence model.

MIGO is the strategic generalized goods-movement transaction in SAP S/4HANA and replaces many classic MB* entry/display transactions. The S/4HANA MM-IM data model persists material documents in MATDOC; MKPF/MSEG access is compatibility-oriented. New custom development should use released APIs/CDS views rather than depending on obsolete MB transaction flows or direct writes to classic tables.

Primary ownership is MM/Inventory Management, with PP, PM, SD or warehouse teams involved according to the reference document. Finance owns valuation/account-determination effects, and ABAP/Basis should join only when dumps, enhancements or technical integration errors are proven.