SAP Release strategy

A release strategy defines who must approve a PR or PO, and under what conditions (e.g. based on value, plant, material group). The document is blocked until the required approvers "release" it, at which point it can be ordered or issued. It enforces spend authority and segregation of duties in procurement.

• Release conditions: when a strategy applies (value, org, group).
• Release codes & levels: the approvers and sequence.
• Release indicators: what is allowed at each step.
• Blocked until fully released.

One behaviour worth knowing early: a document subject to release cannot be printed or transmitted to the vendor until it is released, and it cannot be received against. So a release strategy does not merely record approval, it holds the whole downstream process, which is what distinguishes it from a notification-based approval.

Release strategies use classification, which is an unusual mechanism and the reason the configuration feels indirect. Four objects, built in order.

Characteristics are the fields the strategy looks at, defined with reference to the purchasing document's communication structure: the total value, the purchasing group, the plant, the document type, the material group. Each characteristic points at one field.

A class of the release type groups those characteristics. There is normally one class for requisitions and one for purchase orders.

A release group ties the class to the document type.

Release codes represent approvers, and a release strategy is a combination of characteristic values with the codes required, in sequence or in parallel.

So a strategy might read: purchase orders, purchasing group A, value over fifty thousand, requiring release by the buyer then the department head then finance. Below that value, one code. Below another, no strategy applies at all and the document is released on creation.

The indirection is what allows a strategy to depend on any field without configuration per field, and it is also why the first strategy anybody builds takes an afternoon and the tenth takes ten minutes.

An hour, and it is the only way the classification mechanism becomes clear.

1. Create a characteristic for the total net order value, referencing the communication structure field.
2. Create a class of the release type and assign the characteristic.
3. Create a release group for purchase orders and a release code for an approver.
4. Create a strategy with a value threshold and that code.
5. Raise a purchase order below the threshold. No strategy applies and it can be received against.
6. Raise one above it. The order is subject to release, and a goods receipt is refused until it is released with ME29N.
7. Now change the released order's value upward and check whether the release resets. Whether it does is configuration, and it is the difference between a control and a formality.

Step seven is the one to verify on any existing system, because an approved order whose value can be doubled afterwards was not really approved.

Release strategies are a core financial control, they prevent unauthorised or excessive spend and provide an audit trail of approvals. They are configured to mirror the organisation’s approval hierarchy and thresholds. Misconfiguration either blocks legitimate purchasing or lets spend through unapproved.

It is also the control auditors ask about first in procurement, alongside vendor creation. The questions are consistent: what thresholds apply, who holds the release codes, whether a person can release their own document, and whether changing an approved document resets the approval. Being able to answer those from configuration rather than from memory is what a review needs.

• Requisitions or orders. Releasing requisitions catches spend before commitment, which is usually the right place. Releasing orders catches it before it reaches the vendor. Some businesses do both, which doubles the approvals.
• How many levels. Each level is a real delay. Thresholds should mean that routine purchases pass quickly and only significant ones climb.
• Whether release resets on change. It should, above a tolerance, or approval means little.
• Who covers absence. A release code held by one person on holiday stops procurement, so substitution has to exist.

Purchasing approval can be built several ways and knowing why release strategies are the default helps when somebody proposes an alternative.

Release strategies are configuration, they sit on the document, and they physically prevent the next step until released. That last property is what makes them a control rather than a notification: an unreleased order cannot be received against.

Workflow routes a task to a person's inbox with reminders, escalation and substitution. It is better at getting somebody's attention and, on its own, does not block anything. The strong pattern is both: the release strategy blocks and workflow notifies.

Approval in a procurement front end, such as a cloud buying application, happens before the document reaches the ERP at all. That suits organisations where requisitioning is done outside SAP, and the ERP then receives an already-approved order.

Budget availability control is a different control that behaves similarly: a posting exceeding a budget is refused. It is worth distinguishing, because "the order was blocked" can mean either, and they are resolved by different people.

The design question is where the decision genuinely belongs, and then which mechanism enforces it.

Release strategies fail quietly. A misconfigured one does not error, it simply never applies, and the documents it should have caught flow through approved by nobody. So testing is the whole job.

Test above and below each threshold. A strategy with a fifty thousand boundary needs a document at forty-nine and one at fifty-one, because off-by-one on a characteristic value is the classic error.

Test each characteristic in isolation. If the strategy depends on purchasing group and value, vary one at a time. A strategy that triggers for the wrong reason passes a naive test.

Test the change case. Release a document, then increase its value, and confirm the release resets if it should.

Test that unaffected documents are unaffected. A strategy that catches everything is as wrong as one that catches nothing, and it is more visible.

Check the release simulation on the document, which shows which strategy applied and which codes remain, and is the fastest confirmation that configuration reached the document you expected.

None of this is difficult and all of it is skipped, which is why "the approval was not required" is a common audit finding rather than a rare one. See procurement for the cycle this controls.

• Misconfigured conditions, wrong docs caught or missed.
• Approval bottlenecks from over-complex strategies.
• No release strategy, uncontrolled spend.

• Thresholds so low that everything needs approval. Approvers stop reading and click through, which is worse than no control because it looks like one.
• Characteristics referencing the wrong field. The strategy then never triggers, and nothing warns you.
• No substitute for an approver. See invoice verification and inventory for the controls downstream of this.

• Release codes assigned to individuals rather than to roles. The person leaves and the approval route breaks in a way that takes a day to diagnose.

Releasing a document is one click, and building the classification behind a strategy that catches the right documents is the part you do in the course.

The single check worth running on any existing strategy: release a document, increase its value materially, and see whether the release resets. If it does not, the approval is decorative and nobody has noticed.