BAPI_INCOMINGINVOICE_RELEASE — Release a Blocked Incoming Invoice

The BAPI acts on the invoice document created by logistics invoice verification, the object stored across the invoice header and item tables. It mirrors transaction MRBR used for individual release of blocked invoices, not the release strategy transactions used for purchase orders or purchase requisitions. An invoice ends up blocked either automatically, because the posted quantity or price falls outside the configured tolerance limits, or manually, because someone set a payment block reason during MIRO. This BAPI clears that block on a single invoice document so it becomes eligible for the next automatic payment run. It does not create, park, or reverse an invoice, and it does not touch the purchase order it references.

The interface is deliberately narrow, matching the fact that MRBR releases one document at a time in its BAPI form.

The BAPI does not commit. It updates the invoice block status inside the current logical unit of work and leaves the decision to persist that change to the caller, exactly like every other classic BAPI. A separate call to the transaction commit function module is required immediately afterward. If the caller forgets it, the release looks successful in RETURN, the invoice appears unblocked in the same session, but nothing is actually written to the database. The next payment run still sees the invoice as blocked, and there is no error anywhere in the log to explain why, because the failure is an omission, not a rejected operation.

SY-SUBRC after the call is essentially useless; it stays zero whether the release succeeded, was rejected, or the invoice did not exist. All meaningful information sits in the RETURN table, and it can carry more than one line. A correct check scans every entry for TYPE E or TYPE A, not just the first row, because a single call can return an informational message alongside an error, and code that inspects only line one will treat a real failure as success. A frequent interface bug is checking whether RETURN is initial and calling that success; an invoice that is already released, not found, or blocked for a reason this BAPI cannot touch will still populate RETURN with a message, sometimes type I or W rather than E, and lazy filtering waves those through as if the release happened. In batch programs, RETURN must be captured per invoice and logged with the invoice number, not overwritten on each loop iteration, or a mid-batch failure disappears silently.

The underlying process, invoice verification with tolerance-based blocking and release, is unchanged on S/4HANA, and this BAPI remains valid for programmatic release. There is a Fiori app for end users to manage and release blocked invoices interactively, but that does not replace this BAPI for custom integrations, interfaces, or batch release jobs, which continue to call it directly. No newer released communication scenario has superseded it for this specific operation.

Most failures trace back to loop handling, commit placement, or a mismatch between the block reason and what this BAPI is actually able to clear.

Functional MM invoice verification consultants own the tolerance configuration and the list of valid block reasons, and are the ones who can say whether a given invoice should even be releasable through this path. Developers own the calling program: commit placement, loop structure, and RETURN parsing. When a release job reports success but invoices stay blocked, the evidence needed is the RETURN table contents per invoice plus confirmation of whether a commit call followed the BAPI in that run.

The transaction it mirrors is MRBR, used for interactive individual or mass release of blocked invoices. The relevant tables are the invoice header and item tables written by logistics invoice verification. Sibling BAPIs cover the rest of the invoice lifecycle: creation, parking, and detail retrieval, and none of them substitute for the release step this BAPI performs.