BAPI_INCOMINGINVOICE_PARK — BAPI_INCOMINGINVOICE_PARK for Invoice Parking

The BAPI acts on the incoming invoice object in Logistics Invoice Verification and mirrors the park function of transaction MIR7, as distinct from BAPI_INCOMINGINVOICE_CREATE, which mirrors direct posting via MIRO. A parked document is stored in the invoice verification tables but has no FI document assigned and no impact on vendor open items, GR/IR clearing, or PO history until it is later completed and posted. Parking is used where the invoice amount, tax data, or account assignment needs review, where a workflow approval step is required before financial posting, or where the invoice is entered against a PO that has not yet been fully goods-receipted. Because SAP relaxes several checks for parked documents that it enforces for posted ones, the BAPI accepts data that BAPI_INCOMINGINVOICE_CREATE would reject outright.

The BAPI does not commit on its own. It builds the parked document in the update task and returns a document number and fiscal year that exist only inside the current LUW until BAPI_TRANSACTION_COMMIT is called explicitly by the caller. Programs that call the BAPI and then close the RFC session, or that branch away on an error condition without either committing or rolling back, leave the database in an inconsistent state: the caller believes a document number was assigned, but nothing is persisted. This is the single most common defect in custom parking programs, and it produces intermittent, hard-to-reproduce gaps where a document number appears in a log file but never shows up in the invoice verification tables.

RETURN is a table, not a flag, and every line must be inspected. Reading only the first line, only the last line, or only checking whether INVOICEDOCNUMBER is populated are all common interface bugs that produce false positives. Because parking tolerates more inconsistency than posting, a batch of messages with type W or I is normal even on a fully successful park, so a naive check that treats any non-empty RETURN table as failure causes valid documents to be rejected by the calling program. The correct pattern loops the full table and tests specifically for message type E or A anywhere in it, since a genuine blocking error can appear several lines into a table that also contains harmless warnings about tolerance limits or price variance. A second, subtler bug appears when the calling program filters RETURN by a specific message ID or number it expects, missing a differently-coded error from a user exit or a custom validation that fires during parking and silently drops the invoice.

BAPI_INCOMINGINVOICE_PARK remains valid and in active use on S/4HANA on-premise and private cloud editions for custom integrations that need to park rather than post directly. There is no dedicated released successor API specifically for parking that has broadly displaced it. Fiori-based supplier invoice processing apps use their own backend service layer rather than calling this BAPI directly, but for RFC-based interfaces, custom uploads, and legacy integration programs, this BAPI is still the standard mechanism to reach MIR7-equivalent parking behaviour.

Interface failures, missing commits, and RETURN table misreads are development problems, evidenced by a debug trace or a dump showing INVOICEDOCNUMBER filled but no corresponding document in the invoice verification tables. Tolerance limits, tax code determination, withholding tax setup, and account assignment rules that cause valid-looking parks to fail later at posting are functional configuration issues, evidenced by the relevant IMG settings and a comparison against a manually parked document via MIR7 with identical data.

The transaction it mirrors is MIR7, with posted equivalents living in the standard invoice verification header and item tables. Sibling BAPIs cover the rest of the invoice lifecycle: one posts a document directly instead of parking it, and another releases an invoice blocked for payment or verification. Before parking, interfaces commonly call a purchase order detail lookup to validate PO item data, and a vendor master lookup to confirm withholding tax and payment term settings that feed HEADERDATA and WITHTAXDATA.