BAPI_ACC_DOCUMENT_CHECK — BAPI_ACC_DOCUMENT_CHECK Validation Without Posting

BAPI_ACC_DOCUMENT_CHECK acts on the same generic accounting document object as BAPI_ACC_DOCUMENT_POST, covering general ledger, customer, vendor and tax line items in one call. It mirrors the validation logic that runs behind FB01, FB60, FB70 and similar posting transactions: account existence, company code assignment, currency and amount consistency, tax code determination, and cost object validity. The difference is that it stops short of the actual database update. No document number is drawn from the number range, no accounting document table entry is created, and no financial period is touched. It exists specifically for interface scenarios where an external system needs to know whether a document would be accepted before committing the business transaction that produces it, for example a billing or procurement system deciding whether to proceed with a downstream posting.

There is nothing to commit. Because the function performs validation only, it never calls an update task and never writes to the database, so a caller does not need to follow it with BAPI_TRANSACTION_COMMIT. Calling COMMIT after this BAPI is harmless but pointless, since there is no pending work in the update queue. The risk runs the other way: some interface developers assume that because BAPI_ACC_DOCUMENT_POST needs a commit, this one does too, and add unnecessary commit logic that occasionally masks an unrelated LUW from an earlier call in the same session. The safer mental model is that this BAPI has no side effects at all beyond the RETURN table it hands back.

RETURN can contain multiple lines and mixes severities: S and I for informational confirmations, W for warnings the actual posting will still accept, E and A for conditions that will cause BAPI_ACC_DOCUMENT_POST to reject the same data. The recurring interface bug is checking only the first line, or checking sy-subrc after the RFC call instead of inspecting the table, and treating an empty first row as success while a real error sits in row three. A second common mistake is treating any non-empty RETURN as failure, which causes documents to be rejected on nothing worse than an informational message about a rounding adjustment. The correct pattern loops the full table, tests TYPE against E and A specifically, and surfaces MESSAGE together with FIELD and ROW so the calling process can point at the exact line item that failed, rather than showing a generic 'posting check failed' message to the business user.

BAPI_ACC_DOCUMENT_CHECK still works unchanged on S/4HANA and continues to be RFC-enabled, since it sits on the same generic accounting interface as its posting counterpart. SAP's longer-term direction for journal entry integration is a set of released OData and SOAP services under the API Business Hub rather than classic BAPIs, and new interfaces are generally steered toward those services where a suitable one exists. Existing custom or third-party interfaces built on this BAPI are not broken by the move to S/4HANA and do not need to be migrated purely for that reason.

Functional consultants own the business rules being validated: account determination, tax code assignment, cost object rules. Developers own the RFC call itself and how RETURN is parsed and surfaced. When a check passes but the real posting fails, the evidence needed is the exact input structures sent to both calls side by side, since a mismatch there almost always explains the discrepancy rather than a defect in the BAPI itself.

The direct sibling is BAPI_ACC_DOCUMENT_POST, which shares the same interface structures and is called immediately after a successful check in most integration designs. The transactions it mirrors are FB01, FB60, FB70 and similar accounting document entry screens. Since it writes nothing, there is no underlying table to inspect for its own output; any table evidence belongs to the posting call that follows it, such as the accounting document header and line item tables.