Why PO confirmations go missing in SAP — and how to find them

Confirmation control keys, the EKES table and why ME2N shows a PO as open when the supplier says they confirmed it. A practical guide to finding the real gaps.

A buyer says the purchase order is unconfirmed. The supplier says they sent the acknowledgement three weeks ago. Both are usually telling the truth, and the gap between them is almost always structural rather than anyone's fault.

Here is where confirmations actually live in SAP, and why a line can look open when it is not — or look fine when it is not.

Confirmations are not a field on the PO

The instinct is to look for a confirmation date on the purchase order line. There isn't one in the sense people expect. Vendor confirmations are stored as their own records, in their own table, with a category telling you what kind of confirmation each one is.

That last table is the one that matters. A PO line with no EKES rows has had nothing confirmed. A line with EKES rows may still be short-confirmed — the supplier acknowledged 200 of the 500 you ordered — which a yes-or-no confirmation flag will happily report as confirmed.

The confirmation control key decides what counts

The confirmation control key on the PO item (EKPO-BSTAE) is what tells SAP which confirmation categories are expected for that line and whether they are relevant to planning. Two lines can be identical in every visible respect and behave completely differently because one carries a key that expects an order acknowledgement and the other carries one that expects an inbound delivery.

This is the single most common reason a confirmation report is wrong. If the key is not set on the line, nothing is expected, so nothing is ever missing — and the line quietly never appears on any exception list.

Why ME2N is not enough

ME2N with the right selection parameter will show you open POs, and you can add confirmation columns to the layout. For a one-off question this is fine. It breaks as a routine for three reasons.

1. 1The output is a list of lines, not a list of problems. Ten thousand rows where two hundred need action still has to be filtered by hand, every day.
2. 2It has no memory. Yesterday's answer is gone, so nobody can tell you whether the backlog is growing or shrinking, or how long a specific line has been sitting.
3. 3Short confirmations need quantity arithmetic across EKPO and EKES, which is not something a layout gives you.

What a useful confirmation check looks like

The rule is not "is it confirmed" but "is it confirmed, for the full quantity, and if not, how long has that been true". Three conditions, and the third is the one that turns a list into a priority.

confirmed        = EKES rows exist for the expected category
                   AND confirmed qty >= ordered qty

pending          = no confirmation after N days from PO date
                   (N is yours to set, by category)

ageing bucket    = today - PO date, grouped 0-3 / 4-7 / 8-15 / 15+

Ageing is what most manual reports miss. A confirmation pending for two days and one pending for three weeks appear identically in a spreadsheet sorted by PO number, and the three-week one is the one that will cost you.

Fix the data before measuring the suppliers

Almost every confirmation-tracking project starts by blaming suppliers and ends by fixing master data. Run these four counts on your open PO set first:

• Lines with no confirmation control key — nothing is expected of them
• Lines with no schedule line delivery date — nothing to measure lateness against
• Lines where confirmed quantity is less than ordered quantity — short confirmations hiding inside a confirmed flag
• Duplicate PO lines, which double-count every exception they appear in

Publish those four numbers before you publish a supplier scorecard. It changes the conversation from an accusation into a shared problem, and it is usually the fastest single improvement available.