BAPI_ACC_INVOICE_RECEIPT_POST — Posting invoice receipts into FI via BAPI

BAPI_ACC_INVOICE_RECEIPT_POST posts an accounting document representing an invoice receipt against a vendor, mirroring the FI side of what Logistics Invoice Verification produces when an invoice is entered against a purchase order or goods receipt. It exists for integration scenarios where the invoice originates outside the standard MM invoice-verification path — external billing systems, industry components, or custom interfaces that need to book the vendor liability, offsetting G/L accounts and tax lines straight into accounting without stepping through MIRO or MIR7. The object it creates is a normal FI document, subject to the same posting period, tolerance and account-determination rules as a document posted through the transaction it stands in for. It does not itself touch the purchase order history or GR/IR clearing account logic unless the calling program supplies the matching G/L or offsetting entries.

Like the rest of the accounting-interface BAPI family, this call does not commit the database update on its own. It performs the checks and, if successful, hands the document to the update task, but the change only becomes permanent when the caller invokes BAPI_TRANSACTION_COMMIT afterward. Skip that call and the document is either rolled back at the end of the logical unit of work or left pending inside a dialog transaction that never gets flushed. In batch interfaces this is the single most common cause of postings that appear to succeed — RETURN carries a document number — but never show up in the vendor account or in FBL1N, because the commit step was never reached or was skipped after an unrelated error further down the program.

RETURN is a table, not a flag, and every entry has to be inspected by message type, not just counted. A successful posting normally returns an entry of type S carrying the generated document number in the message variables; interfaces that only check whether RETURN is initial will treat a rejected posting as successful because RETURN is never empty on error either — it is full of E and A entries describing exactly why the document was refused. The reverse mistake is just as common: code that greps for any entry of type E and aborts, without noticing that an earlier W entry (a tolerance warning, a tax adjustment) was informational and the document actually posted. The safe pattern is to scan for message type E or A across the whole table before deciding the call failed, extract the document number only from a genuine S entry, and log the full table rather than the first entry, because the root cause of a rejection is frequently the second or third message, not the first.

BAPI_ACC_INVOICE_RECEIPT_POST remains callable on S/4HANA and is not formally deprecated, but it sits in the same older accounting-interface family as BAPI_ACC_DOCUMENT_POST and is not the preferred entry point for new integrations. Where the requirement is a general FI posting rather than something that specifically has to look like an invoice receipt, BAPI_ACC_DOCUMENT_POST is the more common choice going forward. There is no confirmed released OData or API-Business-Hub replacement specific to this BAPI, so existing interfaces built on it continue to run unchanged, but new builds should evaluate the generic document-posting BAPI or a released API for the same outcome before reusing this one.

The interface developer owns the mapping of vendor, G/L, tax and currency data into the correct structures and the commit sequence around the call. The FI functional consultant owns account determination, tax procedure, tolerance groups and posting period control that decide whether the data the developer sends is actually postable — a RETURN rejection needs the full message text and company code before either side can act on it.

The transaction it mirrors is Logistics Invoice Verification, MIRO for individual invoices and MIR7 for parked invoices; the resulting document lands in BKPF and BSEG like any other FI posting. Sibling BAPIs in the same accounting-interface family include BAPI_ACC_DOCUMENT_POST for generic FI postings, BAPI_ACC_GL_POSTING_POST for pure G/L entries, and BAPI_ACC_DOCUMENT_REV_POST for reversing a document created through this family.