SAP Clean Core: What It Is, Levels A to D, and What to Do with Z Code

Clean core is SAP's term for an ERP system kept as close to standard as possible: on a current release, with cloud-compliant extensions and integrations, good data quality, and sound process design. It does not ban custom code. It requires every extension to stay separate from SAP's code and to depend on interfaces SAP commits to keeping stable, and it grades that dependency on four levels, A through D.

What you are allowed to do depends on the edition. In SAP S/4HANA Cloud Public Edition, development runs on ABAP Cloud and only Level A is accepted. In SAP S/4HANA Cloud Private Edition and SAP S/4HANA on-premise, classic ABAP is still available, clean core is an SAP recommendation, and the right to modify standard code depends on the contract you signed. That is why the custom code inventory has to be finished before the edition is chosen.

The full comparison of editions is in What is SAP S/4HANA, and the responsibilities inside an SAP cloud contract are in RISE with SAP.

What SAP means by clean core

In the course Managing Clean Core for SAP Cloud ERP, SAP defines a clean core as an up-to-date ERP system on the latest releases, with cloud-compliant extensions and integrations, good primary data quality, and good process design. The concept has five dimensions: business processes, extensibility, data, integration, and operations.

For extensibility, the principle is to decouple extensions from standard, resting on two things: using released APIs and following the SAP S/4HANA Cloud extensibility model. The same course states that the approach does not mean avoiding customization. The declared payoff is the upgrade: the less an extension depends on SAP-internal objects, the less it breaks when the release changes.

ABAP Cloud vs. classic ABAP: where each one applies

ABAP Cloud is SAP's cloud-ready ABAP development model, which accesses only released APIs and extension points. Classic ABAP is ABAP development without that restriction, the model in which the Z code of an ECC system was written. The table shows where SAP offers each one, according to SAP's ABAP Cloud FAQ as of October 2026.

Product	ABAP Cloud	Classic ABAP
SAP BTP ABAP environment	All releases, mandatory	Not applicable
SAP S/4HANA Cloud Public Edition	Since release 2208 for new customers, mandatory	No unrestricted classic ABAP
SAP S/4HANA Cloud Private Edition	Since release 2022, recommended	Available
SAP S/4HANA on-premise	Since release 2022, recommended	Available

For Private Edition and on-premise, SAP recommends using ABAP Cloud as much as possible and keeps classic extensibility available and supported. Clean core compliant extensions can also be built with classic ABAP, provided they follow the level rules.

Extension types and Levels A to D are two different classifications

The first classification says where an extension is built and with which tool. The second says which SAP objects it depends on.

The three extension types

• Key user extensibility: simple extensions made by business key users with low-code or no-code tools inside the ERP, such as custom fields and logic at released extension points.
• Developer extensibility: extensions that need code, built by developers inside the ERP using ABAP Cloud.
• Side-by-side extensibility: applications built and run outside the core on SAP Business Technology Platform (SAP BTP), talking to the ERP through released interfaces.

The first two run on the ERP itself (on-stack). SAP prefers side-by-side and acknowledges that cases such as a BAdI implementation require local code.

Levels A, B, C, and D

The table gives the definition and examples for each level from SAP's training material as of October 2026.

Level	What the extension uses	Examples given by SAP	SAP's assessment
A	Only released APIs and extension points, backed by stability contracts	On-stack extension in ABAP Cloud or with key user tools; side-by-side application on SAP BTP	Preferred approach and the only level accepted in Public Edition
B	Classic APIs that SAP considers stable although they are not released	A wrapper around a BAPI such as BAPI_PO_CREATE1; classic ALV	Also preferred in Private Edition and on-premise
C	SAP-internal objects with no compatibility guarantee	Direct use of internal function modules and classes; read access to SAP tables not intended for external use	Manageable risk; SAP publishes a changelog so incompatible changes can be spotted early
D	Non-recommended objects and techniques	Modifications, implicit enhancements, and unsupported write access to SAP tables	Highest risk and technical debt; not considered clean

SAP rates an extension by the lowest-ranked technology it uses: in the course example, an ABAP class with two released APIs and one classic API is Level B. The Cloudification Repository, which SAP maintains on GitHub, lists released and classic APIs, and the ABAP Test Cockpit (ATC) runs the code checks.

Type does not determine level. A developer extension in Private Edition can be A, B, C, or D depending on what the code calls.

What each edition accepts: modifications, add-ons, and Z code

The table compares the three S/4HANA deployments on what a customer may do in code. Sources are SAP documentation and the Private Edition contract supplement, version v.10-2026, the one in force in October 2026.

Topic	Public Edition	Private Edition	On-premise
Modifying SAP objects	Not permitted	Right granted only for the offerings named in section 3.4.3 of the supplement; not permitted for customers also subscribed to SAP extended services	Technically available; SAP recommends clean core
Add-ons	Classic ECC add-ons cannot be installed	Customer ABAP Add-ons, SAP-provided Add-ons, and certified Additional Add-ons; with SAP extended services, only the last two	Subject to compatibility with the release
Z code in classic ABAP	Not accepted	Accepted; installation, management, support, and testing stay with the customer	Accepted

The contractual limit for Private Edition sits in the supplement's definitions. An Add-on is a development that adds new and independent functionality without modifying existing SAP functionality. A Modification is a change to the delivered source code or metadata, and also any other development that customizes, enhances, or changes existing functionality. The definition is broad, and the right to develop Modifications appears only for the RISE with SAP S/4HANA Cloud, private edition offerings listed in section 3.4.3.

