EKPO table — Purchasing Document Item Table

One row in EKPO represents a single line item of a purchasing document: material or service, plant, storage location, quantity ordered, price conditions at header-line level, account assignment category, item category, and a set of status indicators showing whether the item is deleted, delivery-complete, or invoice-complete. The document header (vendor, purchasing organization, document type, currency) sits in EKKO and is not repeated here. A scheduling agreement or contract item in EKPO typically carries a nominal or zero target quantity, with the real delivery schedule sitting in EKET. Text items and some service items carry no material master reference at all, which is normal, not a data error. EKPO is the table most people mean when they say a purchase order line.

The primary key is MANDT plus EBELN plus EBELP, so the client field is implicit and every selection must be scoped by it. Never select on MATNR alone across a live system; it is not selective and will scan the full item population. Always restrict by an EBELN value or range where the document number is already known, or join through EKKO first and filter on document type, purchasing organization or creation date before pulling EKPO rows. Use LOEKZ equal to space to exclude deleted items and ELIKZ/EREKZ only as a first-pass filter, not as proof of physical completion. On any classic database the table is large enough that an unrestricted MATNR or WERKS scan is a real performance problem; on HANA it is tolerable but still wasteful.

Symptom: a purchase order line still shows as open in a reporting list even though the business believes goods receipt and invoice are both done. Select EKPO for the known EBELN and EBELP and check ELIKZ and EREKZ directly. If both are blank, the system considers the item open regardless of what was posted, so the next step is comparing EKPO-MENGE against the cumulative quantities in EKBE for that same EBELN/EBELP, because a partial or reversed posting will leave the completion flags unset even after real-world delivery.

EKPO remains a physical table in S/4HANA and continues to hold purchasing document items; it was not retired or replaced by a compatibility view at the persistence layer the way some finance tables were. Some fields tied to older price determination or classic account assignment scenarios are considered legacy in newer procurement scenarios, and additional item categories exist for advanced procurement processes, but the table structure and its role as the item counterpart to EKKO is unchanged. Reporting layers built on CDS views typically read through EKPO underneath.

A procurement or MM consultant owns interpretation of item status, item category and account assignment fields. Pricing and tax-relevant fields are often shared with FI or controlling when the item carries a cost object. The business buyer or procurement process owner is the right person to confirm intent behind an unusual item category or account assignment choice found in the data.

EKKO is the header table every EKPO row belongs to. EKET carries the delivery schedule for scheduling agreement and forecast items. EKKN carries account assignment detail per item. EKBE carries the actual goods receipt and invoice history. EBAN is the originating requisition when the PO line came from a requisition. Transaction ME21N creates purchasing documents, ME22N changes them, ME23N displays them, and MIGO or invoice verification transactions post the follow-on documents that populate EKBE while reading EKPO for reference.