RBKP table — RBKP Invoice Document Header Table

One row in RBKP represents one invoice document created through logistics invoice verification, identified by document number and fiscal year. This covers standard invoices, credit memos, subsequent debits and credits, and invoices entered for goods receipts or purchase orders. The row exists as soon as the document is parked, held, or posted, so RBKP contains documents in various completion states, not only finished postings. It records who entered the document, when it was entered, the header level reference text, the total gross amount and currency, and whether the document has since been reversed. It does not carry the individual purchase order lines, tax lines, or GL account splits, those are distributed across item and accounting tables that key back to this header by document number and year.

Always restrict by MANDT implicitly through the login client, then narrow by BUKRS and a BUDAT or CPUDT range before touching anything else. RBKP is not small in a mature productive system, and BELNR alone is not selective for exploratory queries since it is just a sequential number with no business meaning attached. XBLNR is useful for finding a specific vendor invoice by its printed number but is free text entered by the AP clerk, so it is inconsistent in format and should be searched with wildcards, not exact match. RBSTAT is worth checking early when a document seems to be missing from downstream reports, since a parked or held document exists in RBKP but has not generated postings anywhere else yet.

To confirm a vendor invoice was actually posted rather than only parked, select RBKP on BUKRS, GJAHR, and XBLNR matching the vendor's invoice number, then check RBSTAT on the returned row. If RBSTAT indicates a parked or held state, the document has no accounting entry yet regardless of what the vendor or requester believes was submitted. If STBLG is populated, the invoice was reversed, and the reversal document number and year point to the offsetting entry, which explains why the original amount no longer appears in open item reports.

RBKP continues to exist as a transparent table on S/4HANA and logistics invoice verification still writes to it in the same shape familiar from ECC. SAP has moved much of the reporting layer for invoice verification onto compatibility views and newer CDS-based analytics, but the underlying table and its key fields have not been restructured the way some MM tables were during the Material Ledger and inventory document changes. Existing ABAP that reads RBKP directly continues to function without adjustment on S/4HANA in practice.

The accounts payable or MM invoice verification team owns questions about individual documents and posting status. A functional MM or FI-AP consultant owns configuration questions about invoice blocking reasons, tolerance settings, and workflow routing that affect why RBSTAT sits in a parked state. A basis or data team gets involved only if the question is about table growth, archiving of old invoice documents, or performance of reports scanning RBKP at scale.

RSEG holds the invoice line items and is written in the same transaction as RBKP, MIRO and MIR7 create both together. EKBE carries the invoice history entry against the purchase order once the invoice posts. BKPF and its related tables hold the resulting accounting document. LFA1 and LFB1 supply vendor master data referenced indirectly through the purchase order and the accounting document, not through a direct field in RBKP itself.