BAdIs, User Exits and Enhancement Points Compared

All three let a customer add logic to standard SAP code without modifying it, but they differ in how the extension point is exposed. Classic user exits are subroutine calls SAP hard-coded into specific programs decades ago, implemented via a CMOD project referencing an SMOD enhancement; there is exactly one implementation slot per exit and no filtering. BAdIs are object-oriented: SAP defines an enhancement spot with an interface, and any number of customers or add-ons can implement it, optionally filtered by values such as company code or document type, managed through SE18 for the definition and SE19 for implementations. Enhancement points, both explicit (deliberately placed by SAP developers) and implicit (automatically present at the start and end of every method, form, and function module), let you inject raw source code with no interface and no naming contract at all. The one structural fact that explains most confusion: all three exist simultaneously in the same system, sometimes within the same program, and colloquial usage calls all of them 'user exits' regardless of which mechanism is actually underneath.

Use a BAdI whenever one exists for the requirement; it is the mechanism designed for extension, supports multiple implementations with filters, and survives upgrades as long as the interface signature does not change. Use a classic user exit only when the program in question predates the enhancement framework and never got a BAdI for that spot; there is no way to add a new user exit slot yourself. Reach for an enhancement point only when neither a BAdI nor a user exit covers the gap, and prefer an explicit enhancement point (one SAP deliberately inserted) over an implicit one. The mistake seen repeatedly on projects is skipping straight to an implicit enhancement point because it is easy to find in the debugger, without first checking whether a filterable BAdI already sits one layer above the same code.

Below all three sits the same thing: standard SAP source code and the kernel that executes it. User exits sit inside customer-function includes called from core programs, a mechanism that predates the enhancement framework. BAdIs sit above raw source code as a formal interface contract, defined against an enhancement spot and resolved at runtime by the kernel's BAdI processor, which decides which active implementations to call and in what order when filters are involved. Enhancement points sit at the lowest level, closest to the source itself, injected directly into the compiled program flow with no interface layer at all. The enhancement framework, comprising BAdIs and enhancement points together, formally superseded CMOD/SMOD user exits from the point it was introduced, though existing user exits remain callable and are not automatically migrated. Nothing above these three has replaced them structurally; extensibility guidance in S/4HANA changes which of the three is acceptable to use, not the mechanics of any of them.

A team needs to block saving a sales order when a customer-level credit flag is set, restricted to order types starting with 'Z'. First check SE18 for a BAdI attached to the sales order save logic; if one exists with a filter on sales document type, implement it through SE19, write the validation inside the interface method, and raise a defined exception class to stop the save cleanly. If no such BAdI exists but the program is old enough to predate the enhancement framework, check CMOD/SMOD for an SD enhancement project that exposes a relevant customer function; implement the include and call a custom function module from it. If neither a BAdI nor a classic exit covers this point, look for an explicit enhancement point SAP already inserted near the save routine; only as a last resort, insert the validation into an implicit enhancement point at the start of the save method itself, accepting that any future change to the surrounding standard code could silently orphan the logic. The order of preference here, not the specific mechanism used, is what an architect reviews.

None of the three mechanisms disappears in S/4HANA; all remain technically callable. What changes is which ones are sanctioned for new work. Clean-core guidance treats implicit enhancement points and new classic user-exit-style extensions as technical debt to avoid, since they touch or depend on standard code directly. BAdIs that SAP has explicitly released for cloud or key-user extensibility remain the accepted mechanism; BAdIs that are not released, along with any enhancement point usage in core objects, are flagged during extensibility and custom-code checks in a system conversion. Existing classic user exits already in production are generally left alone rather than ripped out, but new development is steered toward released BAdIs wherever one exists.

The developer picks the mechanism given what is actually available at the extension point, but an architect should sign off whenever the choice lands on an implicit enhancement point or a classic user exit, since both carry materially different upgrade risk than a released BAdI. The functional consultant confirms the business requirement genuinely needs custom code before any of the three gets used. Handover should record the exact exit, BAdI, or enhancement point name, any filter values applied, and whether the extension is release-compatible or purely legacy on-premise.

Read the clean-core explainer and the key-user-versus-developer-extensibility comparison next to understand which of the three mechanisms survives the shift toward restricted extensibility, and the ABAP Cloud released-API-model page to see what 'released BAdI' actually means in practice. The custom-code-migration page is the natural follow-on once an existing landscape full of user exits and enhancement points needs to be inventoried before a conversion.