EKBE table — Purchase Order History Table EKBE

One row in EKBE represents a single posted follow-on transaction against one item of a purchase order or scheduling agreement: a goods receipt, an invoice receipt, an order acknowledgment, a shipping notification, a delivery, a revaluation, or a subsequent debit or credit. The table is commonly called purchase order history. It does not describe the purchase order itself, only what has actually happened against it after creation, so a PO with no goods receipt and no invoice yet has no rows here at all. Over the life of a PO item there will typically be many rows: one per partial goods receipt, one per invoice, and an extra row for every reversal of either. The transaction/event indicator on each row is what tells a reader which kind of event it is looking at.

MANDT first, as with any standard table. Never scan EKBE without an EBELN restriction; on a procurement-heavy system it grows without bound and there is no secondary index that rescues a broad scan. The natural access path is EBELN plus EBELP, which is what the table is built around. If a search is date-driven, go through the referenced document instead, using MKPF-BUDAT for goods receipts or RBKP-BUDAT for invoices, rather than filtering on EKBE-BUDAT in bulk, since that field is a redundant copy and performs poorly as a primary filter. Restricting on VGABE early keeps the result set to a single event type and prevents goods receipt and invoice rows from being aggregated together by accident.

Symptom: an invoice is blocked for quantity variance on a PO item. Select EKBE for that EBELN and EBELP with VGABE = 1 (goods receipt), sum MENGE net of any reversal rows identified by the offsetting movement type, and compare that figure to the sum of MENGE where VGABE = 2 (invoice) for the same item. A mismatch between the two confirms the variance the system is complaining about. If the two totals already agree, the block is being driven by a tolerance key setting in invoice verification, not by anything visible in the PO history itself.

EKBE continues to exist as a transparent table in S/4HANA with its original structure and role as PO history; it has not been retired and there is no compatibility view standing in front of it for this purpose. The material documents underlying its goods receipt rows are technically sourced from the newer document store in current S/4HANA releases, but the application logic that writes EKBE behaves the same way, so reporting or programs built against EKBE do not need rework after migration.

Interpretation of goods receipt rows in PO history sits with the MM or procurement functional consultant; invoice rows sit with the FI-AP or invoice verification consultant. A mismatch between receipt and invoice quantities usually needs input from both sides rather than one. This is a functional reading question, not a basis or authorization one.

EKKO and EKPO hold the purchase order that EKBE reports history against. MKPF and MSEG hold the goods movement detail behind EKBE's goods receipt rows, written when a receipt is posted through MIGO. RBKP and RSEG hold the invoice detail behind EKBE's invoice rows, written through MIRO. EKET holds the PO's confirmed schedule lines, useful for comparing planned quantities against what history actually shows. ME23N displays EKBE data as the purchase order's history tab without requiring a direct table query.