SAP Purchase Order Status Tables: EKKO PROCSTAT and EKPO

There is no single purchase order status table in SAP. The header processing state lives in EKKO-PROCSTAT, the item-level indicators live on EKPO as ELIKZ, EREKZ and LOEKZ, the outstanding delivery quantity is derived from EKET, vendor confirmations sit in EKES, and the goods receipt and invoice history sits in EKBE. Message status is a separate thing again, recorded in NAST and covered in the purchase order output determination reference. Anyone who goes looking for one status field and one status column is going to build a report that quietly disagrees with ME2N. This is the field-level map, the values each field takes, and the joins that make the answers line up.

Last updated August 2026.

Which table stores purchase order status in SAP?

Status is spread across six tables because SAP tracks several different things that people all call status: where the document sits in its approval lifecycle, whether the goods arrived, whether the invoice arrived, whether the vendor acknowledged the order, and whether anyone deleted a line. Each of those has its own home. Start from this map and the rest of the article fills in the values.

Two of those deserve care straight away. EKET is a schedule line table, so an item with three delivery dates has three EKET rows, and a query that joins EKKO to EKPO to EKET without aggregating will multiply your line count. EKBE is a history table, so it holds one row per movement rather than one row per item, and the same item appears again for every goods receipt, every reversal, and every invoice.

What is EKKO-PROCSTAT and what do its values mean?

EKKO-PROCSTAT is the purchasing document processing state, and it is the closest thing SAP has to a single header status field on a purchase order. It describes where the document sits in the version and release lifecycle, not whether anything has been delivered. These are the values you will see:

The most common report bug here is treating PROCSTAT 05 as the definition of an open order. It is not. It says the order was approved, and says nothing at all about whether a single item has been received or invoiced. An order can sit at 05 for a year after it was fully delivered and closed.

Why does the PO header processing state not match version management?

Because they are two different fields on two different tables, and SAP has a knowledge base article specifically about people conflating them. The header field shown as Proc. state is EKKO-PROCSTAT. The Processing state column on the Version Management tab is EREV-BANPR, a field on the version table EREV that describes the state of a particular version, not the document. If your report reads one and your users read the other on screen, they will disagree, and neither of them is wrong.

A related trap: the rejected state does not always survive a change. SAP documents cases where a rejected purchase order status resets after any subsequent change to the order, so a snapshot of PROCSTAT 08 taken today is not proof that the order was never reworked and approved later. If rejection history matters to you, read the change documents rather than the current field.

Which fields on EKPO show the status of a purchase order item?

Item status in SAP is a set of single-character indicators rather than one status code, and each answers a narrow question. Nearly every open-purchase-order report in existence is built out of these seven fields.

What is the purchase order release status table in SAP?

Release status is carried on EKKO itself rather than in a separate status table. EKKO-FRGKE holds the release indicator, EKKO-FRGZU holds the codes that have signed off so far as a string of positions, and EKKO-FRGRL flags a document that is subject to release and not yet fully released. The strategy that produced those values is identified by EKKO-FRGGR, the release group, and EKKO-FRGSX, the release strategy.

The Customizing behind them lives in the T16F family, with the strategies in T16FS and the codes in T16FC. That side has its own quirks, including the fact that release characteristics must reference the communication structure rather than EKKO directly, which is covered in the reference on the SAP PO release strategy tables T16FS, T16FC and EKKO. For status reporting the practical rule is simpler: filter on FRGRL rather than FRGKE when you want documents that are still waiting on somebody, because FRGRL is the flag SAP itself uses to mean not yet released.

How do I find purchase orders still to be delivered in SAP?

The quantity still to be delivered is not stored. It is derived, and the derivation is the reason two reports on the same data set disagree.

The standard report ME2N with selection parameter WE101 is the reference implementation. It selects items where the goods received quantity is less than the scheduled quantity from EKET, and where the delivery completed indicator on EKPO is not set. Both conditions matter. An item can be short on quantity and still be closed because a buyer ticked ELIKZ, and an item can be fully received and still be open because nobody did. A query that checks quantities but ignores ELIKZ will report closed orders as open, which is exactly the discrepancy people bring to their SAP team.

The neighbouring parameters are worth knowing so you pick the right one. WE102 lists items where goods receipts exist, and WE103 covers the open goods receipt case. Combining several selection parameters in one run does not behave the way most people expect, and SAP has published knowledge base articles on ME2L and ME2N returning results that look wrong when parameters are stacked. Run them one at a time if the numbers matter.

