Clean Core

Clean core is often reduced to "no custom code", which is not what SAP describes. The principle concerns how a system deviates from standard, not whether it does:

• Extensions use released APIs and extension points, so SAP can change internals without breaking them.
• Configuration is preferred over code wherever the standard offers a setting.
• Integration runs through released, documented interfaces rather than direct table access.
• Data and operations follow current standards, so the system stays supportable.

A system can carry many extensions and still be clean, as long as each one depends only on what SAP has committed to keep stable. Clean core is therefore a rule about dependencies, not a ban on differentiation.

SAP's current guidance classifies custom objects into four levels, which SAP Cloud ALM uses to report a clean core share:

Earlier SAP material describes a three-tier extensibility model with comparable intent, and both vocabularies still appear in SAP documentation. The clean core levels turn the principle into something a team can measure object by object.

• Predictable upgrades: extensions that use only released APIs keep working across releases, which reduces regression testing and upgrade projects.
• Cloud compatibility: the same rules apply in SAP S/4HANA Cloud Public Edition, so an on-premise team following them keeps its options open.
• A shared decision ladder: standard first, then key user extensibility, then developer extensibility, then side-by-side gives architects and consultants a common language.
• Measurability: ABAP Test Cockpit checks and the level classification make progress visible instead of anecdotal.
• Lower long-term cost: fewer modifications mean fewer adjustments during support package and release changes.

For any organization that wants to stay on current SAP releases, clean core is the extension policy that SAP's own tools and guidance are built to support.

• It does not decide what to build. Clean core governs how an extension depends on SAP, not whether the requirement behind it is worth building.
• It moves complexity rather than removing it. A side-by-side extension is clean for the core, but it adds integration, identity, monitoring and a second lifecycle.
• API coverage is uneven. Where no released API exists, teams fall back to level C or wait, and that gap is a frequent complaint in practitioner communities.
• Legacy code takes years. Large ECC-era code bases move level by level; the measurement shows the distance, not the path.
• Ownership is outside the scope. An extension can be perfectly clean and still lack an owner, documentation or a link to the process it supports.

Clean core keeps the ERP upgradeable; ownership, process design and the cost of the surrounding landscape remain separate questions.

Work down this ladder and stop at the first option that meets the requirement:

1. Standard or configuration. Can a setting, a business role or a delivered app cover it?
2. Key user extensibility. Is it a custom field, a check, a default value or a UI adaptation? Alder Manufacturing's need for a supplier rating field on purchase orders ends here.
3. Developer extensibility. Does it need custom ABAP close to SAP S/4HANA data and transactions? Build it with ABAP Cloud on-stack.
4. Side-by-side on SAP BTP. Does it serve external users, combine several systems or need its own lifecycle? A self-service portal for Cedar Office Supply belongs here.
5. Classic extension. Only with a documented exception, an owner and a plan to move up the levels.

The clean core decision is made per requirement, and the reason for each choice should be recorded where architects can find it later.

1. Treating it as a one-time cleanup. Without checks in the development process, new level C and D objects appear after the project ends.
2. Banning level C outright. Some requirements have no released API yet; a monitored level C object can be the honest choice.
3. Counting objects instead of risk. One modification in a central posting routine weighs more than many unused reports.
4. Moving everything to SAP BTP. Side-by-side is not automatically cleaner if the extension still needs unreleased interfaces.
5. Forgetting the UI layer. Copied and modified SAP Fiori apps carry their own upgrade risk; SAP's UI extension mechanisms, such as adaptation projects, are the safer route.

Most clean core failures are governance failures that show up later as upgrade effort.