EKKO table — Purchasing Document Header Table

A row in EKKO is one purchasing document header, keyed by EBELN. The document type field BSART decides what that header actually is: a standard PO, a contract, a scheduling agreement, an RFQ or a quotation, and the meaning of several other fields shifts depending on that type. The header carries vendor, purchasing organization, purchasing group, currency, payment terms, incoterms, creation data and, where a release procedure is active, the overall release status. It does not carry quantities, prices or delivery dates for individual items; those belong to EKPO and EKET. It also does not carry goods receipt or invoice history; that is EKBE. Treat EKKO as the envelope, not the contents.

MANDT restricts every selection first, then EBELN is the natural key if it is already known. Where EBELN is not known, restrict on BSART and EKORG together before adding a date range on AEDAT; selecting on LIFNR alone across a large system is expensive because vendor is not the leading index component. Avoid a full table scan filtered only on FRGKE or BSTYP, both are low-cardinality flags with poor selectivity. If the question is about value or quantity, do not query EKKO at all, go to EKPO or EKBE and pull EBELN back from there.

Symptom: a buyer claims a PO was never released for payment blocking checks. Select EKKO where EBELN equals the document number and read FRGKE. A value indicating incomplete release confirms it is stuck in the release strategy, not blocked downstream. Cross-check against the release status history in the associated release table if the strategy uses multiple steps, since FRGKE only shows the current aggregate state, not which approver is still outstanding.

EKKO remains the primary persistence table for purchasing document headers in S/4HANA; it was not replaced or split the way some FI tables were. Fiori apps and analytical reporting read purchasing data through CDS views built on top of EKKO and EKPO, but the underlying table structure and key fields described here are unchanged for standard purchasing documents. Custom ABAP written against EKKO directly still works.

A functional MM or purchasing consultant owns questions about document type behavior, release strategy configuration and header field meaning. Vendor master data disputes route to the master data or procurement operations team. Account assignment or cost object questions on a specific header belong jointly to MM and FI/CO, since the account assignment category set at header influences what EKKN allows at item level.

EKPO holds the line items and is the table almost every EKKO investigation ends up joining to for real numbers. EKET carries delivery schedule lines for scheduling agreements and split deliveries. EKBE records goods receipts and invoice receipts against the document. EKKN and EKPA carry account assignment and partner data. LFA1 supplies the vendor master. Transactions ME21N, ME22N and ME23N create, change and display these headers; ME31K and ME31L do the same for contracts and scheduling agreements.