MB31 — Goods Receipt for Order

MB31 posts a goods receipt into inventory against an internal order, most commonly a production order or process order, using movement type 101 by default (102 for reversal). The receipt increases stock, updates the order's delivered quantity, and triggers valuation based on the order's cost estimate or standard price. The one structural fact that explains most confusion: MB31 validates against the order (its status, its component list, its tolerance limits), not against a purchase order history. Consultants who come from a purchase-to-pay background expect PO-style three-way matching and are surprised when MB31 accepts quantities the order's own settings do not flag as an issue, because there is no PO to compare against.

MB31 sits at the confirmation-and-receipt end of production execution, used when finished or semi-finished goods produced against a production or process order need to be booked into stock without going through the order confirmation transaction's automatic goods receipt option. It is also used for goods receipts against maintenance orders where spare parts or refurbished components are received back into stock. A consultant reaches for MB31 specifically when the goods receipt needs to be posted independently of confirmation, or when troubleshooting a receipt that MIGO's order-related tab did not handle as expected. In newer implementations MIGO or a Fiori manufacturing app is preferred for the same posting; MB31 remains the fallback when the order type or movement scenario is not yet mapped to the newer interface.

In SE16 or SE16N, open MSEG filtered on BWART = 101 (or 102 for the reversal) and AUFNR equal to the order number in question. Join to MKPF on MBLNR and MJAHR to get posting date and user. Compare the summed quantity against the order's delivered quantity in AFPO to confirm whether the posting actually reduced the open order quantity, and check RESB for the same order to see whether component consumption moved in step with the receipt.

MB31 still works on S/4HANA and posts through the same logic, though the underlying storage is the universal journal's MATDOC table with MKPF and MSEG served as compatibility views. SAP's direction is toward MIGO for order-related receipts and toward Fiori apps for production execution, which present the same posting with a more current interface, but no functional change has been made to what MB31 itself checks or writes.

This is a functional MM or PP problem first; the consultant investigating an MB31 issue needs to check order status, movement type configuration, and valuation settings before involving anyone else. ABAP involvement is limited to custom user exits or enhancement logic wrapped around the posting; Basis is rarely involved except for authorization object failures. A good handover includes the order number, movement type, material document number if one was created, and the exact error message text.

MB1A, MB1B, and MB1C cover the other classic goods movement transactions for consumption, transfer, and other receipts, useful for understanding movement type logic more broadly. MB03 displays the material document that MB31 creates, MB52 gives a stock overview to confirm the posting landed where expected, and MBST is the reversal transaction referenced directly in the pitfalls above. MMPV is relevant when an MB31 posting fails because the posting period is already closed.