Purchase order approval is often discussed as a workflow topic, but in SAP it is also a very concrete configuration and system-behavior topic. Many approval problems come from details that are easy to ignore.
Which fields determine the approval strategy
Standard purchase order release strategy mainly uses header-level fields from CEKKO, such as company code, purchasing group, purchasing organization, document type, net order value, supplier, Incoterms, plant, material group, and purchasing version. Additional fields can be introduced through enhancement.
When line-item fields are used, the aggregation logic must be understood. For example, if all PO items belong to the same plant, that plant can be passed to the header-level strategy. If items contain different plants, the system may pass a blank value and then search for a strategy by blank value.
Some fields must use database values rather than display values. Cost center, material number, version, and supplier may need leading zeros; item category may need the internal number rather than the external code shown to the user.
Why the strategy does not work as expected
A practical check is to use CL20N or CL30N to verify whether the classification values can find the correct and unique strategy. Many issues are not caused by workflow logic, but by inconsistent class assignment or incorrect characteristic values.
Modification after approval is the real difficulty
After a PO has been approved, three questions must be answered: can it be changed, will a change reset approval, and which change scenarios should trigger re-approval?
SAP controls this through Changeability. The standard logic distinguishes value increase, new strategy caused by field changes, and a special case where the PO has already been output to the supplier.
For example, if the total amount increases, re-approval may be triggered. If the purchasing group changes but still maps to the same approval code, approval may remain valid; if it maps to a different approval code, the strategy may be reset.
Output changes the business meaning
A successfully output PO may already have been sent to the supplier by print, email, or EDI. In that case, modification and cancellation of approval have a different business meaning. If the design ignores output status, the system may either block legitimate changes or allow changes without enough control.
Some projects use standard changeability settings, while others add configuration-driven enhancement so that changes to delivery date, payment terms, quantity, storage location, or other fields can trigger re-approval according to PO type.
So PO approval should not be designed only as a chain of approvers. It should be designed as a controlled purchasing behavior: which fields decide approval, which changes reset approval, and what happens after the supplier has already received the order.