10.4 Clean Core: Definition, Benefits, the Five Principles, and Clean Core Levels

Clean Core: Definition, Benefits, the Five Principles, and Clean Core Levels

The C_TS462 learning journey includes the course Introducing RISE with SAP Methodology for SAP Partners and Customers (SL_RISE419). About half of that course explains clean core, because an implementation consultant decides every day whether a requirement is solved with standard configuration, a clean extension, or a modification that will make future upgrades harder. In the system-based assessment you configure Sales in an SAP S/4HANA Cloud Private Edition system; clean core explains why the tasks use standard customizing and apps rather than custom code.

What a Clean Core Is

The course defines a clean core as a system that is as close to standard as possible, running cloud-compliant extensions and integrations that are created with standardized guidelines and best practices from SAP. Clean core does not mean "no customization". It means customization only where it adds competitive value, built in a way that does not block upgrades.

The course compares this with a new smartphone:

• Optimized out-of-the-box functionality: the standard system works efficiently in its delivered state and readily takes updates.
• Strategic customization: adding apps is fine, but excessive modifications hurt performance; customize where it differentiates the business.
• Effortless updates: a streamlined device updates easily; a clean core makes system upgrades smooth.
• Consistent long-term performance: staying close to the optimal state keeps the system reliable.

Why now? The course names transformation headwinds: markets change quickly, new technologies such as AI must be adopted, supply chains are disrupted, and customer preferences shift. A company with a heavily modified ERP cannot adapt fast enough.

Benefits for Users, IT, and the Company

The course uses the example of Gritty Pixel, a media production company with a fragmented SAP ECC system, separate non-SAP inventory and sales systems, interfaces between them, and large amounts of duplicated data.

The Five Clean Core Principles

Each principle has a mantra in the course:

Operations is described as the ongoing discipline of running the system so that it stays clean. For RISE with SAP customers, the Operations View of the RISE with SAP Methodology Dashboard shows a system health score and KPIs calculated daily from SAP Cloud ALM metrics, with up to 30 days of history.

Extensions: Released APIs and the Clean Core Level Concept

A clean extension rests on two pillars: it uses released APIs (any ABAP repository object, such as a data element, CDS view, or class, that SAP has released and keeps stable across upgrades), and it follows the extensibility model, which places an extension either on-stack (in SAP S/4HANA) or side-by-side (on SAP BTP). Side-by-side keeps the core cleanest, but some use cases, such as implementing a BAdI, need an on-stack implementation.

For SAP Cloud ERP Private and on-premise systems, which contain existing custom code, SAP introduced the clean core level concept:

Customers should use levels A to C in that order of preference. An extension takes the level of its least clean component: an ABAP class that uses two released APIs (level A) and one classic API (level B) is a level B extension as a whole.

Technical Debt and Its Governance

The course defines technical debt as any customization that deviates from the standard, upgrade-stable SAP code base and architecture and therefore makes future maintenance and innovation more complex and expensive. It names these forms:

• Modifications to SAP standard code
• Clones of standard programs, which no longer receive SAP updates
• Old-school, tightly coupled enhancements: user exits, classic BAdIs, and implicit enhancements

Technical debt should be an informed decision that is documented and managed. The course proposes continuous governance for every new extension:

1. Requirement: check whether standard SAP features or SAP Best Practices content can meet the need, and confirm the business value (for example, through a Solution Standardization Board).
2. Design: choose the technical approach with clear guidelines and the SAP Application Extension Methodology, using the levels to guide architecture decisions.
3. Implementation: follow development guidelines, prefer no-code or low-code options, and document technical debt transparently.
4. Deployment: run mandatory checks with the ABAP Test Cockpit on transport release, with a documented exemption process.

Governance is a must for greenfield projects, and in brownfield systems every net-new development should follow the same cycle. Measuring technical debt with KPIs helps a company set realistic reduction goals.

A Sales Example: Clean Field Extension versus User Exit

Suppose the sales department wants a Sustainability Rating field on the sales order that also appears on the delivery and the invoice.

Clean approach (key-user extensibility, level A): In the Custom Fields app, create the field in the business context Sales: Sales Document and activate the business scenarios that copy it from the sales document to the delivery and to the billing document. When you publish, the system generates the database extensions, the CDS extensions, and the copy logic. Then use Adapt UI to place the field on the screen. No ABAP code is written, and the extension survives upgrades.

Classic approach (technical debt): Append the field to VBAK, LIKP, and VBRK and fill it in user exits such as USEREXIT_MOVE_FIELD_TO_VBAK in include MV45AFZZ (sales order) and in delivery and billing copy routines. User exits work directly on the program's global data, which makes errors in custom code affect standard processing and creates upgrade effort. In clean core terms, such code is technical debt and should be replaced over time, for example by released Cloud BAdIs for sales documents, which receive defined parameters and do not allow database commits.