TL;DR
SAP clean core means keeping your ERP standard and upgrade-stable while you build business-specific changes as extensions that survive upgrades. It does not ban custom code. SAP measures it across five principles, from business processes to operations. It also grades every extension on four levels, with A as the safest and D as the riskiest. Level A uses only released, stable interfaces, while Level D covers modifications and other changes that break on upgrade. Start with an honest inventory and a correctly configured ABAP Test Cockpit baseline, then keep new work clean and pay down old debt in waves.
Key Takeaways Clean core allows custom code, as long as it sits outside the standard and uses stable interfaces. SAP replaced its three-tier extensibility model with four clean core levels, A to D, in 2025. The five principles cover business processes, extensibility, data, integration and operations, not just ABAP. ATC and SAP Cloud ALM measure progress, but an ATC still set up for the old model inflates the backlog. Reports and data pipelines that read unreleased interfaces are part of the clean core problem too. Stop new debt at the transport gate first, then retire or refactor old extensions in dependency-aware waves. Watch on YouTube
Enterprise Digital Transformation Roadmap: From Data Foundations to Agentic AI
Kanerika walks through why transformation works in order, foundations first and agentic AI after, the same logic clean core applies inside the ERP.
The Pricing Tweak That Froze an Upgrade
Picture an SAP team at a mid-sized manufacturer (an illustrative composite, not a named client). Years ago, a developer changed SAP’s own pricing routine so a large customer’s rebate would calculate the way sales wanted. Because it worked, nobody wrote it down.
Then the upgrade project started, and the modification clashed with SAP’s new version of that routine. So every order path that touched pricing had to be adjusted by hand and tested again. The go-live date moved, and then it moved again, because a small favor had become a dependency nobody could see.
That small change is what SAP clean core is designed to prevent. Rather than editing the product, you build the rebate logic as an extension that calls stable, published interfaces. The next upgrade then treats it as a passenger instead of an obstacle.
What Is SAP Clean Core?
SAP clean core is SAP’s approach to running an ERP system that stays close to the standard product and can take every upgrade without rework. The idea is about where change lives, not whether change is allowed. SAP’s own goal is to “keep the core clean, standard, and upgrade-stable while still enabling business-specific differentiation where it counts.”
SAP’s Managing Clean Core for SAP Cloud ERP course widens the picture. As of November 2026, the course describes a clean core as an up-to-date ERP system that keeps pace with SAP’s release cycle. It also asks for cloud-compliant extensions and integrations, good primary data and sound process design. In other words, code is only one part of it.
Clean Core Means Upgrade-Stable Change, Not No Change
Every enterprise has rules the standard product does not cover, such as a rebate model, an approval chain or a regulatory report. Clean core keeps those rules but moves them into extensions that depend only on interfaces SAP promises to keep stable. Because SAP then owns the contract on those interfaces, an upgrade no longer needs a line-by-line review of your code.
Clean Core vs Fit-to-Standard vs No Custom Code
Fit-to-standard is a design habit. Teams start from SAP’s standard process and only build a variation when the business case is real. Clean core is the technical rule for that variation: once you decide to build it, you build it upgrade-safe.
“No custom code” is neither of these, and it is not what SAP asks for. The common claims below show where the term gets misread.
Checklist
Enterprise Data Governance Checklist
Assess governance maturity, ownership and policies, so each clean core principle has a named owner and the system does not drift after the first cleanup.
Get the Checklist → Common claim What it actually means Clean core bans custom code Custom code is fine when it uses released or documented interfaces and stays outside SAP’s own objects Moving an extension to SAP BTP makes it clean A BTP app that calls unreleased interfaces is still fragile on upgrade A new implementation is clean forever Debt builds up again unless new work passes a quality gate It only applies to S/4HANA Cloud Public Edition The same model is recommended for Private Edition and on-premise S/4HANA, where it is a choice rather than a rule
What Clean Core Does Not Guarantee
A clean extension can still have a bug, a slow query or a weak authorization check. So regression testing, security reviews and performance work stay on the plan. Clean core reduces upgrade friction, but it does not replace the rest of good engineering.
Clean core also sits inside the bigger picture of application modernization , and our guide to legacy system modernization covers retiring aging platforms.
Why Clean Core Matters Now
SAP describes landscapes that become weighed down by custom code, undocumented changes and hard-to-maintain integrations, which slows upgrades and raises total cost of ownership. Each of those was a reasonable decision once, yet together they turn every release into a project.
SAP lists three benefits of a clean core: faster innovation, less technical debt, and easier maintenance and upgrades. It attaches no savings percentage to them, so the honest case is time. A team that stops reworking the same code at every upgrade can spend those weeks on new business requests.
For companies still on SAP ECC, the clock adds urgency. Mainstream maintenance for SAP ERP 6.0 ends at the close of 2027 , with extended maintenance through 2030 at a premium. So every modification carried into an SAP modernization program is one more item to remediate under deadline pressure.
AI readiness is the newer reason, covered in its own section below. If you plan to use SAP Joule or your own agentic AI with the ERP, start with a clean core.
The Five Clean Core Principles
SAP’s own document on the five guiding principles of clean core names business processes, extensibility, data, integration and operations. The point of the list is that a system can have tidy ABAP and still be far from clean.
The notes below give one typical risk and one control for each.
Business Processes
The risk here is a process that copies every legacy variation, so each local habit becomes a custom branch.
The control is a fit-to-standard review, where a process owner signs off any deviation from SAP’s standard flow with a business reason.
Extensibility
This principle is where the A to D levels apply. The risk is a modification or a direct write to an SAP table. The control is to build every extension with key-user tools, ABAP Cloud or side-by-side apps on released interfaces, which the next two sections explain.
Data
Duplicate customers, orphaned materials and inconsistent units make every process and report fragile. So the control is data quality rules with named stewards and a regular cleanup cadence.
For analytics, SAP positions SAP Business Data Cloud as the data foundation for its business data and AI. That keeps heavy data work off the transactional core, and our guide to SAP Business Data Cloud covers what sits in that layer.
Integration
Point-to-point interfaces built on internal function modules or table reads, for example, break quietly on upgrade.
The SAP API Policy goes further, stating that customer and third-party apps must not use non-published APIs unless SAP permits it. One example of such permission is custom ABAP interfaces in private cloud and on-premise systems. So the control is an integration inventory that maps each interface to a published API, an event or a dated exception.
Operations
Even a clean system drifts if nobody watches it. Release currency slips, monitoring tools get switched off and exceptions never expire.
Checklist
Enterprise Data Modernization Checklist
A step-by-step checklist for scoping, sequencing and validating a modernization program, from the first inventory to reconciliation and sign-off.
Get the Checklist → Transport handling shows what this principle changes day to day. Without a gate, ATC findings are advice a developer can skip when releasing a transport. With one, a clean core finding above the agreed level holds the transport until the code is fixed.
Exceptions get an end date, so a waiver granted for one go-live does not quietly become permanent. For drift, the control is a regular operations review against SAP’s own compliance views, which the assessment section covers.
Principle Typical risk Evidence to collect Owner Business processes Legacy variants rebuilt as custom flows Fit-to-standard decisions with reasons Process owner Extensibility Modifications and table writes ATC results by clean core level Development lead Data Duplicates and poor master data Data quality scores per domain Data steward Integration Interfaces on unreleased objects Interface list mapped to published APIs Integration architect Operations Outdated releases and silent drift Release status and operations KPIs Basis or platform team
Ownership matters more than the table itself. When the development lead owns extensibility and a steward owns data, a review becomes five short conversations. Otherwise it is one long argument.
Talk to Kanerika
Size Your Clean Core Backlog
Kanerika’s two-week readiness assessment covers your SAP system, tooling licenses and ATC baseline, so you see the real size of the backlog before you fund remediation.
Book an Assessment Call → SAP Clean Core Levels A, B, C and D
In August 2025, SAP replaced its original three-tier model with the clean core level concept . It is a maturity model with four levels of compliance. The levels replace a yes or no verdict with a grade, so a team can see how far each extension sits from the ideal.
Level A is fully compliant. It uses only publicly released, stable SAP interfaces backed by formal stability contracts, either side-by-side on SAP BTP or on-stack with ABAP Cloud. Level B is still compliant, but it also uses SAP’s classic APIs and technologies, which are documented and generally upgrade-stable.
Level C is partially compliant, because it reaches SAP internal objects for legacy scenarios. SAP says it plans a changelog for SAP objects to help here, but that is a plan, not a shipped tool. Level D is not clean, since it covers explicitly non-recommended objects, modifications, write access to SAP tables and implicit enhancements.
Level What it uses Example Upgrade risk What to do A Released APIs with stability contracts ABAP Cloud app on a released CDS view Lowest Keep B Documented classic APIs Classic BAPI call from custom code Low Keep and watch C SAP internal objects Report reading an internal table directly Medium Plan to refactor D Modifications, table writes, implicit enhancements Changed SAP pricing routine Highest Remediate first
What the Levels Give Leaders
The levels give leaders two things. First, finance, IT and the partner share one vocabulary for what a clean system is. Second, a vague goal becomes a road map: move objects from D and C toward B and A.
Not every Level C object needs to move this year. A report that reads an internal table once a month, for instance, may be cheaper to watch than to rewrite. The value of the grade is that the choice is made on purpose, with the risk written down.
Where Extensions Should Live: Key-User, On-Stack and Side-by-Side
Once a change is justified, the next question is where to build it, and SAP describes two extensibility models for that. Side-by-side extensions on SAP BTP are “scalable, decoupled applications that run independently from the core,” in SAP’s words. By contrast, on-stack extensions with ABAP Cloud are “tightly integrated, upgrade-stable extensions within the ERP system.”
SAP also tells customers to choose between them based on the use case, applying a BTP-first strategy .
Key-user extensibility sits alongside both. It covers custom fields, logic and forms that a trained business user adds through SAP’s own apps, with no developer tools.
Key-User Extensibility
This is the lightest option and the easiest to keep clean, because SAP manages the tools. It suits a new field on a sales order or a small validation. But it reaches its limits quickly once logic gets complex or needs to call other systems.
On-Stack With ABAP Cloud
ABAP Cloud, also called developer extensibility, lets developers build inside the ERP using only released objects. According to SAP’s ABAP Cloud FAQ , it is mandatory in the SAP BTP ABAP environment. It is also mandatory for new S/4HANA Cloud Public Edition customers since release 2208.
In Private Edition and on-premise S/4HANA from release 2022, it is recommended but not mandatory. Released S/4HANA APIs also need release 2022 or later, which matters for older systems. Our guide to SAP ABAP covers ABAP Cloud and RAP in more depth.
Side-by-Side on SAP BTP
Side-by-side apps run on SAP BTP and talk to the ERP through APIs or events. They fit logic that serves several systems, needs its own release rhythm or uses services such as workflow and AI. SAP Build adds low-code tools for apps and automations on the same platform.
Checklist
Data Integration Checklist for Enterprise Teams
Review integration patterns, source connectivity, transformation logic, error handling and security controls, so every feed you move onto a released API is checked the same way.
Get the Checklist → There is one trap, though. A BTP app that reads unreleased interfaces is no cleaner than the code it replaced, since it simply moves the fragile dependency to another server.
How to Choose
Pattern Fits when Needs Watch out Key-user Fields, simple rules, forms Trained key users and naming rules Sprawl of small changes nobody owns On-stack, ABAP Cloud Logic close to ERP data and transactions Release 2022 or later, released objects Missing released APIs for your scenario Side-by-side, SAP BTP Cross-system apps, workflow, AI services BTP account, APIs or events, operations Calling unreleased interfaces anyway
A useful default is to start with key-user tools. Then move to ABAP Cloud when the logic needs ERP data in the same transaction, and go side-by-side when it outgrows the ERP.
How to Assess Your Clean Core Status
An assessment answers one plain question: which extensions would hurt at the next upgrade, and why? It starts with an inventory and ends with a decision for every object.
Inventory More Than Custom Code
Capture more than custom programs: modifications, enhancements, interfaces, background jobs, reports and the extractors that feed analytics and BI . Also add usage data, because objects that never run are the cheapest to retire.
Run ATC With the Clean Core Checks, Configured Correctly
SAP calls the ABAP Test Cockpit (ATC) the main tool for code-level governance, but the setup decides whether its results mean anything. According to SAP PRESS , the clean core level checks are available in S/4HANA 2023 and 2025. On 2023, SAP Note 3565942 is the starting point, though it is not enough on its own.
Systems below S/4HANA 2023 cannot run these checks on-premise, so central ATC on SAP BTP is their only path to level analysis. If data elements and domains show up as Priority 1 errors, the same source warns, the system is still running the old three-tier checks. That inflates your backlog with objects the level model excludes.
One setting is easy to miss. In the check variant, open the Usage of APIs check under the Clean Core category. Its classicAPIDataSource attribute must point at the classification file in SAP’s Cloudification Repository on GitHub.
ATC check variant > Clean Core > Usage of APIs (SAP Note 3565942)
classicAPIDataSource = https://raw.githubusercontent.com/SAP/abap-atc-cr-cv-s4hc/refs/heads/main/src/objectClassifications_SAP.json
releasedAPIDataSource = checkedSystem " default on S/4HANA 2025
" After SAP Note 3565942, run the note analyzer in SAP Note 3627152
" No GitHub access: upload the file with SYCM_API_CLASSIFICATION_MANAGR
" and enter the local filename as classicAPIDataSourceWithout that URL the check still runs, but classic APIs are not classified correctly. So verify the attribute before anyone sizes a backlog from the results.
Watch on YouTube
Fabric Migration: Code Is Easy, Dependencies Are Not
A short Kanerika take on why the hard part of any move is the web of reports and feeds that depend on the code, not the code itself.
Read the Cloud ALM Compliance Views
For RISE customers, SAP Cloud ALM shows clean core compliance views on a RISE with SAP dashboard. The System view checks whether the installed S/4HANA version is current, whether data collection is active and which extensions need review before the next upgrade. The Operations view tracks compliance from the operations side with quality KPIs.
Give Every Object a Disposition
An inventory with no decisions is just a long spreadsheet. So give every object one of five outcomes, and record who made the call.
Retire objects with no usage and no legal reason to exist.Replace with standard where SAP now covers the need.Refactor to Level A or B using released or classic APIs.Relocate side-by-side when the logic belongs outside the ERP.Keep under a dated exception with an owner and a review date.For each object, the record should hold the owner, usage evidence, current level, dependency map, test plan and chosen disposition. That record is what lets you plan waves instead of guessing, and it pairs well with a broader data governance framework for the data-side decisions.
A Practical Path to SAP Clean Core
Two tracks run side by side on any clean core program. Partners such as REALTECH call them stay clean and get clean. SAP’s own Cloud ALM guidance makes the same point when it tells customers to set clean core principles for new developments.
Stay clean means new work adds no new debt. Get clean means existing extensions are analyzed, prioritized and modernized over time.
The order matters. If new Level D code keeps arriving while the team refactors old Level D code, the backlog never shrinks. So the gate on new work comes first, and the cleanup follows in waves.
Five Phases With Exit Criteria
A five-phase path works for most SAP estates, whether the system is ECC heading for S/4HANA or an S/4HANA system that has drifted.
AI Assessment
How Ready Is Your Data and Governance for AI Agents?
Score your AI and data foundations against industry levels, then see what needs fixing before an agent starts reading your ERP.
Start Your AI Assessment → Phase Output Exit criterion 1. Set rules and owners Extension policy, level targets, named owners per principle Policy signed off by IT and business leads 2. Baseline and prioritize Inventory, ATC results by level, usage data Every object has a level and a draft disposition 3. Pilot one extension One extension rebuilt at Level A or B, with a real report or interface depending on it Pilot passes regression tests and a dependent report still reconciles 4. Remediate in waves Waves grouped by dependency, not by package name Level D count falls each wave with no business incident 5. Gate every release ATC in the transport gate, exception approval flow No new Level C or D object reaches production without an approved exception
Teams are tempted to skip the pilot in phase three, yet it is the cheapest place to learn how long a refactor takes. So pick an extension that a report or interface depends on, because that is where surprises hide. Then test it with the same discipline you would use for data migration testing .
Where Clean Core Fits in an S/4HANA Move
A greenfield move can enforce clean core from day one, provided the gate exists before the first line of code. A brownfield conversion keeps history and custom code, so the assessment and the waves above become part of the conversion plan. In both cases clean core is a rule for the target system, not a separate project, and our migration services team treats it that way.
Keep Reporting and Integrations Intact
Reporting is the easiest part of a clean core plan to forget. A report, an extractor or a data pipeline that reads an SAP table directly is a dependency too.
When that table changes, a dashboard can go wrong without anyone noticing for weeks. The same thing happens when an interface is retired in favor of a released API.
So trace every report and pipeline back to the SAP object it reads. Data lineage makes this practical, because it shows which semantic model, Power BI report or downstream table depends on which source. Then move each feed onto published APIs or CDS-based interfaces, in line with the SAP API Policy covered above.
Connectivity alone is not the test. Check delta behavior, authorizations and reconciliation as well. A feed can connect cleanly and still drop changed records or expose data to the wrong region.
Our guide to SAP data integration walks through the patterns, and Kanerika’s data integration services cover the build.
Legacy reporting tools add their own dependencies, since BusinessObjects universes often sit on old extraction paths. A clean core wave is then a natural moment to plan a SAP BusinessObjects migration as well. Treat the report estate as part of the same inventory, with the same owners and dispositions.
Common Clean Core Mistakes
Five mistakes come up again and again, and each has a simple control.
Treating clean core as a one-time project. Without a release gate, debt returns, so put ATC in the transport path.Moving brittle code to BTP unchanged. A lift to another runtime keeps the fragile calls, so redesign the interface first.Trusting an ATC run on old three-tier variants. Check for data elements flagged as Priority 1 before you size the backlog.Retiring “unused” code too early. Period-end, year-end and regulatory jobs run rarely, so check a full year of usage first.Merging AI-generated ABAP without review. Run it through ATC, ABAP Unit and a human reviewer like any other code.The fourth mistake causes the most pain, because it surfaces months later during a close. A year of usage data, plus a quick word with finance, avoids it.
Clean Core and AI
AI cuts both ways here. On one side, assistants and enterprise AI agents work on standard processes and released APIs, so a clean core is easier for them to read and act on. Logic hidden in a modification is invisible to them, which is an easy way for an agent to give a wrong answer.
Kanerika Service
AI-Powered SAP ABAP Development Services
Kanerika replaces custom modifications with SAP-aligned extensions, supports ABAP Cloud and RAP adoption and sets ATC baselines for a clean core.
Explore SAP ABAP Services For a wider view, see our piece on AI in ERP .
On the other side, AI is starting to help with the cleanup itself. In August 2026, SAP said it delivered its first Custom Code Assistant in Q2 2026 , along with a first agent for custom code migration strategy. A second agent, for clean core transformation, was planned for Q3 2026. As of November 2026, we found no SAP announcement that it had shipped, so treat it as planned rather than available.
These tools speed up analysis and refactoring, but they do not remove the need for review. Like other AI code assistants , they produce code that must pass the same ATC checks and tests. Then the same owner still signs off the disposition.
How Kanerika Helps You Reach a Clean Core
Kanerika works on clean core in the same order this guide follows. Our SAP ABAP development services team starts with the foundation: coding standards, ATC baselines and AI-ready development practices.
Assessment, Pilot, Then Rollout
Each engagement opens with a two-week readiness assessment of the SAP estate, tooling licenses and ATC baseline. Then a pilot on live backlog items runs for six to eight weeks on one squad, with full governance from day one. So leaders see the real size of the backlog, and how a governed team handles it, before they fund the rollout.
In remediation, our developers replace custom modifications with SAP-aligned extensions and support ABAP Cloud and RAP adoption. Where the business needs its own logic, we build it as an SAP extension, along with the integrations it depends on. Finally, we set up governance so the gate on new work keeps holding after we leave.
Guardrails on AI-Assisted ABAP
Our developers use SAP Joule for Developers and GitHub Copilot inside ADT to draft CDS views, RAP objects and ABAP Unit tests. AI-drafted code still passes the same ATC checks, ABAP Unit tests and code review as hand-written code before every transport. A developer approves each change, and the tools run on enterprise tenants with no production business data in a prompt.
Our ABAP practice puts numbers on this way of working. Kanerika’s SAP ABAP page lists 65% faster ABAP development cycles and 70% fewer code review issues. It names no client, so read both figures as practice claims rather than a case study result.
The Same Principle Outside SAP
For a data blending and analytics platform, Kanerika built custom connectors for niche systems the product did not support. In short, we extended the platform instead of bending it.
The result was a 70% reduction in data prep time and 90% better governance, through repeatable, auditable pipelines. It is not an SAP project, but it is the same principle of extending through supported interfaces.
Case Study
70% Less Data Prep Time with Custom Data Connectors
Kanerika built governed custom connectors for systems a data platform did not support natively, cutting data prep time by 70% without bending the platform.
Read the Case Study → Kanerika is a Microsoft Solutions Partner and holds ISO 9001:2015, ISO 27001, ISO 27701:2019, SOC 2 Type II and CMMI Level 3 credentials. We also bring data modernization and analytics experience, since report dependencies often set the pace. To size your own estate, book a call with our SAP team for an assessment of custom code, interfaces and report dependencies.
Wrapping Up
SAP clean core is a rule about where change lives. Keep the ERP standard, build differentiation as extensions on stable interfaces, and grade every extension from A to D across five principles.
Then start with an honest inventory and an ATC baseline set up for the level model. Gate new work first so no fresh debt arrives. After that, move old extensions toward Level A or B in waves, with every report and interface traced, so each upgrade becomes routine.
Frequently Asked Questions
What is clean core in SAP?
Clean core is SAP’s approach to keeping the ERP standard and upgrade-stable while business-specific needs are built as extensions on stable, published interfaces. It covers business processes, extensibility, data, integration and operations. The aim is that each upgrade runs without reworking custom code, so teams spend their time on new requirements instead.
What are the SAP clean core levels?
SAP grades extensions on four levels. Level A uses only released, stable interfaces. Level B also uses documented classic APIs. Level C reaches SAP internal objects for legacy scenarios, so it is partially compliant. Level D covers modifications, table writes and implicit enhancements, which carry the highest upgrade risk and debt.
Does clean core mean no custom ABAP code?
No. Custom ABAP is allowed as long as it is built in an upgrade-safe way, ideally with ABAP Cloud on released objects or with classic APIs that SAP documents. What clean core rules out is changing SAP’s own code, writing to SAP tables directly and relying on internal objects without a plan.
Is SAP BTP required for a clean core?
No. SAP recommends a BTP-first strategy for side-by-side extensions, but key-user tools and on-stack ABAP Cloud are also clean options. BTP is one home for an extension, not a requirement. A BTP app that calls unreleased interfaces is still fragile, so the interface matters more than the platform.
Does clean core apply to on-premise S/4HANA and ECC?
Yes, as a practice. ABAP Cloud is recommended rather than mandatory in Private Edition and on-premise S/4HANA from release 2022. ECC cannot use released S/4HANA APIs, but teams can still inventory, retire and plan remediation now, which shortens the later move to S/4HANA.
How do I check clean core compliance?
Start with an inventory of custom code, modifications, interfaces, jobs and reports. Then run the ABAP Test Cockpit with the clean core level checks, which need S/4HANA 2023 or later, or central ATC on SAP BTP for older systems. RISE customers can also review the compliance views in SAP Cloud ALM.
Is there a clean core certification?
SAP Learning offers clean core training, such as its Managing Clean Core for SAP Cloud ERP course. However, we could not verify any SAP-issued certification that marks a customer system as clean core certified. Progress is shown instead through ATC results by level and the compliance views in SAP Cloud ALM.
How does clean core reduce technical debt?
Clean core stops new debt by gating every release with ATC and an exception process, so modifications cannot slip into production. It then reduces old debt by retiring unused objects, replacing them with standard features or refactoring them to Level A or B. Each upgrade then needs less rework and less retesting.
