BAPI_ACC_GL_POSTING_POST — BAPI for Posting General Ledger Documents

BAPI_ACC_GL_POSTING_POST posts an accounting document consisting only of general ledger line items, functionally equivalent to what a user would key into FB50 or F-02 when no customer or vendor line is involved. It sits in the same family as BAPI_ACC_DOCUMENT_POST but with a narrower interface: no accounts receivable table, no accounts payable table, no tax line table beyond what is passed in the G/L items themselves. It is the natural choice for integrations that push journal entries from external systems, treasury tools, billing engines or non-SAP subledgers into FI where every line lands on a G/L account rather than a subledger account. The underlying business object is the accounting document; the BAPI creates one document per call and returns its number once the posting succeeds.

The interface is compact compared to its sibling BAPI_ACC_DOCUMENT_POST because it only carries G/L line data.

The BAPI does not commit. It builds the document inside the calling LUW and hands back a document number in the RETURN messages, but the posting only becomes durable when the caller issues BAPI_TRANSACTION_COMMIT. Interfaces that skip this step, or that call it conditionally based on a flag that never gets set, see the call return cleanly with what looks like a valid document number, only for the document to vanish because the update was rolled back at the end of the session. This is the single most common cause of the report that a posting BAPI worked in a test but the document is not in BKPF, and it has nothing to do with the BAPI itself.

RETURN is a table, not a single flag, and every row has a TYPE field that can be S, E, W, A or I. The only safe pattern is to scan the whole table for TYPE E or TYPE A before deciding the posting succeeded; checking only whether the call dumped, or checking only the first row, misses the common case where an early informational message is followed by an error further down the table. The document number, when posting succeeds, is not returned in a dedicated output parameter but embedded inside a success message in RETURN, so interfaces that parse it with a fixed offset break the moment the message text or number of leading messages changes. Interfaces that log success purely because no exception was raised, without inspecting message type, routinely report documents as posted that were rejected for a closed posting period or an unbalanced amount. Any wrapper around this BAPI should extract the message class, number and variables explicitly rather than pattern-matching on message text.

BAPI_ACC_GL_POSTING_POST remains a released, supported BAPI on S/4HANA and continues to post into the universal journal through the standard posting logic underneath. It has not been formally deprecated. For new integration builds, particularly cloud-to-cloud or partner scenarios, SAP's published communication scenarios and OData-based journal entry APIs are the preferred entry point, and many S/4HANA implementations steer new interfaces there while leaving existing BAPI-based integrations in place. For established on-premise custom code this BAPI is still a normal, working choice.

Most failures trace back to a small set of recurring causes.

A posting rejected for a closed period, missing account assignment, or account determination problem is a functional configuration issue and belongs with the FI consultant. A posting that reports success but never appears in the ledger, or that fails with a dump, is an interface defect and belongs with the developer, who should be asked to show the commit call and the full RETURN table content, not just the first message.

The manual equivalents are FB50 and F-02, and the resulting document lands in BKPF and BSEG. The closest sibling is BAPI_ACC_DOCUMENT_POST, used when the document needs customer or vendor lines alongside G/L lines, with BAPI_ACC_DOCUMENT_CHECK available to validate a document before posting and BAPI_ACC_DOCUMENT_REV_POST used to reverse one afterward.