SE18 — BAdI Definition Maintenance
SE18 is the transaction for creating and maintaining a BAdI (Business Add-In) definition: the hook itself, its generated interface, its filter-dependent and multiple-use settings, and its enhancement spot assignment. It contains no executable logic. The actual code that runs lives in an implementation, maintained separately in SE19, which is where most BAdI troubleshooting should really begin.
This page covers SE18, the transaction used to define a BAdI extension point and inspect its interface, filter dependency and multiple-use rules. It focuses on the recurring diagnostic trap where a not-firing BAdI is investigated in SE18 when the real problem sits in its SE19 implementation, plus interface-change and transport pitfalls that break existing implementations.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,228 words
Purpose
SE18 is the transaction where a BAdI (Business Add-In) definition is created and maintained. This is the definition side of an extension point: it establishes the BAdI's name, the interface auto-generated as IF_EX_<badi_name>, whether the BAdI permits multiple simultaneous implementations or only one, whether it is filter dependent, and which enhancement spot it belongs to. SE18 defines the hook; it contains no business logic and no ABAP coding runs from here directly. The one fact that explains most of the confusion around it: SE18 only tells a developer that an extension point exists and how it is shaped. Whether that extension point actually does anything in a given system depends entirely on the implementation, which is maintained in SE19. A ticket that reads BAdI not firing is almost never an SE18 problem.
When it is used
Reached for during custom development when a new extension point needs to be exposed inside a Z or Y development, or when investigating whether standard SAP code already offers a hook at a point of interest. A developer places the cursor on a CALL BADI or GET BADI statement in the standard code, navigates to the definition, and opens it in SE18 to see the interface signature, filter dependency and multiple-use setting before writing an implementation. Functional consultants do not normally open SE18 directly; an enhancement requirement arising from a functional gap is handed to development, who decide whether an existing BAdI already covers it or a new one is needed. Contrast with IMG activities that maintain filter values or activate an existing BAdI's business configuration; that work is downstream of SE18, not part of it.
How to use it in practice
- Open SE18, enter the BAdI name (or the enhancement spot name for spot-based BAdIs), choose Display or Change.
- If the BAdI name is unknown, locate it from the ABAP source by placing the cursor on the GET BADI or CALL BADI statement and using forward navigation, or search by enhancement spot in the BAdI Builder.
- Review the Interface tab to see the generated interface IF_EX_<name> and its methods, parameters and exceptions.
- Check the definition attributes: the multiple-use flag, the filter-dependent flag and the assigned enhancement spot.
- To create a new BAdI, work inside an enhancement spot, define the BAdI, generate the interface, add methods, and activate.
- Jump to SE19 to review or create the actual implementation, since nothing runs from SE18 alone.
Key data objects
- SXS_ATTR - attributes of enhancement-spot based BAdI definitions, including the multiple-use and filter-dependent flags.
- SXC_ATTR - attributes of classic kernel BAdI definitions predating the enhancement framework.
- TADIR - repository object entry for the enhancement spot and BAdI definition, used to confirm package, transport layer and whether the object is customer or SAP delivered.
- The generated interface IF_EX_<badi name> - not a flat table, but the interface object itself, inspected and adjusted through the class builder once the definition is saved.
How to prove it in the data
To confirm a BAdI's shape rather than trust a description passed down verbally, open SE16N on SXS_ATTR (or SXC_ATTR for a classic BAdI) filtered on the BAdI name and read the multiple-use and filter-dependent flags directly. Cross check against TADIR filtered on the same object name to confirm the package and whether it is customer-owned or SAP-delivered. If the symptom is a missing implementation rather than a definition problem, the confirming check moves to SE19, not SE18, since that is where implementation existence, filter values and activation status actually live.
ECC vs S/4HANA
SE18 and the enhancement framework it belongs to are unchanged on S/4HANA; classic kernel BAdIs and enhancement-spot BAdIs both continue to work exactly as on ECC. What changed is guidance rather than mechanics: S/4HANA extensibility classification increasingly steers custom development toward using released, stable BAdIs rather than any available hook, to protect custom code against breakage on upgrade. There is no Fiori app equivalent; this remains a developer transaction accessed through the standard GUI or an ABAP development tools environment.
Common pitfalls and how to diagnose them
- Definition vs implementation confusion - a ticket reporting a BAdI is not working gets opened in SE18 out of habit, but SE18 only proves the hook exists. Move to SE19 immediately to check for an active implementation, matching filter values, and whether it was transported to the affected system.
- Filter-dependent mismatch - if the definition is marked filter dependent but no implementation carries a matching filter value, the calling program finds zero applicable implementations. Check the filter-dependent flag in SE18 first, then check the maintained filter values on the implementation.
- Single-use vs multiple-use collision - a BAdI defined as single use permits only one active implementation. A second developer creating an implementation either gets blocked at activation or silently deactivates the first one. Check the multiple-use flag in the definition before assuming two implementations can coexist.
- Interface change breaking existing implementations - adding a method or parameter to the interface in SE18 requires every existing implementing class across the landscape to be adjusted and reactivated. Skipping a where-used check before changing an interface produces syntax errors or short dumps on activation after transport into downstream systems.
- Fallback or default class assumption - some BAdIs ship with a default implementing class that fires when no customer implementation is active. Assuming that no BAdI implemented means nothing happens is wrong if a default class exists; check for a default class entry in the definition before ruling out BAdI behavior as a cause.
- Transport sequencing - the BAdI definition and its implementations are separate transportable objects. Importing an implementation into a system without a compatible version of the definition already present produces an activation failure on import. Check version consistency between systems before assuming the implementation code itself is faulty.
- Destructive reflex fix - deleting and recreating a BAdI definition to resolve an interface problem breaks every existing implementation in every system that has it, forcing a full rebuild. The safer fix is extending the interface with a new method or an optional parameter carrying a default value, never deleting the definition.
Whose problem this is
Strictly an ABAP or development-owned transaction; functional and Basis teams should not attempt changes here. A clean handover from a functional gap to development states the business rule that needs the hook, the exact program and line where the extension point is needed if it is already known, and whether an equivalent BAdI might already exist rather than assuming a new one must be built.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se18ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.