SAP Clean Core: What It Means and How to Achieve It

SAP clean core is SAP's name for keeping the ERP core as close to standard as possible, with custom functionality built outside the core on interfaces SAP commits to keep stable. It is a set of guiding principles, not a rule that you must have zero custom code. If you sign off on an S/4HANA release, that distinction matters, because it decides what you have to retest when the next feature pack arrives.

For a test manager, the practical version is simple. A clean core is a promise that the next upgrade will be cheap to prove. Fewer modifications, fewer calls into SAP internals and fewer non-standard process variants mean a smaller regression scope and a faster, better-evidenced sign-off.

This guide explains the meaning, the five dimensions SAP now uses, the A-D extension levels, how to measure where you stand and a step-by-step path to get there. Part 1 covers the definition, the case for 2026, the dimensions one by one and the integration rules. Part 2 covers measurement, the migration path, testing and sign-off, myths and FAQs.

What clean core means, and what it does not

SAP describes clean core as a set of guiding principles for keeping an ERP system agile, cost-efficient and ready for new innovation. Clean core is SAP's set of guiding principles for continuous business transformation — keeping your ERP agile, cost-efficient, and ready to adopt the innovations that drive growth. The point is continuity: the aim is a system you can keep changing without each change turning into a rebuild.

The working rule is about where custom logic lives. Extensions sit outside the standard core and reach SAP business objects only through interfaces SAP designed to survive an upgrade. In SAP's own clean core guidance, extensions must access SAP business objects only through well-defined, upgrade-stable interfaces. That is the test that matters: not how much code you own, but how the code connects to the standard.

Three things clean core does not mean:

• It does not mean zero custom code. SAP's model assumes you will have extensions. It asks you to grade them and keep them off the internals. The 2023 SAP Community post "Clean Core demystified" made the same point, and it is still the right starting explanation.
• It is not binary. SAP's current model replaces a clean/not-clean decision with a graded scale. In SAP's own words, the new model enables a more granular assessment of an extension's quality and upgrade stability, rather than a simple binary "clean" or "unclean" decision.
• It is not a product. You do not buy clean core. You get there by choosing standard processes, extension technologies and integration patterns, and by checking them continuously.

The "BTP-first" phrase you will hear is a preference, not the definition. SAP's guidance still recommends a "BTP-first" strategy, aiming for the highest possible level, but a clean core does not require every extension to run on SAP BTP. A well-built on-stack extension using ABAP Cloud can be just as clean.

Why clean core matters more in 2026 than in 2023

Three things changed between the first clean core messaging and today. The grading model changed, the operating expectations changed and the data and AI stakes changed.

The grading model changed first. In August 2025, SAP retired its original three-tier extensibility model and replaced it with a more granular Clean Core Level Concept, a four-level scale that scores each extension against criteria for how it is built, how decoupled it is and how well it survives an upgrade. Teams that built their governance on the three tiers now need to re-map their existing custom code.

The operating expectation changed second. SAP's September 2026 Clean Core Operations white paper treats operations as its own discipline. The new Clean Core Operations whitepaper defines operations as a cross-principle governance practice, covering people, process, tools, and change management in one coherent model. The same post makes the point that when operations are an afterthought, clean core becomes a one-time project rather than a sustainable practice. If your 2023 plan ended at go-live, this is the gap to close.

The third change is the cost of a dirty core. Customers on RISE with SAP are expected to follow the RISE methodology, which includes clean core guidance and, in SAP's own description, the RISE with SAP Methodology dashboard provides real-time insights into clean core adoption. A dashboard is only useful if someone reads it and acts, which is why the sign-off questions in this guide matter.

AI raises the bar again. SAP's data white paper and its clean core messaging both tie reliable AI to governed data and standard interfaces. As one SAP data message puts it, AI is only as reliable as the data behind it. An agent that reads cleanly modeled business objects through released APIs is far easier to trust, test and audit than one that scrapes screens or reads tables directly.

Timing is the last factor. ECC mainstream maintenance is ending, so many programs are moving to S/4HANA now. The ECC end-of-maintenance dates set the deadline, but the clean core choices you make during migration are the ones you will live with for years. The 2025 migration report found that 32% of organizations have completed their S/4HANA transition, according to SAPinsider's survey, which means most programs are still making those choices.

The five dimensions at a glance

SAP now frames clean core as five principles. SAP's clean core strategy is built on five guiding principles — Processes, Extensibility, Data, Integrations, and Operations. Earlier SAP material used six components, including the software version. The five-dimension view folds that version question into operations and upgrades, and it treats process standardization as a clean core dimension in its own right.

Figure 1 shows the hub and the five spokes. Each spoke has one goal, one main SAP tool, one clean test and one KPI you can track release to release.

Spoke (hub: S/4HANA / SAP Cloud ERP core)	Goal	Main SAP tooling	One KPI
Processes	Keep processes flexible by standardizing first	Fit-to-standard workshops, SAP Best Practices, Signavio process insights, Readiness Check	Share of process variants with a documented business case
Extensibility	Build extensions on released interfaces	ABAP Cloud, ATC clean core checks, SAP BTP side-by-side	Share of custom objects at Level A or B
Data	Keep master and transactional data lean and governed	Data quality checks, archiving, clean core data white paper	Duplicate rate in customer, vendor and material master
Integration	Connect through released APIs and events	SAP Integration Suite, released APIs, event patterns	Share of interfaces on released APIs or events
Operations	Keep the core clean after go-live	SAP Cloud ALM, transport governance, ATC transport gate	Share of transports passing the clean core gate without P1 or P2 findings

The table is a map, not a checklist. Two rules help make it usable:

• Every spoke needs an owner with a name, not a team alias.
• Every KPI needs a baseline taken before the next feature pack, so you can show movement.

In practice, most failed clean core programs were strong on one or two spokes and silent on the rest. A clean extension layer sitting on a process model with 40 unapproved variants is not clean in any useful sense.

Processes: stay close to standard on purpose

Process standardization is the cheapest clean core lever, and the most often skipped. Every process variant you keep is a path through the system that a regression pack must cover. It is also a point where a new feature pack can change behavior you did not intend to change.

SAP's guidance ties process adherence to fit-to-standard. The RISE with SAP methodology provides clear guidance on how clean core adherence should be driven by the fit to standard approach, and the role that proper governance (through a well-functioning solution standardization board) plays in transformations. In a working program, that means three things:

1. Run fit-to-standard early. Use the SAP Best Practices content as the default and record every gap as a requirement with an owner.
2. Put variants through a board. A variant is approved only when the business case shows it differentiates the company, not when a legacy report needs to look the same.
3. Use process evidence to test. Process mining from Signavio or similar tools shows which variants people actually run, so you test the paths that carry volume and risk first.

A process variant is a real differentiator when it changes revenue, cost or regulatory outcome, and when a standard process cannot be configured to deliver the same result. Pricing for a regulated product or a pooled-shipping rule in a logistics network can qualify. A report layout preference does not.

The test scope follows from the decision. Link each approved variant to its test cases in your coverage map, the way the fit-to-standard test coverage map does, so that a standardization decision also reduces the regression pack.

Extensibility: key user, on-stack ABAP Cloud and side-by-side BTP

Extensibility is where most of the clean core debate sits, because it is where custom code lives. SAP's current model has three practical extension styles:

• Key-user extensibility adds fields, logic and reports through configuration tools inside the application. It is the lightest touch and usually the cleanest. See the key-user extensibility entry.
• On-stack developer extensibility uses ABAP Cloud, which restricts code to released APIs and extension points. See ABAP Cloud.
• Side-by-side extensibility runs the application on SAP BTP and connects to the core through APIs and events. See side-by-side extensibility.

The A-D levels grade these styles. SAP's update to the ABAP extensibility guidance describes the grades in terms of the SAP objects an extension uses. Figure 2 gives the layered view, from the released core at the bottom to the modifications at the top, with the ATC behavior from SAP's published mapping.

Level A: released APIs and extension pointsABAP Cloud or SAP BTP side-by-side with SAP Build. ATC raises no message. This is the target state.

Level B: classic APIs and frameworksClassic ABAP that follows SAP's recommended practice and uses officially provided classic APIs. ATC priority 3, informational. Use only when Level A cannot meet the need.

Level C: internal SAP APIsConditionally clean only if you run the changelog-for-SAP-objects checks before each release upgrade. ATC priority 2, warning.

Level D: modifications and non-recommended objectsHighest risk and technical debt. Plan remediation, do not extend it.

Two rules govern how the levels are applied:

• An extension takes the level of its lowest-ranked technology. One Level C call inside an otherwise Level A extension makes the whole extension Level C. Extensions are evaluated based on the lowest-ranked technology used within them. This is the rule testers most often miss.
• Level B is a fallback, not a goal. Level B is for cases where released APIs cannot meet the requirement. Level C is conditionally clean, access to internal objects, posing (manageable) risks and allowing for specific customer needs. Level D is the one to retire.

Where do you check the levels? For S/4HANA 2025 and later private cloud and on-premise systems, the clean core ATC checks are delivered in the system. The new ATC checks for clean core are available in the ATC on SAP BTP in the SAP BTP ABAP environment and SAP S/4HANA 2025 private cloud and on-premise systems. SAP's recommended central setup is ATC on SAP BTP. Central ATC in the SAP BTP ABAP environment is the SAP recommended approach for governance of ABAP developments for clean core in SAP S/4HANA private cloud or on-premise landscapes. For S/4HANA 2023, you need the note. On SAP S/4HANA 2023, the starting point is SAP Note 3565942. Treat the note as a start, not the finish: after implementing SAP Note 3565942, run the note analyzer in SAP Note 3627152 before treating the ATC configuration as complete. The ATC transaction is covered in the ATC T-code entry.

The full mechanics of the A-D levels, including how to classify a real custom code inventory, are in our levels guide. For the code-level work, the remote ATC checks for S/4HANA custom code guide walks through the run.

Data: lean, governed and fit for AI

Data is the dimension that clean code cannot fix. Custom code can be fully Level A and still produce wrong numbers if the customer or material master is full of duplicates. Your core can be immaculate on the process and code side and still run on duplicates, dead records and mismatched reference values from day one. That is a sign-off problem, not just a data team problem.

SAP has published guidance for this dimension. Its clean core data white paper, dated November 2025, is aimed at organizations moving from ERP to S/4HANA Cloud Private Edition. Inside, you'll find practical guidance on implementing clean data practices, sustaining them at scale, and unlocking the full potential of your enterprise data. SAP's RISE clean core materials also describe a data foundation of five pillars for clean core data.

For a test lead, a data-clean core means four checks you can evidence:

1. Master data quality before the mock loads. Measure duplicates, missing mandatory fields and inconsistent reference values in customer, vendor, material and business partner data. The cost of getting this wrong is high; one SAPinsider analysis cites Gartner's estimate that poor data quality costs the average organisation 12.9 million dollars every year.
2. Archiving before and after migration. Archive what you do not need to carry forward, so the core is smaller and the reconciliation scope is smaller. Plan the archive runs and their retests as part of the migration, not as an afterthought.
3. Governed reference data. Decide who owns each object, what the approved change path is and how a change in one system reaches the others. Test the replication path, not just the record.
4. Reconciliation evidence at each release. Keep the reconciliation results with the release record so a later feature pack can be compared against a known baseline.

If your team needs a structured start, the free SAP Academy course on data quality, cleansing and mapping rules covers the rule design, and the data reconciliation and validation sign-off course covers the evidence side.

Data also decides how well AI features behave. An agent that reads a duplicated customer record will summarize the wrong account. Clean data is therefore a precondition for the AI scenarios that SAP is pushing, not a separate project.

Integration: released APIs and events, not point-to-point on internals

Integration is the dimension where clean core is most often broken without anyone noticing. A new interface that calls an RFC into an unreleased function module looks harmless in a design review. It becomes a blocker at the next upgrade.

SAP's clean core principle is that integration should run on released APIs and event-based patterns — with no brittle dependencies. In practice, that means three moves:

1. Inventory every interface by its target. Record whether each one calls a released API, an event, a classic API, or an internal object. The inventory is the input to your regression scope.
2. Move point-to-point calls onto Integration Suite. SAP Integration Suite is the managed route for new and migrated integrations, and it lets you monitor the flows from one place. If you are moving from PI/PO, the guide to testing migrated PI/PO interfaces in Integration Suite covers the test steps.
3. Retire RFCs into released or wrapped interfaces. Where an RFC calls an internal function module, replace it with a released API where one exists. Where none exists, wrap the internal call in your own component so the dependency sits in one place you can retest.

Released APIs need to be checked against the current release, not a version you remember. SAP's developer catalog is the reference point. One 2026 practitioner guide notes that released APIs are documented in the SAP Business Accelerator Hub (api.sap.com). Check your API list against that catalog at each release, because a release can change what is released.

SAP's TechEd 2026 agenda also includes a session on new guidance for data, integration, and clean core in relation to SAP's API policy. If you are on RISE or planning to be, that is the session to watch on the week this guide is published.

For the testing side of this dimension, the free academy course on testing SAP interfaces: IDoc, OData and API basics gives testers the vocabulary, and the interface inventory and test tracker gives you a working list.

Part 2 covers how to measure the core, the step-by-step path from baseline to proof, what a clean core changes about regression and sign-off, the common myths and the frequently asked questions.

Operations: keeping the core clean after go-live

Operations is the dimension that decides whether the other four hold after go-live. SAP's Clean Core Operations whitepaper is now published, and it treats operations as a governance layer that spans the other principles. It defines operations as a cross-principle governance practice, covering people, process, tools, and change management in one coherent model. The companion post in SAP's series also lists the aims: streamlining system management, automating routine tasks, and maintaining high availability with minimal manual overhead.

For a test manager, operations comes down to three recurring controls:

1. Watch custom code usage in production. The ABAP Call Monitor, run through transaction SCMON, collects usage data of your custom code extensions in production. The SAP Cloud ALM System View points to the same tool as the way to keep the core clean.
2. Gate every transport. Use the ATC transport gate so that a non-compliant object cannot move into production without a finding being reviewed. SAP PRESS has published a walkthrough, Configuring the ABAP Test Cockpit and Transport Gate in SAP S/4HANA. Confirm the setup in your own sandbox, then prove the gate blocks a deliberately bad object.
3. Repeat the scoring after every feature pack. A clean result on one date is a snapshot. Clean Core scoring grades custom code on three ATC checks (Usage of APIs, Allowed enhancement technologies and Customer modifications) and assigns each object a level from A to D. Run it again at each feature pack and each upgrade.

Operations also covers the cloud side of custom apps. SAP's TechEd 2026 agenda includes an ABAP Cloud session on sizing, technical monitoring, integration with the SAP Cloud ALM solution, and troubleshooting tools for custom apps before and after go-live. If you run custom apps on the ABAP environment, that session is worth attending for the monitoring setup.

Measure clean core: a baseline and five KPIs

Clean core becomes manageable when you can show a trend. SAP has published a Clean Core Measurement Framework that covers governance maturity and KPIs, so you do not have to invent the measures from scratch. The framework helps organizations assess their governance and maturity, define target actions, and track progress through clean core KPIs.

Start the baseline with two inputs. The first is the SAP Readiness Check for brownfield systems, which tells you what the conversion touches. The second is the clean core ATC run, which grades the custom code. For S/4HANA 2025 and later, the clean core check variant is ABAP_CLEAN_CORE_DEVELOPMENT, which SAP provides for remote ATC on SAP BTP and for central ATC on S/4HANA 2025 FPS01 and later.

The five KPIs below are the ones we recommend. Each one maps to a regression or sign-off question.

KPI	Where the number comes from	What the trend should show
1. Level mix of custom objects (A to D)	Clean core ATC run, with usage data applied	The Level D share falls and the Level A share rises release over release
2. Modification count	Customer-modification check in the ATC run	No new Level D objects after the baseline date
3. Unreleased or internal API use	Usage of APIs check, Level C findings and their changelog check results	Each Level C object has a named owner and a passing changelog check
4. Interfaces on released APIs or events	Interface inventory, counted by target type	The share of interfaces on released APIs or events goes up
5. Upgrade test effort	Hours spent on regression per feature pack, from your release regression plan	Effort falls as the levels improve

Counts alone mislead. An object can be Level D and never run. Use usage to weight the counts. ATC tells you what isn't clean; usage tells you what still matters. Activate SCMON in your production system, let it run a representative window, aggregate with transaction SUSG, create a snapshot, and import it into the CCM app. Remember that the usage data is harder to read than it looks. You cannot display the aggregated usage data in SUSG, SCMON or /SDF/SCMON. A remote enabled API is provided to read the aggregated usage data, which you can use to build your own display or extractor.

The collection window is the other judgment call. SAP's training material recommends running the preferred tool for 6–18 months, which should include at least one year-end closing. One practitioner post cites a 13-month figure as SAP's recommendation, which conflicts with the training range, so check the current SAP guidance and record which window you used. Whichever window you pick, a quarter-end report can look unused in a short sample.

Step-by-step: from baseline to proof

SAP's own extensibility white paper describes a six-step path. It starts with the clean core concept and strategy, moves through analysis of existing custom code (for brownfield only), then extension guidelines, governance and operations, and ends with building upgrade-safe extensions. SAP's extensibility white paper sets that sequence out in full.

We use a five-stage loop because it maps to the artifacts a sign-off board asks for. Figure 3 shows it. The loop is continuous. Each feature pack restarts it at the baseline.

1. BaselineReadiness Check, SCMON/SUSG usage snapshot, clean core ATC run
2. ClassifyExtensions by level A to D, process variants, data objects, interfaces
3. DecideRetire, return to standard, rebuild on ABAP Cloud or BTP, or record an exception
4. GovernATC transport gate, Cloud ALM tracking, named owners per exception
5. ProveRegression pack and sign-off at each feature pack, then back to the baseline

The decision for each object

Classification gives you a level. The decision gives you an action. Figure 4 is the rule set we use in sign-off reviews. Apply it to each object or group of objects, not to the whole system at once.

1. Is the object executed in production during your usage window?Yes → go to the next question · No → retire it. Get business sign-off, delete through a transport and keep a backup.
2. Does standard configuration or a key-user tool meet the need?Yes → return to standard, and remove the code · No → go to the next question
3. Can ABAP Cloud, a released API or an event on SAP BTP deliver it?Yes → rebuild at Level A · No → go to the next question
4. Can a Level B or Level C dependency be contained with a named owner and a changelog check?Yes → record a documented exception with a review date · No → Level D: redesign, or drop the requirement

The retire branch is where most of the savings sit. Obtain business sign-off, delete the approved code through a transport, and retain a backup in Git with gCTS. Then the deleted objects leave the regression pack too. That is a scope reduction you can evidence.

Three variants of the path

• Greenfield. Skip the brownfield analysis and start at Classify. Build new extensions with ABAP Cloud or BTP from day one, and turn on the ATC gate before the first custom transport. There is no legacy code to grade, so the baseline is a record of design decisions.
• Brownfield. Run the full loop. SAP's own path treats code analysis as a brownfield step, and that is where most levels get assigned. Expect the first pass to be dominated by Retire and Exception decisions.
• Live S/4HANA. You already have a core in production. Start at Baseline with usage data, then focus on Govern. The first win is usually stopping new Level D work, not cleaning up the old code.

Set the target honestly. The goal is not to reach Level A everywhere overnight — that is neither realistic nor necessary. Most programs aim for no new Level D objects and a falling Level C count, with Level B used where a classic API is the supported option.

Testing and sign-off: what a clean core changes

A clean core shrinks the blast radius of an upgrade. It does not remove the need to test. What it changes is how you choose the scope. Regression scope should follow two things: the extension level and the interface type. Figure 5 shows the four combinations.

A/B extension on an internal interfaceRetest the interface end to end. Re-run the ATC scan on the changed objects.

C/D extension on an internal interfaceFull regression of the affected processes. Run changelog checks before the upgrade. Highest scope.

A/B extension on a released interfaceATC re-scan and a smoke test of the process path.

C/D extension on a released interfaceRetest the extension logic and its process path. Confirm the exception record is current.

The Level C rule is the one that matters most for the sign-off pack. Level C code, which accesses internal objects, is conditionally clean only when dedicated checks are run before each release upgrade, using SAP's changelog approach for internal objects. Make that check a named test step in the release plan, with an owner and a date.

Build the evidence pack for each feature pack from the same five items:

• ATC results by level, before and after the feature pack, with the check variant and release recorded.
• Changelog check results for every Level C object.
• Interface inventory delta: new, removed and changed interfaces, with their target types.
• Regression results tied to the scope in Figure 5, not to a general "run everything" plan.
• The exception register, with owner, review date and sign-off.

