BAPI_ACC_DOCUMENT_POST — Generic Accounting Document Posting BAPI

BAPI_ACC_DOCUMENT_POST creates an FI accounting document — the same object FB01 creates online, and the same one that lands in the document header and line item tables once posted. It is deliberately generic: a single call can carry general ledger lines, customer (AR) lines, vendor (AP) lines and tax lines together, which makes it the standard entry point for interfaces from non-SAP subledgers, billing systems, payroll feeds, bank statement postings and custom batch programs that need to create FI documents without going through the FB01 dynpro. It does not post to CO on its own; if the posting needs a cost object it relies on the account assignment fields inside the line item structures, same as manual entry would.

BAPI_ACC_DOCUMENT_POST does not commit the database. It runs the same validations and number range draw that FB01 would, builds the document in the work process, and hands back OBJ_KEY as if the posting succeeded — but nothing is durable until the caller explicitly calls BAPI_TRANSACTION_COMMIT (or the equivalent rollback call on failure). Forget the commit and the session ends, or the next dialog step in the same LUW triggers an implicit rollback, and the document that OBJ_KEY pointed to simply does not exist. This is the single most common defect in first-pass interface builds: the developer sees a document number returned, assumes the posting is final, and only discovers the gap when finance cannot find the document days later or when a number range shows a permanent gap.

RETURN is a table, not a single flag, and every row has a TYPE field (S, W, E, A) that must be inspected individually — checking sy-subrc after the call or checking whether RETURN is empty tells almost nothing, because the BAPI frequently returns sy-subrc 0 alongside error rows, and it can return warning rows on an otherwise successful posting. The correct pattern loops RETURN looking for TYPE = 'E' or TYPE = 'A'; only if none are found is it safe to call the commit. A second class of bug comes from calling the commit unconditionally regardless of RETURN content, which turns a rejected posting attempt into a document anyway if some lines partially succeeded, or masks the real error behind a generic dump later in the interface chain. A third comes from parsing only the first row of RETURN for a status code and ignoring the rest, which loses the actual account-determination or tax message that explains why the whole document failed.

BAPI_ACC_DOCUMENT_POST still works on S/4HANA and remains in wide use for existing interfaces and custom batch programs; SAP has not withdrawn it. For new builds, particularly extensibility and side-by-side scenarios, SAP's published API strategy increasingly points toward OData-based journal entry creation services published through the API Business Hub rather than classic BAPIs. Existing interfaces built on this BAPI are not obliged to migrate, but new integration work is worth checking against the currently released API catalog before defaulting to it out of habit.

The commit call, RETURN parsing and retry logic are development problems; evidence needed from functional is the field status group and account determination configuration behind whatever GL, AR or AP account the line is trying to post to. The functional side owns document type, posting key, and tax code setup; evidence needed from development is the exact RETURN row, not a summary of 'it failed'.

Mirrors FB01 online, writes to the same BKPF and BSEG tables, and reads number ranges the same way manual posting does. BAPI_ACC_DOCUMENT_CHECK runs the same validation without posting, useful for pre-flight interface testing. BAPI_ACC_DOCUMENT_REV_POST reverses what this BAPI created. BAPI_ACC_GL_POSTING_POST is the narrower GL-only sibling when no subledger lines are involved, and BAPI_ACC_INVOICE_RECEIPT_POST covers the logistics invoice verification path instead of a generic accounting document.