SAP PO Release Strategy Tables: T16FS, T16FC, and EKKO

The release strategy itself lives in T16FS, keyed on release group (FRGGR) and release strategy (FRGSX), and the document carries its own copy of those keys on the purchase order header table EKKO. The release codes attached to a strategy sit in the eight fields FRGC1 through FRGC8 on T16FS, the codes themselves are defined in T16FC, and the groups in T16FG. On the order, EKKO-FRGKE holds the current release indicator, EKKO-FRGZU holds which codes have signed off so far, and EKKO-FRGRL flags an order that is not yet fully released.

Last updated August 2026.

The four EKKO fields that describe a purchase order's approval state

Start on the document, because that is where most questions actually begin. Every purchasing document subject to a release procedure carries its strategy on the header record, so you never have to re-derive it to know where an order stands.

The pair people most often confuse is FRGKE and FRGZU. FRGZU is the running tally: it records which of the strategy's codes have released so far. FRGKE is the consequence: the release indicator the document has landed on given that tally, which is what actually decides whether the order is changeable, printable, or blocked. A document can gain another entry in FRGZU without FRGKE changing, if the strategy needs more signatures before it moves to the next indicator.

Which table stores the release strategy in SAP?

T16FS stores the release strategies. It is keyed on FRGGR and FRGSX, the same two fields the document carries on EKKO, and each row holds up to eight release codes in the fields FRGC1 through FRGC8. That is the join almost every report needs: take FRGGR and FRGSX off the order, read the matching T16FS row, and you have the full list of codes that must release this document. The description of the strategy is in a separate table, T16FT, which is a common surprise the first time a query returns nothing but two-character keys.

The T16F* configuration tables, and what each one is for

The release procedure is spread across a family of tables that all start T16F. They are small, they are Customizing rather than transaction data, and knowing which is which saves a lot of guessing.

T16FV is the one worth understanding properly, because it is what makes a strategy sequential rather than a free-for-all. It stores the prerequisites: the rule that says code 02 cannot release until code 01 has. If your approvals appear to be jumping levels or refusing to move, T16FV is where the answer is, not the strategy row.

T16FK deserves a note too. It maps each combination of already-granted releases to the release indicator the document should carry. A strategy with n release codes produces n+1 entries in T16FK, one for the untouched state and one for each successive release. If somebody added a code to a live strategy and the orders stopped behaving, an incomplete set of T16FK entries is a common cause.

Where are release codes stored in SAP?

Release codes are defined in T16FC, with their descriptions in T16FD, and they are assigned to a strategy through the FRGC1 to FRGC8 fields on that strategy's T16FS row. A release code is deliberately not a user. It is a slot in the approval sequence. Which people can act on a given code is controlled by the authorization object M_EINK_FRG, which checks the release group and release code, so the answer to who can approve lives in role and authorization data rather than in the T16F tables.

How do I find the approver for a purchase order release strategy?

There is no approver table, and expecting one is the single most common wrong turn in this area. SAP separates the strategy from the people. The strategy tells you which codes must release the document. Authorizations on M_EINK_FRG, granted through roles, tell you which users hold each code. To answer "who can approve this PO", read FRGGR and FRGSX off EKKO, look up the codes on T16FS, then find the roles that grant those release group and release code values and the users assigned to them. If workflow is in use, the agent determination in the workflow adds another layer on top of that, and it can narrow the population further.

Which table holds the release strategy characteristics?

Not a T16F table. Release strategy determination runs on classification, so the characteristics live in the classification tables like any other characteristic in SAP. Characteristics are created with CT04 and stored in CABN, their allowed values in CAWN, and the values assigned to a specific class in AUSP. The class itself uses class type 032, which is the class type reserved for release strategies on purchasing documents, and you maintain the assignment of values to a strategy through CL20N or CL24N.

One operational detail that catches audits out: a strategy only works if its classification is active, so check the status in CL24N when a strategy that looks correctly configured never triggers. Another is that changes made directly in CL24N are not logged in the standard system for class type 032. If you need an audit trail on who changed a threshold, the change log has to be switched on for T16FS and class type 032 in O1CL, and if nobody did that before the change you are looking for, the history is simply not there.

What is CEKKO in SAP?