On sign-off, our practice is that the test manager signs for scope and evidence, the process owner signs for business behavior, the solution architect signs each Level C exception, and the program sponsor signs any exception that carries a risk the board has not accepted before. Your RACI may differ. The point is that every exception has a name on it.

For the interface side, the SAP Academy course on testing SAP interfaces covers the basics testers need for contract checks against released APIs. For change scoping, the change impact analysis course shows how to go from a transport to a test scope.

Clean core myths and mistakes

"BTP is automatically clean"

Running an extension on SAP BTP does not make it clean by default. The core recommendation remains a "SAP BTP first" strategy, aiming for the highest level, but the new model also acknowledges the realities of complex system landscapes. The aim is the highest level, not the platform. An extension on BTP that calls an unreleased API still carries a lower level.

"Classic ABAP is always dirty"

Classic ABAP can be clean at the right level. Level B uses classic APIs that SAP supports, and the ATC result for it is informational. For Level B, the ATC check gives priority 3 findings, which are information messages. The mistake is treating every classic object as a problem to fix now, when the real question is whether an object is at Level C or D.

"It is a one-time project"

A clean core is a state you keep, not a deliverable you finish. The SAP Community guidance on the new levels treats the work as a repeating cycle. Run ATC regularly, aim to increase A and B extensions over time, keep C-level code on a documented remediation schedule, and enforce zero tolerance for new D-level development. That is how the model becomes a living practice rather than a one-time audit.

"RISE does it for you"

RISE gives you a method, not an outcome. SAP's RISE page ties clean core to following RISE with SAP Methodology, which promotes standardization and modern extensibility to drive successful transformation. You still run the method, and the custom code, the test scope and the exceptions are your responsibility. Our RISE testing ownership guide sets out the split.

What has changed since SAP's 2023 "Clean Core demystified" post

The 2023 post is still the right starting explanation for the principle. The framework around it has changed. Figure 6 sets the two views side by side.

Topic	2023 view	2025–2026 view
Principles	Six components, including the software version →	Five dimensions: processes, extensibility, data, integration, operations. Version moves into upgrades and operations.
Extensibility grading	Three tiers, with classic ABAP at Tier 3 →	Four levels, A to D, from August 2025. Level A is the target; Level D needs remediation.
Verification	Manual review of custom code and guidance →	ATC clean core checks in S/4HANA 2025 and on SAP BTP. S/4HANA 2023 needs SAP Note 3565942 first.
Guidance	Mostly blog posts →	Per-dimension white papers, including Operations, Data, Integration and Processes.
Measurement	No standard KPI set →	SAP's measurement framework, with KPIs and governance maturity.
Partner certification	Clean core criteria for partner solutions →	A two-tier integration certification program, with the new tiers scheduled to launch in Q3 2026.

The 2023 six-component view is the one to retire from your governance documents. Earlier material listed six dimensions: software stack, processes, extensibility, integration, data and operations. The current framing keeps the same concerns and folds the software stack question into operations and upgrades.

The three-tier model also needs remapping. The new model evolves the previous three-tier approach into four distinct levels, A, B, C and D, based on architectural integrity, upgrade safety and alignment with clean core principles. A custom code inventory graded under the old tiers cannot be read as a level without re-running the scoring.

The bottom line

A clean core is a standing decision about how custom logic connects to the standard. It is not a one-off score. Measure it with the ATC levels and usage data, decide each object deliberately, and carry the results into the regression scope and the sign-off pack at every feature pack.

The practical test is simple. After your next feature pack, you should be able to name the objects that changed, the level each one sits at, the interfaces it touches and the owner who signed off the exceptions. If you cannot do that from your records today, the clean core work starts with the baseline, not with the next extension.

Frequently asked questions

What is clean core in SAP?

Clean core is SAP's set of principles for keeping the S/4HANA core standard enough to upgrade without rework. Custom logic lives outside the core and uses interfaces SAP maintains across releases. SAP now grades extensions from A to D and measures the core across five dimensions.

What are the clean core principles in SAP?

SAP's current principles are processes, extensibility, data, integration and operations. Integration means connecting systems reliably using released APIs and event-based patterns, with no brittle dependencies. Figure 1 sets out the goal and the KPI for each one.

