What happens to MV45AFZZ and SD user exits in S/4HANA?
The exits still run. The real question is which are standard capability in disguise — and can be retired.
The short answer
MV45AFZZ and the classic SD user exits still technically function in S/4HANA, but clean core says stop relying on them. The better move is to read what each exit does and map it to standard capability: a static credit-limit check maps to S/4HANA FSCM (credit management), output logic maps to output management and BRF+, and pricing logic maps to the condition technique or a released BAdI. In practice many exits turn out to re-implement capability S/4 now delivers as standard and can be retired outright, while the few that encode genuine differentiation move to released extension points. The decision is not really technical — it is a business-logic question about what each exit is for.
Do SD user exits still work in S/4HANA?
Technically, yes — the MV45AFZZ include and the classic SD enhancement points still exist and execute in S/4HANA. But technical survival is not the point. Clean core guidance is to move away from core-embedded exits toward released extension points, because exits are exactly the kind of modification that makes every upgrade more expensive and more fragile. So the question is not can I keep MV45AFZZ, but should I — and for what.
The common MV45AFZZ patterns and their S/4 homes
Most sales-order exits fall into a handful of patterns, and S/4HANA has a standard home for each:
- Static credit-limit or credit-block logic — maps to S/4HANA FSCM / SAP Credit Management (UKM), delivered as standard.
- Output and print determination — maps to S/4 output management and BRF+ rules.
- Custom pricing or discount logic — maps to the condition technique, or a released pricing BAdI where truly needed.
- Field defaulting and validation — often maps to released in-app extensibility or key-user field logic.
Read the rule, then decide: retire, re-map, or re-platform
The right method is to read the business rule inside each exit before deciding its fate. An exit that enforces a static credit limit is a credit policy — S/4 FSCM does that, so you retire the exit. An exit that encodes a genuinely unique pricing rule is real differentiation — you re-platform it onto a released BAdI or the condition technique. The classification (retire, re-map to standard, or re-platform) is what turns a pile of exits into a clean, defensible plan.
Why this is a business decision, not just a technical one
Deciding to retire a credit-check exit is not a coding decision — it is a decision to adopt S/4 standard credit management and configure risk classes instead. That belongs to the business process owner, informed by evidence about what the exit actually does and how it is used. Treating exit disposition as a pure technical conversion is how teams migrate logic they should have retired, and carry it for another decade.
Frequently asked
Are SD user exits deprecated in S/4HANA?
They are not hard-deprecated — MV45AFZZ and classic exits still execute — but they are discouraged under clean core. The guidance is to move functional extensions to released extension points (released BAdIs, the condition technique, BTP) and to retire exits that merely re-implement standard capability.
What replaces MV45AFZZ in S/4HANA?
It depends on what the exit does. Credit logic moves to FSCM credit management, output logic to output management and BRF+, pricing to the condition technique or a released pricing BAdI, and simple field logic to in-app extensibility. Read the rule to choose the right home.
How do I know which exits to retire versus keep?
Read the business rule each exit encodes and check whether S/4HANA delivers that capability as standard, plus how heavily the exit is used. Exits that duplicate standard capability are retirement candidates; exits that encode genuine differentiation are re-platformed onto released extension points.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading