EBKN table — Purchase Requisition Account Assignment

One row in EBKN represents a single account assignment distribution for one purchase requisition item. If a requisition item is account-assigned to a single cost center or WBS element, there is normally one EBKN row for that item. If the item is split across multiple account objects (multiple account assignment, distributed by quantity or by percentage), there is one EBKN row per split, each carrying its own share of quantity or value and its own cost object. The table is the requisition-side mirror of EKKN on the purchase order: the same account assignment structure is reused, but EBKN belongs to EBAN (purchase requisition) rather than to EKPO (purchase order item). It does not store the account assignment category itself, which lives on EBAN.

EBKN is client-dependent, always restrict on MANDT implicitly by working inside the correct client. Selection should always start from BANFN, ideally with BNFPO, since neither field alone is safe to omit on a table that can carry several rows per item. Never select on cost center or WBS element alone across the whole table in a production system; the table grows with every multi-account-assigned requisition line ever created and there is no archiving housekeeping that most sites run aggressively. If the question is value-based, sum NETWR only within a single BANFN plus BNFPO plus ZEKKN combination, never across ZEKKN blindly assuming it is redundant.

Symptom: a requisition item shows one quantity on the requisition but postings appear to hit two different cost centers. Select EBKN on the known BANFN and BNFPO. If more than one row returns with different ZEKKN values, the item is multiply account-assigned by design, and each row's KOSTL or PS_PSP_PNR with its own MENGE or NETWR share explains the split. Cross-check the sum of MENGE across those rows against EBAN's requisition quantity for the item; a mismatch points to a distribution percentage or value error at creation, not a posting error downstream.

EBKN continues to exist as a transparent table in S/4HANA and purchase requisition account assignment data is still written to it in the classic structure. There is no widely adopted compatibility view that replaces EBKN the way some purchase order tables gained CDS-based read layers; consultants querying requisition account assignment in S/4HANA still go to EBKN directly or through the standard requisition apps rather than a renamed successor table. Field-level behavior and the split-by-ZEKKN logic are unchanged from ECC.

Discrepancies between requisition account assignment and actual posting belong to the MM/procurement configuration owner first, since account assignment category and default derivation are controlled there. If the dispute is about which cost object should have been charged, it moves to whoever owns the controlling or project master data being questioned, not to the person who created the requisition.

EBAN is the requisition header and item table that EBKN always joins back to. EKKN is the equivalent account assignment table on the purchase order side, populated once the requisition converts. EKPO and EKKO carry the resulting PO item and header once conversion happens. Requisitions are created and changed through the standard requisition maintenance transactions, and EBKN rows are written automatically whenever an account-assigned requisition item is saved with more than one distribution line entered on the account assignment screen.