BKPF table — Accounting Document Header Table

One row in BKPF represents a single accounting document header, created whenever an FI posting is made, whether by a G/L journal entry, an incoming invoice, a billing document transfer, or a payment run. The header carries the administrative and control data for that document: which company code and fiscal year it belongs to, what document type was used, who entered it and when, the posting and document dates, the currency, a free-text reference, and whether the document has since been reversed. It does not carry any monetary amounts or account assignments; those live at line item level. A document with one debit and one credit line, or with fifty lines split across cost centers and tax codes, still produces exactly one BKPF row.

Always restrict on MANDT implicitly and on BUKRS plus GJAHR explicitly before doing anything else; those two fields carry the real selectivity on this table. BELNR alone is meaningless because document number ranges are assigned per company code and can repeat across company codes and years. Do not select across all company codes on BUDAT or CPUDT without at least a company code range first, the table grows without bound over the life of a system and an unrestricted date-range scan against it is a common cause of a stuck background job or a locked dialog session. If hunting by user or entry date across many company codes, expect the query to run long unless a suitable index supports it.

Symptom: a customer or vendor line is reported as still open even though someone claims the document was reversed. Select BKPF on BUKRS, BELNR, GJAHR for the original document and check STBLG and STJAH. If both are blank, no reversal exists regardless of what was told to the business. If they are filled, take that STBLG/STJAH pair, look up the reversal document's own BKPF row to confirm it posted successfully, then check BSEG for both documents to confirm the clearing fields were actually set on the open item, not just that a reversal document exists.

BKPF continues to exist as a real table in S/4HANA and is still populated on every posting; it remains the header table for FI documents. Line item detail that used to live only in BSEG is now sourced from the universal journal table ACDOCA, with BSEG retained as a compatibility view mapped onto it. Joins from BKPF into line items therefore still work using the same BUKRS, BELNR, GJAHR keys, whether the target is BSEG or ACDOCA directly.

Questions about why a specific document looks the way it does, wrong document type, wrong posting date, missing reversal, sit with the FI or GL accounting functional team, not basis. Performance problems caused by unrestricted reads against BKPF in production are a basis and ABAP development concern, usually surfaced through a long-running job or a database team escalation rather than a functional ticket.

BSEG carries the line items belonging to each BKPF header. BSET carries the tax lines for the same document. T001 and T003 supply company code and document type configuration referenced by BKPF. ACDOCA is the universal journal table that underlies both BKPF and BSEG in S/4HANA. Documents in BKPF are written by standard posting transactions across FI, MM, and SD, and by the payment program which links back through REGUH and PAYR.