SELECT k~ebeln, p~ebelp, p~matnr, p~menge AS ordered,
       SUM( t~wemng ) AS received, p~elikz, p~erekz
  FROM ekko AS k
  INNER JOIN ekpo AS p ON p~ebeln = k~ebeln
  INNER JOIN eket AS t ON t~ebeln = p~ebeln AND t~ebelp = p~ebelp
 WHERE k~bstyp = 'F'          "purchase orders only, not RFQs or contracts
   AND k~loekz = @space        "header not deleted
   AND p~loekz = @space        "item not deleted or blocked
   AND p~elikz = @space        "delivery not flagged complete
   AND p~stapo = @abap_false   "drop statistical lines
   AND p~wepos = @abap_true    "a goods receipt is actually expected
 GROUP BY k~ebeln, p~ebelp, p~matnr, p~menge, p~elikz, p~erekz
 HAVING SUM( t~wemng ) < p~menge
 INTO TABLE @DATA(lt_open).

Aggregating EKET rather than joining EKBE is deliberate. EKET-WEMNG already carries the received quantity per schedule line, so you avoid the row multiplication you get from a history table that holds one row per movement including reversals. If you do need the movement detail, go to EKBE and filter on VGABE, where 1 is a goods receipt and 2 an invoice receipt, rather than trying to interpret BWART on its own.

Which table stores purchase order confirmations in SAP?

EKES, the vendor confirmations table. It holds what the supplier told you, which is a different thing from what the buyer ordered and a different thing again from what arrived. EKES-EBTYP is the confirmation category, checked against table T163E, and the two you meet constantly are AB for an order acknowledgement and LA for a shipping notification or inbound delivery.

Which categories the system expects for a given item is decided by the confirmation control key on EKPO-BSTAE. If BSTAE is blank, no confirmation is expected and EKES will be empty no matter how many emails the vendor sent. EKES-DABMG holds the reduced quantity, which is how SAP records that a later confirmation superseded an earlier one, and ignoring it is how confirmation reports end up double counting.

What is the purchase requisition status table in SAP?

EBAN, and the field is EBAN-STATU, the processing status of the requisition. It records what the requisition turned into rather than an approval state:

Do not read EBAN-STATU as an approval status. Requisition release works the same way as purchase order release, through the FRG fields, and EBAN-BANPR is a processing state field in its own right. SAP has published notes going back decades on requisitions staying at status N even though an order exists, so if the field looks wrong the answer is usually a known inconsistency rather than a data entry mistake.

Why do two purchase order status reports disagree?

Nine times out of ten it is one of five things, and they are worth checking in this order.

Deleted lines were not excluded. LOEKZ is on both EKKO and EKPO and it is not a boolean, it is a character field where L means deleted and S means blocked. A query written as LOEKZ = space is correct, a query written as LOEKZ <> "L" silently keeps blocked lines.

Document category was not filtered. EKKO holds more than purchase orders. EKKO-BSTYP distinguishes them, with F for purchase orders, A for requests for quotation, K for contracts and L for scheduling agreements. Leaving it out is how a purchase order report ends up counting contracts.

The delivery completed indicator was ignored. Covered above, and it is the single biggest source of the gap between a custom report and ME2N.

Statistical and no-goods-receipt items were counted. STAPO and WEPOS exist precisely to tell you these lines do not behave like normal ones.

The underlying tables are genuinely out of sync. This is the uncomfortable one. SAP publishes guidance on inconsistencies between EKES, EKET and EKBE, because confirmations, schedule lines and history are updated by different processes and can drift after cancellations, reversals and partial deliveries. When the numbers cannot be reconciled by query logic, the answer is a consistency check rather than a smarter join.

The same caution applies when this data leaves SAP. Teams that keep an open-order dashboard alive by connecting the ERP tables to the systems that read them tend to find the drift early, because the mismatch shows up as a reconciliation break rather than as a question in a monthly meeting.

The short version

Header lifecycle: EKKO-PROCSTAT, with 05 meaning fully released and nothing more. Approval: EKKO-FRGRL, FRGKE and FRGZU. Item closure: EKPO-ELIKZ for delivery and EKPO-EREKZ for invoicing. Outstanding quantity: derived from EKET-MENGE against EKET-WEMNG, with ELIKZ as the override. Vendor promises: EKES. What actually moved: EKBE. Upstream: EBAN-STATU. Get those seven right and your report will agree with ME2N.

If you want the wider table map behind these fields, the reference on EKKO and EKPO SAP purchase order tables and joins covers the structure, and purchase order history in SAP covers EKBE and the reporting transactions in detail. For the orders that never make it into SAP as data in the first place, because they arrived as a supplier PDF, the purchase order to SAP extraction page covers turning those documents into rows.