CEKKO is the communication structure the system fills when it determines a release strategy for a purchasing document. The C stands for communication structure. It matters because characteristics used in a release strategy have to reference a field of CEKKO, not a field of EKKO. That is the rule people run into when they try to build a strategy on a field that exists on the order but is not in the structure: the characteristic can be created, but it will never receive a value at determination time. The determination itself is done by the function module ME_REL_STRATEGIE_EKKO, which fills CEKKO from the header and item data before the classification match runs. Purchase requisitions use the equivalent structure CEBAN.

This is also why a value that is only known at item level, or only after the order is saved, is awkward to use as a release characteristic. The strategy is determined from what CEKKO holds at that moment, and totals like net order value are aggregated into it rather than read line by line.

Reading the release state in a query

The join is straightforward once you know the keys. This pulls each open order with its strategy, the strategy description, and the codes it needs.

SELECT k~ebeln, k~bsart, k~netwr, k~waers,
       k~frggr, k~frgsx, k~frgke, k~frgzu, k~frgrl,
       t~frgc1, t~frgc2, t~frgc3, t~frgc4,
       d~frgxt AS strategy_text
  FROM ekko AS k
  LEFT JOIN t16fs AS t
    ON t~frggr = k~frggr
   AND t~frgsx = k~frgsx
  LEFT JOIN t16ft AS d
    ON d~frggr = k~frggr
   AND d~frgsx = k~frgsx
   AND d~spras = @sy-langu
 WHERE k~frgrl = "X"
   AND k~loekz = ""
 INTO TABLE @DATA(lt_pending).

Filtering on FRGRL rather than on FRGKE is the trick worth keeping. FRGKE values are configuration-specific, so a report that hard-codes them breaks the moment somebody adds an indicator. FRGRL is a plain flag meaning this document still needs a release, and it survives configuration changes.

What is the difference between ME28 and ME29N?

ME29N releases a single purchasing document and is the transaction a buyer or approver normally uses, including the reset action where the strategy allows it. ME28 is the collective release: you select by release code and release group and work through a list. Neither changes the underlying tables in a different way, they both update the FRGZU and FRGKE fields on EKKO, so a report reading those fields sees releases from either route identically. For requisitions the equivalents are ME54N and ME55.

Stale Customizing entries, and why a strategy sometimes misbehaves

SAP documents an inconsistency worth knowing about before you trust a query on these tables. Entries can remain in T16FK, T16FV, T16FS, T16FC and T16FG after the corresponding Customizing settings have been deleted. A strategy that no longer exists in configuration can still have rows sitting in the tables, so a report that reads T16FS directly and assumes every row is live will show strategies nobody uses. If you are building an audit extract, cross-check against what is actually assigned on documents rather than trusting the configuration tables to have been cleaned up.

Where the release strategy sits relative to the rest of the purchase order

The release fields are on EKKO, so they travel with the header. The order's items, quantities and prices are on EKPO, its schedule lines on EKET, and its goods receipt and invoice history on EKBE. A full picture of an order for an audit usually means EKKO for the strategy and the header, EKPO for what was bought, and EKBE for what actually happened afterwards. The field-level detail for the first two is in the EKKO and EKPO reference, and the receipt and invoice side is in purchase order history in SAP.

It is also worth remembering what a release procedure does not cover. It gates the purchasing documents that exist in SAP. Spend that never becomes a purchase order in the first place, which in most US businesses now means a large share of software and cloud charges paid on a card, is invisible to every table on this page, and it usually has to be tracked against its own commitments rather than through the release strategy. Teams tightening approval thresholds sometimes discover the thresholds were never the binding constraint.

What this page does not claim to do

PurchaseOrders reads purchase order documents and returns their header fields and line items as Excel, CSV, JSON, or an API response. It does not create purchase orders in SAP, it does not release or approve them, it does not configure release strategies, and it does not write to EKKO, T16FS, or any other table described here. Those all stay in SAP. If your task is turning supplier PDFs into loadable data rather than reading what SAP already holds, that is covered in purchase order to SAP.

Related reading

For the header and item tables in full, see EKKO and EKPO. For the receipt and invoice history, see purchase order history in SAP. The equivalent schema in other systems is covered in Oracle purchase order tables and D365 purchase order tables. For the approval process itself rather than its schema, see the purchase order approval process. For how FRGRL and FRGKE sit beside EKKO-PROCSTAT and the EKPO closure flags, see the SAP purchase order status tables reference.