EKKN table — Purchasing Document Account Assignment Table

Each row in EKKN represents one account assignment line for one purchasing document item. For an account-assigned item (cost center, internal order, WBS element, asset, network, or similar), this table carries the actual G/L account and the cost object the item's value flows to. When an item is not split, there is exactly one EKKN row per EKPO item. When it is split - a common pattern for shared costs across two cost centers, or a WBS element plus a cost center - there are multiple EKKN rows for the same EBELN/EBELP, each carrying its own share expressed as a quantity or a percentage. The table exists for both purchase orders and, structurally mirrored, for purchase requisitions via a separate table. It is read at goods receipt and invoice posting time to determine where the FI/CO document lands.

Always restrict on MANDT implicitly and on EBELN, ideally with EBELP, before pulling from EKKN in any productive-size client - the table has no natural upper bound and scanning it without a document key restriction is slow. If the question is account-object driven rather than document driven (for example, list every PO line hitting a given cost center this year), filter on KOSTL together with a posting-date range from a joined table such as EKBE, because EKKN itself carries no posting date. Do not assume ZEKKN starts at 1 and increments cleanly for every item; treat it purely as a distinguishing key, not a count of splits.

Symptom: a cost center owner disputes a charge that appears to come from a purchase order. Select EKKN where EBELN equals the PO number and EBELP equals the item; if more than one row returns, the item is split - check whether VPROZ sums to 100 or MENGE sums to the EKPO quantity, and read SAKTO and KOSTL on each row to see the actual split of value across cost objects rather than assuming the whole item hit one center.

EKKN is retained in S/4HANA as the primary account assignment table for purchasing document items; there is no wholesale replacement. Field lengths for objects such as the WBS element were extended to match the wider identifiers used across S/4HANA, but the table's row-per-account-assignment-line structure and its relationship to EKPO and EKBN are unchanged. Reporting layers increasingly read purchasing data through CDS views rather than EKKN directly, but the underlying table still carries the data.

MM configures which account assignment categories are allowed and how distribution is entered on the PO item. FI or Controlling owns the validity and correctness of the cost objects themselves - whether a cost center is open, a WBS element is released, an order permits postings. A dispute over what an EKKN row says is usually an MM configuration question; a dispute over whether the cost object should have been used at all is a controlling or project accounting question.

EKPO is the parent item table and the source of the account assignment category; EKKO is the document header. EKBN records how the account assignment line was actually consumed at goods receipt and invoice entry. EBKN is the equivalent table for purchase requisition items before conversion. ME21N, ME22N and ME23N create and display the account assignment on a purchase order; ME51N/ME52N/ME53N do the same on a requisition; MIGO and MIRO read EKKN to determine posting targets at goods receipt and invoice verification.