Does clean core mean no custom ABAP code?

No. SAP's model expects some extensions and asks you to grade them and keep them off internal objects. Level A and Level B extensions are compliant with the model. Level D is the category you need to remove, and Level C is allowed only under a documented check.

How do you achieve clean core in SAP?

Start with a baseline from usage data and an ATC run, then classify each object and decide whether to retire, standardize, rebuild or record an exception. Put an ATC gate on transports and repeat the scoring at each feature pack. Use Figure 3 as the working loop.

Is clean core required for RISE with SAP?

I could not verify a contract clause that makes clean core mandatory under RISE. SAP's RISE materials tie a clean core outcome to the RISE with SAP Methodology and describe a dashboard for tracking adoption. Check your contract and statement of work for any specific obligation, and treat the methodology as the baseline for the program.

What is the clean core approach in SAP BTP?

The clean core approach on SAP BTP is side-by-side extensibility, where extensions run on BTP and connect to the core through APIs and events. SAP's recommended strategy is BTP-first, aiming for the highest level. Side-by-side is not the only clean option, because an ABAP Cloud extension on the stack can be Level A as well.

Is there an SAP clean core certification?

SAP certifies partner solutions for clean core. Partners can earn the SAP-certified for clean core designation with the SAP S/4HANA Cloud designation, so customers see at a glance that the solution supports their clean core efforts. Certification covers a product's integration model, not your system. It validates the underlying integration model, not every decision involved in deploying or operating it. SAP's integration certification program is also being restructured into two tiers, with the new structure scheduled to launch in Q3 2026, so check the current SAP program page before you rely on it.

How do you measure how clean your SAP core is?

Use five KPIs: the level mix of custom objects, the modification count, unreleased or internal API use, the share of interfaces on released APIs or events and the upgrade test effort. Take the baseline from an ATC clean core run and weight it with SCMON and SUSG usage data. Report the trend at every feature pack.

Sources

1. Introducing the Clean Core Operations Whitepaper, SAP Community, September 2026
2. The Clean Core White-Paper Series Is Now Complete, SAP Community, September 2026
3. Clean core strategy and resources, SAP, undated
4. ABAP Sessions at SAP TechEd 2026, SAP Community, October 2026
5. Clean Core Levels A–D: how to classify your custom ABAP, SAP Community (member post), 2026
6. ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development, SAP Community, updated 2026
7. Clean Core After Go-Live: A Step-by-Step Analysis, SAP Community (member post), 2026
8. System View, SAP Cloud ALM Help, undated
9. Aggregate usage data in your production system with SUSG transaction, SAP Community, updated August 2026
10. ABAP Call Monitor (SCMON) – Analyze usage of your code, SAP Community, 2026
11. Collecting Usage Data for Custom Code, SAP Learning, undated
12. Identifying Unused Custom Code During S/4 Migration, practitioner blog, undated
13. Extended Warehouse Management in SAP S/4HANA FAQ series: update on the new Clean Core level concept, SAP Community, 2025
14. Clean Core Extensibility: Balancing Standardization and Differentiation, SAP Community, 2025
15. Why Clean Core matters, SAP Community, 2026
16. ABAP Extensibility Guide: Clean Core for SAP S/4HANA Cloud, August 2025, SAP Community, 2025
17. Certification of Partner Solutions following Clean Core, SAP Community, 2025
18. Certification Of Partner Solutions Following Clean Core Criteria, SAP, 2023
19. SAP's New Integration Rules Draw a Line in the Sand for Certifications, SAPinsider, 2026
20. Flintfox by Enable Earns SAP Clean Core Certification for RISE with SAP, SAPinsider, September 2026
21. Clean Core demystified: What does it mean and how to achieve it with SAP BTP?, SAP Community, 2023
22. Configuring the ABAP Test Cockpit and Transport Gate in SAP S/4HANA, SAP PRESS Blog, September 2026
23. SAP Clean Core — Strategy Behind Every S/4HANA Build Decision, practitioner blog, 2026
24. Clean core data white paper, SAP, November 2025
25. SAP clean core strategy and BTP extensions for S/4HANA (2026), ERP Implementation, 2026