Purchase order remains open after delivery and invoice

The buyer or accounts payable clerk reports that a purchase order they consider finished still shows up on the open PO list, or blocks a period-end report that is supposed to be empty. The goods came in, the invoice was posted and paid, and from the business side the transaction is closed. But ME2M, MB5S, or a vendor aging report keeps listing the order as outstanding, sometimes for a tiny remaining quantity or value nobody can explain. It gets escalated when the open item shows up in a GR/IR reconciliation report at month end, or when a controller asks why a purchase order from months ago is still committing budget. At this point nobody suspects a specific configuration or master data setting; it looks like a data error, or like someone simply forgot to close something manually.

Ordered roughly by how often each one turns out to be the actual cause once someone opens the PO history and checks line by line rather than at header summary level.

Work through the item detail before touching any indicator, since the fix depends entirely on which of the above is actually present.

Pull PO history for the item showing ordered, delivered and invoiced quantity and value side by side, then run FBL3N for the GR/IR account filtered by that purchase order number. A non-zero balance on the GR/IR account proves the order is genuinely incomplete somewhere in the chain; a zero balance with the order still flagged open points to a missing completion indicator or a value-limit framework order rather than a real outstanding amount.

If the cause is a missed final indicator on a delivery that is genuinely complete within tolerance, set delivery completed on the item in ME23N; this is a data fix with no transport required, but only after confirming the shortfall is within acceptable business tolerance, not blindly. If a blocked invoice is holding the order open, release it through MRBR once the variance behind the block has been investigated and resolved. A missing freight or delivery-cost invoice is closed by posting the outstanding vendor invoice for that condition line, not by editing the order. A down payment left uncleared is resolved by running the down payment clearing step against the final invoice. If the underlying tolerance keys are simply too tight for the vendor's normal receiving pattern, correcting the tolerance fields on the vendor master or info record is a master-data change, effective immediately, not a transportable configuration change. If the real issue is that a framework or value-limit item category is designed to stay open by nature, that is expected behaviour, and the fix is excluding it from the open-item report rather than changing the order; changing item category completion logic globally is a configuration change requiring testing and transport, and should never be done to close one order.

The reflex fix is to open the item and manually flag both delivery completed and final invoice to force it off the open list, without checking why it was actually still open. If the real cause was a blocked invoice or an uncleared down payment, this hides a genuine outstanding balance on the GR/IR account or the down payment clearing account rather than resolving it, and that balance then sits unexplained at the next period-end reconciliation. It also removes the order from anyone's follow-up list, so the blocked invoice or uncleared down payment never gets chased and the vendor's payment status stays wrong indefinitely.

Accounts payable or procurement operations owns the first pass: checking indicators, blocked invoices, and down payments is data investigation, not configuration, and most cases resolve there. The handover to MM configuration only applies when tolerance keys or item category completion logic need a structural change, and the handover note should include the PO number and item, the GR/IR balance if any, the tolerance key and percentage in use, and whether a blocked invoice or open down payment is involved.