Short Dump Blog - Updated 5/7/2026 - 8 min read
BAdI vs User Exit in SAP: what is the practical difference?
A practical comparison of SAP Business Add-Ins and classic user exits for consultants and ABAP developers working with S/4HANA and GTS.
Author: Rastislav Janak / s4hanahub team
Problem definition
Enhancement work often starts with the dangerous sentence: "We just need a small exit." Many serious SAP side effects began life as a small exit, then grew up, got transported, and started blocking documents in silence.
The uncomfortable question
Are we choosing BAdI or user exit because it is the right extension point, or because it was the first place where the debugger stopped?
BAdIs and user exits are not only technical hooks. They are decision points where project teams decide how much custom logic they are willing to carry into support, upgrade and audit.
The practical difference matters less as a vocabulary quiz and more as governance. Interface, call timing, filters, update context and ownership decide whether an enhancement is elegant or merely well-hidden.
Here is the project version: SAP enhancement work usually starts with one question: should the requirement be implemented with a BAdI or with a user exit? That sounds simple, which is how SAP topics lure us into underestimating them.
Both extension techniques allow customer logic to be inserted into SAP standard processing, but they differ in architecture, discoverability, lifecycle behavior and how cleanly they fit modern S/4HANA projects.
The SAP evidence trail is less romantic: A Business Add-In, usually shortened to BAdI, is an object-oriented enhancement concept. A BAdI definition exposes an interface, and one or more implementations provide the customer-specific logic. In a clean demo this takes minutes; in production it asks for ownership, variants and a little courage.
In practice this makes the enhancement easier to structure, test and transport than older procedural exits, especially when the BAdI supports filters or multiple active implementations.
This is where the support ticket usually starts: A user exit is usually older and more procedural. Many user exits are delivered through SMOD/CMOD enhancements and function module exits. The screen is only the stage. The process is the plot.
They are still very important in real systems because logistics, finance, SD, MM and foreign trade processes often contain proven user exits that are already part of productive customer designs.
The control angle is the part worth underlining: The practical selection rule is simple: if SAP delivers a relevant BAdI for the process step, start there. BAdIs are normally more explicit, easier to search by interface or implementation class, and better aligned with enhancement spots and modern ABAP design. A consultant should be able to explain this without opening a thirty-slide apology deck.
If the process only exposes a user exit, then the user exit may still be the correct and supported place for the requirement.
For training, the useful lesson is this: In SAP GTS and S/4HANA projects, the most important analysis step is call context. That is the difference between technical navigation and knowledge people can reuse.
Developers should identify where the enhancement is called, which document or communication structure is available, and whether the logic runs during simulation, save, transfer, output, compliance check or customs processing. The name alone is rarely enough.
Here is the project version: For maintainability, document every enhancement with business process, trigger point, input structures, expected side effects and a short rollback approach. This makes BAdIs and user exits searchable knowledge assets instead of hidden custom code. That sounds simple, which is how SAP topics lure us into underestimating them.
A good enhancement is boring in production. It does its job, leaves evidence, and does not require a heroic consultant to remember why it exists.