BAPI_ACC_DOCUMENT_REV_POST — Reversing accounting documents via BAPI

BAPI_ACC_DOCUMENT_REV_POST reverses an accounting document that already exists in the system, whether it was posted manually, through FB01, or through another BAPI such as BAPI_ACC_DOCUMENT_POST. It mirrors the functional behaviour of FB08, individual document reversal, rather than mass reversal transactions. The BAPI creates a new document with reversed debit and credit entries, links it to the original via the reversal reason and reference, and updates the original document's status to reversed. It operates purely on FI accounting documents (table BKPF and BSEG) and does not touch the originating logistics or sales document, so if the reversal needs to also undo a goods movement or a billing document, that has to be handled separately, typically before or after this call rather than through it.

The interface is narrow compared to the posting BAPIs, since it only needs enough information to identify one existing document and describe how to reverse it.

Like the other document-handling BAPIs in this family, BAPI_ACC_DOCUMENT_REV_POST does not commit the database update by itself. A successful call only means the reversal has been built and validated in the update task; it is not saved until BAPI_TRANSACTION_COMMIT is called afterward. If the caller forgets the commit, the reversal document is not written to the database, the original document still shows as open or cleared exactly as before, and no error is raised anywhere in the interface to indicate this. The symptom in production is a batch job or interface that logs a successful reversal, complete with a document number range, but the document never appears in FB03 or the line item reports, because the number was reserved in the buffer and rolled back with the missing commit.

RETURN behaves the same way as in the posting BAPIs and gets misread the same way. The call can return without a dump and without any entry of type E in RETURN while the reversal still did not happen, typically because the document was already reversed, already cleared against a payment, or the reversal reason used forbids reversing documents with cleared items. Interfaces that only check whether the returned document number field is populated, without scanning every RETURN line for type E or A, will report success on a reversal that was actually rejected. The correct pattern is to loop through all RETURN entries, treat any E or A as a full failure regardless of what else is populated, and only trust a returned reversal document number when RETURN contains no error-level entries. Warnings, type W, commonly appear for things like a reversal posting date falling outside the original document's period, and these need visibility in logs even though they do not block the reversal, because they explain why the reversal landed in a later period than expected.

BAPI_ACC_DOCUMENT_REV_POST remains usable on S/4HANA for reversing FI documents and is not marked obsolete. The underlying accounting document model changed with the introduction of the universal journal, but the reversal logic and status handling for BKPF-level documents did not require a new interface for standard reversal scenarios. For newer integration scenarios, particularly cloud-based and event-driven architectures, released APIs built on the same accounting document object are preferred where available, but for on-premise custom developments and existing interfaces this BAPI continues to be the standard call for programmatic reversal.

Most incidents trace back to document status or configuration rather than the BAPI call itself.

A rejected reversal or an unbalanced reversal is a functional configuration issue first, usually a reversal reason restriction, an open item clearing status, or a closed posting period. Bring the exact document number, company code, fiscal year, and the full RETURN table content. It becomes a development issue only when RETURN shows no errors but the commit is missing or the calling program suppresses error-level messages before logging.

Functionally mirrors FB08 for individual document reversal, and reads and updates BKPF and BSEG directly. Reversal reason codes are maintained in FI configuration tables governing negative posting behaviour. The natural counterpart is the posting BAPI that most likely created the document in the first place, and any reset-clearing step needed before reversal is a separate call, not part of this interface.