Clean core, level by level: what A, B, C and D mean for your custom code

"Clean core" has been SAP's guidance for years, but until recently it was hard to measure. In August 2025 SAP published a simpler model: four levels, A to D, that classify every extension by how much upgrade risk it carries. It applies to S/4HANA in the cloud and on-premise, and it gives architects and auditors a shared vocabulary.

The four levels

Level A: extend with released interfaces. The extension uses only publicly released, stable SAP APIs and extension points that come with a stability contract. That covers ABAP Cloud development on the same stack and side-by-side extensions on SAP BTP, built with SAP Build, CAP or the ABAP environment. This is fully clean.

Level B: classic APIs. Everything allowed at Level A, plus SAP's classic APIs and technologies, such as BAPIs, that are documented and generally upgrade-stable even without a formal stability contract. SAP treats this as compliant.

Level C: internal objects. The extension reads or calls SAP internal objects that are not released. This is common in older code and often works fine, but SAP can change those objects in any release. SAP plans to publish change logs for its objects so teams can spot impacts early. Partially compliant.

Level D: not recommended. Modifications to SAP code, direct writes to SAP tables, implicit enhancements and similar techniques. These carry the highest upgrade risk and are where technical debt accumulates.

Measuring where you are

The ABAP Test Cockpit is the main tool. With the current check variants, ATC can classify custom code against the levels so you get a count of objects at each one. Customers on RISE with SAP can also see clean core indicators in SAP's methodology dashboard. A useful first report shows, per application area, how many objects sit at C and D and how often they are actually executed in production.

A realistic target

Very few established SAP customers can reach Level A everywhere. A practical policy looks like this:

1. New development starts at A or B. Make it a code review rule and enforce it with ATC in the transport release.
2. Retire unused C and D code first. Usage statistics typically reveal a large amount that nobody runs any more.
3. Replace the rest gradually. When a business change touches a Level D modification, budget the work to rebuild it as a BAdI implementation, a RAP-based extension or a BTP app.
4. Track the numbers each quarter. The share of C and D objects should go down over time.

Why it is worth the effort

Every C and D object is something to check and possibly fix at each upgrade. On S/4HANA Cloud Public Edition, which upgrades twice a year, there is no room for them at all. On Private Edition and on-premise they turn upgrades into projects. Clean code also matters for AI: SAP's agents and Joule work through the same released APIs and business objects, so extensions built on them are easier to expose to new capabilities later.