EKBN table — Purchase Order Confirmations Table

One row in EKBN represents a single confirmation sent for a specific schedule line of a purchase order item, under a confirmation control key that requires tracked confirmations. A schedule line can receive several confirmations over its life - an order acknowledgment first, then a shipping notification, possibly a revised delivery date later - and each of those lands as its own row, distinguished by a sequential confirmation number and a confirmation category. The table does not hold the 'official' schedule; it holds what the vendor said, category by category, over time. Purchase order items with a confirmation control key that does not require confirmations have no rows here at all, which is the normal state for most PO items in many organizations.

Always restrict by client, then by EBELN and EBELP before anything else; a full scan on EKBN with no document filter is rarely justified because the table is sparse compared to EKET. If the question is about one schedule line, add ETENR to the selection immediately. Do not assume every PO item has rows - absence of rows simply means the item's confirmation control key does not require tracked confirmations, not that something failed. When multiple rows exist for the same schedule line, sort by EBTNR to see the sequence of confirmations over time, and check BSTAE on each to know what kind of confirmation it is before comparing dates or quantities across rows.

Symptom: buyer says the vendor promised a later delivery date than what the purchase order schedule shows, and wants to know if that was ever captured. Select EKBN where EBELN equals the PO number, EBELP equals the item, and ETENR equals the schedule line in question. Order the result by EBTNR and read EINDT and BSTAE on each row against the requested confirmation category to see the sequence of dates the vendor actually confirmed, then compare the latest relevant one to EKET-EINDT on the same key to see whether the schedule line was ever updated to match.

EKBN continues to exist in S/4HANA and is populated the same way, driven by the same confirmation control key logic on the purchase order item. There is no widely known compatibility view replacing it as the primary source for this data; purchase order maintenance and display transactions still read and write it directly. Newer confirmation-related Fiori apps generally write to the same underlying table rather than a separate structure, but any such detail specific to a given release should be checked against the actual system rather than assumed.

Questions about what confirmation control key configuration is doing and what a given BSTAE code means belong with the MM functional consultant or the procurement configuration owner. Reading actual confirmation history out of EKBN for a specific PO and reconciling it against EKET is standard P2P functional troubleshooting, not a basis or technical data issue.

EKKO and EKPO hold the purchase order header and item that EKBN's confirmations belong to. EKET holds the schedule lines that EKBN confirmations are recorded against, and is the table actually consumed by MRP and goods receipt logic. Purchase order maintenance transactions write and display confirmation data as part of normal PO change and display, and the confirmation control key setting on the item determines whether EKBN gets populated at all.