P2P-03
Procure to Pay
Purchase Order
Preventative
Automated
July 21, 2026
Control Description
SAP S/4HANA automatically blocks new and changed purchase orders based on their type and dollar amount, requiring someone other than the creator to approve them before they can be processed.
Risk
Unauthorized or inaccurate purchase orders could be placed and fulfilled without proper management review and approval.
Implementation Details
1, PO created (ME21N) with specific attributes e.g document type, purchasing org, plant, net order value, account assignment category, etc.
2. SAP evaluates those attributes against a set of Characteristics , the specific fields the system checks (e.g., document type, value, purchasing org) to decide which approval rules apply.
3. Those Characteristics are compared against the Release Strategy configuration (SPRO > MM > Purchasing > Release Procedure for Purchase Orders, i.e. OMGQ), which maps specific combinations of characteristic values e.g., "Doc Type = NB AND Value > $50,000" to a specific Release Strategy.
4. When a PO's attributes match a strategy's criteria, the system stamps the PO with that strategy and sets the Release Indicator to a "blocked" status. The PO can't proceed, no printing, transmitting, or goods receipt ,until it's released..
5. That strategy determines who has to approve. It carries one or more Release Codes. Each one is essentially the authorization required to release the PO. If a strategy requires multiple codes, it also defines the order: codes can approve simultaneously, or in a strict sequence (e.g., Code 01 must approve before Code 02 is even allowed to).
6. Authorization enforcement: a user can only execute the release step (ME28/ME29N) if their security role contains authorization object M_EINK_FRG with the matching Release Group (FRGGR) and Release Code (FRGCO) values.
Test Procedures
A) Test of Design
1 - Obtain a copy of the organization's current Signature Authority Matrix or spending approval policy.
2. Access SPRO > Materials Management > Purchasing > Define Release Procedures to identify active release strategies.
3. Extract release strategy data from tables VV_T16FS_2, AUSP, and T16FC using transaction SE16N
Join the extracted data to create a mapping that shows, for each release strategy:
• Document Type (the PO category that triggers the strategy).
• Purchasing Organization (business unit or location).
• Net Order Value range (monetary thresholds).
• Release Code(s) assigned (authorization identifiers required to approve).
Verify complete coverage with no gaps in monetary threshold ranges:
• Confirm that value ranges are continuous (e.g., 0-10K, 10K-50K, 50K+) with no overlaps or gaps.
• Ensure every possible PO amount falls within a defined threshold.
Compare the mapped release strategy configurations against the organization's Signature Authority Matrix.
• Verify that each PO category defined in policy has at least one corresponding release strategy with classification triggers configured in SAP.
B) Test of Operating Effectiveness
• Perform transaction tests to verify that purchase orders route to the appropriate users for approval based on the release strategies and authorization limits assigned in SAP:
a) Release Strategies Trigger as Configured – Create test purchase orders with varying Document Types and Net Order Values. Verify that each PO routes to the correct approval queue based on the release strategy mapping documented in the Test of Design (Procedure 2). Confirm that the required release code(s) are triggered as expected.
b) Segregation of Duties is Enforced – Verify that the user who creates a PO cannot independently release or approve that same PO, even if they possess a release code. Confirm that approval must come from a different user assigned the appropriate release code.
c) Control Re-triggers on PO Value Changes – Modify the Net Order Value of an approved PO to exceed its original threshold. Verify that the release strategy is re-evaluated and re-triggers, requiring approval under the new (higher) value-based release code if applicable.
d) Authorization Limits are Enforced – Attempt release of a test PO using a user assigned a release code that does not match the strategy triggered by that PO. Verify that the system denies the release and requires a user with the appropriate release code.