The same document takes Customer ABAP Add-ons out of the SLA and requires the customer to run simplification and incompatibility checks at every upgrade. The supplement is versioned: the version referenced in your Order Form is the one that applies, and the name of the offering you bought has to be checked against the list in that section. The other differences between the two clouds are covered in SAP Cloud ERP public vs. private.

How to inventory Z code before a RISE or conversion project

The steps below come from the Conversion Guide for SAP S/4HANA 2025, updated on October 7, 2026, and from the course Practicing Clean Core Extensibility for SAP S/4HANA Cloud.

1. Measure real usage in production. SAP points to the ABAP Call Monitor (transaction SCMON) or Usage and Procedure Logging (UPL), not both at once, for 6 to 18 months, covering at least one year-end closing. Transaction SUSG aggregates and keeps the SCMON data, which is deleted after a short time.
2. Run SAP Readiness Check early in planning. It identifies the relevant simplification items, gives a high-level custom code analysis, and checks add-on compatibility.
3. Check the code against the S/4HANA simplifications. The Custom Code Migration tool, available as an SAP Fiori app, and ATC list where Z code no longer complies with the scope and data structure of SAP S/4HANA. SAP warns that the checks do not yet identify every case, so testing in the target system is still required.
4. Retire what is not used. The Custom Code Migration app combines the analysis with usage statistics and generates a deletion transport request that the Software Update Manager consumes during conversion.
5. Review modifications, copies, and enhancements. Transactions SPDD, SPAU, and SPAU_ENH and the clone finder tool locate direct modifications, clones of SAP objects, implicit enhancements, and method overwrites. SAP's guidance is to treat this code as a candidate for removal.
6. Classify what remains by Levels A to D. Each object gets a destination: retire it, rebuild it in ABAP Cloud, or move it to the highest level possible. When a released API is missing, SAP points to wrapping the object in a custom wrapper or requesting the release through the SAP Influence channel.
7. Adapt after the technical conversion. Modifications and enhancements are adjusted with SPDD, SPAU, and SPAU_ENH, and simplification findings are fixed using ATC with the variant S4HANA_READINESS.

The transition paths and what each one carries over are in SAP ECC to S/4HANA migration.

Clean core in SAP plant maintenance: orders, notifications, confirmations, and measurements

In plant maintenance, the practical question is which interface each Z program or integration uses to read and write maintenance orders, notifications, confirmations, and measurement readings. The table lists the APIs SAP documents for Public Edition in October 2026. For Private Edition, on-premise, and ECC, availability follows the installed release and is checked there.

Object	API	Protocol	Documented operations	Communication scenario
Maintenance order	API_MAINTENANCEORDER_0002	OData V2	Read and create; changes as listed in SAP's operations table	SAP_COM_0397
Maintenance notification	API_MAINTNOTIFICATION	OData V2	GET, POST, and PATCH	SAP_COM_0397
Operation confirmation	API_MAINTORDERCONFIRMATION	OData V2	GET, POST, batch, and cancellation	SAP_COM_0398
Measuring point	API_MEASURINGPOINT	OData V4	GET, POST, and PUT	SAP_COM_0395
Measurement document	API_MEASUREMENTDOCUMENT	OData V4	GET, POST, and PUT; no deletion	SAP_COM_0398

Public Edition also has BAPIs released for specific scenarios. SAP's table of released RFC interfaces lists BAPI_ALM_ORDER_MAINTAIN and BAPI_ALM_ORDER_GET_DETAIL for orders and the BAPI_ALM_CONF family for confirmations (SAP_COM_0344), and the BAPI_ALM_NOTIF family for notifications (SAP_COM_0322). Because the table still ties those interfaces to deprecated scope items (BH1, BH2, and BJ2), being listed does not guarantee activation in a new tenant, and it does not authorize calling another BAPI.

With that in hand, a maintenance Z program can be read through the levels:

• An application on SAP BTP that creates orders through API_MAINTENANCEORDER_0002 uses a released interface and sits at Level A, on the edition and release where the API is released.
• A classic ABAP extension that calls an order or confirmation BAPI sits at Level B if SAP classifies that BAPI as a classic API, which is checked in the Cloudification Repository.
• A Z report that reads SAP tables not intended for external use sits at Level C.
• A validation in an implicit enhancement, a modification to a standard program, or a direct write to an SAP table sits at Level D.

When writing the specification, a measuring point is master data and a measurement document is the recorded reading, each with its own API and scenario.

Common misreadings of clean core

Treating the decision as Z code yes or no

SAP's model does not split the system into standard code and Z code. One Z object that calls only released APIs is Level A; another, with a direct write to an SAP table, is Level D. The useful inventory question is which SAP object each Z program depends on.

Assuming Private Edition allows everything

The technical capability exists, and the contractual right is narrower. The v.10-2026 supplement grants the right to modify only to the offerings it names and leaves testing with the customer. The level classification is not a license either: it describes code dependencies and does not authorize changes to standard.

Third-party solutions on SAP PM belong in the same inventory

Field apps, scheduling tools, and integrations with other systems also depend on SAP PM objects. For each one, ask the vendor for the object, the operation, the exact API or BAPI, the validated edition and release, the communication scenario, the component installed in SAP, and who owns testing at every upgrade. PM RUN is a maintenance execution, mobility, and planning platform that runs on top of SAP PM without replacing SAP, and it uses SAP PM on ECC 6.0 or S/4HANA, on-premise or in the cloud. The asset management in SAP page describes what the platform covers.