BAPI_INCOMINGINVOICE_CREATE — Create Incoming Invoice via BAPI (MIRO Equivalent)

BAPI_INCOMINGINVOICE_CREATE creates a Logistics Invoice Verification document, the same object produced by transaction MIRO. It books a vendor invoice against one or more purchase order items, or against a direct G/L or material account assignment, and on successful posting generates the resulting FI accounting document in the same step. This is a posting BAPI, not a parking BAPI: unlike BAPI_INCOMINGINVOICE_PARK, it does not leave the invoice in a preliminary, editable state. It writes the invoice header to RBKP and the line items to RSEG, updates purchase order history, and can trigger invoice blocking (payment block, quantity or price variance block) exactly as MIRO would, depending on tolerance configuration.

Core importing and exporting parameters used in almost every call.

The BAPI does not commit. It performs the posting logic and returns a document number that exists in the current update task but is not yet durable. BAPI_TRANSACTION_COMMIT (or an explicit COMMIT WORK in the calling program) is required to make the invoice persist. Interfaces that omit this step, or that call the BAPI inside a loop and commit only once at the end, will see INVOICEDOCNUMBER populated for every call yet find some or all of those documents missing afterward, because a later rollback in the same LUW silently undoes earlier successful postings that were never separately committed.

RETURN is a table of BAPIRET2 structures, not a single flag, and sy-subrc after the call is not a reliable indicator because the function module itself frequently returns zero even when the posting failed. The correct check is to scan RETURN for any entry with TYPE equal to E or A; only then does the invoice not exist. A common interface bug is checking only whether RETURN is empty, which misses genuine warning-level entries (TYPE W) that flag duplicate invoice suspicion, price variance, or quantity variance while the document still posts. A second, more damaging bug: INVOICEDOCNUMBER can come back non-blank from an internal simulation pass even when a later validation step in the same call rejects the posting, so code that treats a filled document number as proof of success, without also confirming RETURN has no E or A entries, ends up logging false successes and, on retry logic, double-posting the same invoice.

BAPI_INCOMINGINVOICE_CREATE remains valid and widely used in S/4HANA for custom back-end integrations and batch invoice loads; it has not been formally deprecated. For new integrations, particularly those exposed to external systems or built as part of a Fiori-based extension, SAP's preferred entry point is a released API-first service for supplier invoice creation rather than a direct BAPI call, but the BAPI is still the pragmatic choice for internal RFC-based interfaces and migration cutover loads where the calling program already runs inside the SAP system.

Failures traced back to this BAPI in real interfaces are almost always master data or timing issues surfaced through a generic-looking error message.

A posting that returns an error message is functional territory first: PO status, GR posting, tolerance keys, and tax code configuration explain most rejections. A posting that returns no error but leaves no document, or double-posts, is a developer issue in commit handling or RETURN evaluation. Functional needs the exact RETURN message text and the PO/GR history; developer needs the interface log showing whether commit was called and what RETURN contained at the point of the decision.

Mirrors transaction MIRO and writes to tables RBKP and RSEG. Sits alongside BAPI_INCOMINGINVOICE_PARK for preliminary postings and BAPI_INCOMINGINVOICE_RELEASE for releasing blocked invoices. Depends on prior purchase order and goods receipt state, which makes BAPI_PO_GETDETAIL1 and BAPI_GOODSMVT_CREATE relevant upstream checks when a posting fails on PO or GR grounds.