✅ SAP Release Strategy — When to Use vs Standard

The approval workflow framework for PRs and POs. Many clients ask for it; many don't actually need it. This page shows when standard works, when to build a release strategy, and the full configuration walkthrough.

Senior consultant rule

Release strategy is for approval governance, NOT for blocking purchases. If client just wants "supervisor sees and approves" — release strategy is right. If they want "stop maverick buying" — also auth roles + materials master + source list combined.

1. What SAP standard does WITHOUT release strategy

✅ User authorizations control who can create PR/PO (PFCG roles)
✅ Material master restricts which materials a user can buy
✅ Source list restricts which vendors can be picked
✅ Plant-specific authorizations
✅ Workflow events fire on PO save (for custom workflows)
✅ Document type defines field selection (e.g. CapEx PO requires cost center)

Translation

Standard auth roles already control WHO can create POs and FOR WHAT. Release strategy adds: "AFTER creation, someone else must approve before the PO is binding."

2. When you actually NEED release strategy

Need	Why release strategy helps
Hierarchical approval based on value	"PO > 1L → Manager; > 5L → Director; > 50L → CFO"
Category-based approval	"CapEx POs → CFO regardless of value"
Plant-specific approval chains	"Plant Manager approves all POs for their plant"
Compliance & audit trail	SOX, internal audit, "every PO above X needs documented approval"
Segregation of duties	Buyer creates PO; different person must approve before sending to vendor
Cost center / project approvals	Project manager approves PRs for their WBS

3. Components — building blocks of release strategy

Component	What it is	T-code
Release Code	An individual approver (e.g. 01 = Manager, 02 = Director, 03 = CFO)	per release group config
Release Group	A set of release codes that work together	per release group config
Release Strategy	The complete approval chain for specific conditions	per group config
Release Characteristic	What drives strategy selection (value, plant, Purch Group, doc type, etc.)	CT04
Release Class	Container for characteristics. Type 032 for PO, 028 for PR.	CL02
Classification values	The actual conditions per strategy (e.g. value > 100K + doc type EC)	CL20N

4. Configuration step-by-step (PO release example)

Define characteristics — CT04
For PO release, common characteristics use the communication structure CEKKO:
- CEKKO-GNETW — Total PO value
- CEKKO-EKGRP — Purchasing Group
- CEKKO-WERKS — Plant
- CEKKO-BSART — Document type
- CEKKO-LIFNR — Vendor
Create release class — CL02
Class type: 032 (PO release) or 028 (PR release). Add the characteristics you defined.
Define release groups — OMGS (for PO) / OMGQ (for PR)
Example: Release Group "PO" for general purchase orders.
Define release codes
Per release group:
- 01 — Procurement Manager
- 02 — Procurement Director
- 03 — CFO
Define release strategies
Each strategy is a sequence of codes:
- Strategy "S1" — applies when value < 1L → only auto-released (no codes)
- Strategy "S2" — applies when value 1L–5L → code 01
- Strategy "S3" — applies when value 5L–50L → codes 01, 02 (both must release)
- Strategy "S4" — applies when value > 50L → codes 01, 02, 03
Set classification values — CL20N
For each strategy, define the condition values (the WHEN). e.g. for S3: GNETW = 500001 to 5000000.
Assign release prerequisites
Define which release codes must release before others (sequential or parallel).
Authorization roles — PFCG
Authorize specific users to release specific codes. Auth object M_EINK_FRG.

5. Real industry scenarios

🏭 Manufacturing — value-based hierarchy

Char: CEKKO-GNETW (total PO value in PKR)

S1: 0 to 99,999       → Auto-released (no approval)
S2: 1,00,000 to 5,00,000   → Manager (code 01)
S3: 5,00,000 to 50,00,000   → Manager + Director (01, 02)
S4: > 50,00,000          → Manager + Director + CFO (01, 02, 03)

💼 Service company — category-based

Char: CEKKO-EKGRP (Purchasing Group)

S1: EKGRP = IT0 → IT Director approval
S2: EKGRP = SRV → Operations Head approval
S3: EKGRP = CAP → CFO + Board approval

🏢 Multi-plant — plant-specific

Char: CEKKO-WERKS (plant) + CEKKO-GNETW (value)

For Plant 1100: Manager approves > 1L
For Plant 1200: Manager approves > 50K (smaller plant)
For Plant 1300: CFO approves > 1L (high-risk plant)

📊 CapEx workflow (high-control)

Char: CEKKO-BSART (doc type) + CEKKO-GNETW

If doc type = EC (CapEx PO):
  ALL values → CFO approval (regardless of amount)
  Above 10L → CFO + Board

If doc type = NB (standard):
  Value-based hierarchy

6. When NOT to use release strategy

Use case	Why standard is better
"Only authorized buyers can create POs"	That's authorization roles (PFCG), not release strategy
"Buyer must follow standard procedures"	That's training + workflow, not release strategy
"PO must reference an approved vendor"	That's source list with fix-source indicator
"Material must be approved for use"	Material master status (block at PO/MRP level)
"PO must be reviewed by quality"	That's QM-related blocking, not release strategy

Avoid over-engineering

Release strategies are powerful but complex. Each strategy = config + maintenance + user training + auth roles. Don't add a strategy for every minor variation — keep it simple. Most clients need 3-4 strategies max.

7. Try it in real SAP — step by step

Open CT04 → Display characteristic CEKKO_GNETW (delivered with standard)
Open CL02 → Display class type 032 → see how it uses CEKKO chars
Open OMGS → see existing release groups for PO
Look at any strategy → see its codes, prerequisites
Create a PO via ME21N with value matching a strategy
Note the "Release indicator" status
Open ME29N with your PO → release using your code
Run ME5F for release reminders

8. Interview Q&A

What's the difference between release procedure and release strategy?

Release procedure is the framework (overall config). Release strategy is one specific approval chain that applies under defined conditions.

Can a PO have multiple release strategies?

No — exactly one strategy is determined at PO save based on classification values. But that strategy can require multiple release codes (multi-step approval).

What's CEKKO?

The communication structure for PO release classification. Holds values like total value (GNETW), Purch Group (EKGRP), Plant (WERKS) — used as characteristics in release class 032.

Can release codes work in parallel?

Yes — define prerequisites. "Code 01 and 02 must both release before 03 can" (sequential), or "01 and 02 in any order" (parallel).

How to test which strategy applies?

Create test PO with target values, save, check release indicator. Or use simulation via SAP debugger on CEKKO determination.

Release strategy = approval workflow for PRs/POs. Components: Characteristics (CT04) → Class (CL02) → Codes → Groups → Strategies. Used when standard auth roles aren't enough — when you need hierarchical, value/plant/doc-type-based approval BEFORE PO becomes binding.

👥