ATC Clean Core Results: Turn Them Into Regression Scope

To turn clean core ATC results into a regression scope, group every finding by clean core level, check the Level C objects against SAP's changelog before each upgrade, and map each Level D or changed Level C object to the processes, interfaces and extensions that call it. The ATC run does not give you a full picture of Level A, so your test scope starts from the B, C and D list.

This guide is for the test manager or CoE lead who has the ATC output in front of them and needs to decide what gets retested. It assumes you already know the clean core levels. If you need the full mechanics, read our clean core glossary entry and the SAP Clean Core pillar guide.

What the clean core ATC checks actually report

SAP places the clean core checks under a ABAP test cockpit category called Clean Core. The relevant ATC checks for clean core are Allowed SAP enhancement technologies, Usage of APIs and Critical Statements. The first flags enhancements in custom code that use a technology SAP does not allow for clean core. The second, Usage of APIs, is based on SAP's usage guidelines for SAP APIs in custom code. Most of your regression scoping will come from that check.

One thing to get straight before you plan: the ATC results are not a Level A list. Level A customer objects are determined using SAP EarlyWatch, while Level B, C, and D customer objects are identified using the ABAP Test Cockpit (ATC). A clean ATC run therefore tells you what to worry about, not that everything else is safe.

Configure the checks before you trust the counts

A clean core ATC run can look healthy when it is not. The SAP PRESS write-up on configuring the checks says the clean core level checks are available in SAP S/4HANA 2023 and 2025, but available doesn't mean ready to use. On S/4HANA 2023, the starting point is SAP Note 3565942, and on both releases, that note alone isn't sufficient. After you implement it, run the note analyzer in SAP Note 3627152, because the note analyzer identifies all dependent and correction notes required to make the clean core checks fully functional.

Two more setup points matter for scoping. Systems below SAP S/4HANA 2023 can't run these checks on-premise at all, which pushes you toward central 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 private cloud and on-premise landscapes. The usage check also needs the classic API data source parameter filled in, which points to SAP's object classification file on GitHub. A misconfigured or outdated ATC variant doesn't fail in an obvious way. The checks run and produce findings, just not the right ones.

Read the findings by level

SAP's ABAP Extensibility Guide uses the levels to separate classic ABAP work from released APIs. Level B can be achieved by custom extensions that comply with SAP recommendations for the use of classic ABAP development technologies and the frameworks offered as classic SAP APIs, while Level C contains custom extensions that cannot be qualified for Level B because they use arbitrary SAP internal objects. The single source of truth for the level assignments is the official SAP Note 3578329.

Level	What the ATC run tells you	Upgrade risk in practice	Test consequence
B	Classic SAP APIs such as BAPIs and IDocs	Supported and stable, but not released	Regression on the process and interface that calls it; plan a later move to a released API
C	Internal SAP objects, reported as warnings	Conditionally clean. There is no guarantee on long-term stability.	Check against the changelog before each upgrade; retest only the objects that changed
D	Not-recommended SAP objects, reported as errors	Not clean; the likeliest source of upgrade breakage	Replace before the upgrade, or record a signed exception and retest in full

The warning and error split is what you should use for triage. In one worked example, a direct read of an internal standard table is a Level C item that ATC reports as a warning, while a direct write to that table is Level D and reported as an error. Classify: direct access to KNA1 (an internal SAP object, not a released API) → Level C (ATC: warning). A direct write would be Level D (ATC: error). The community author's remediation rule is useful for your planning too: A keep, B keep and plan to lift later, C verify via the changelog-for-SAP-objects approach and wrap behind a released interface, D replace before the upgrade.

Turn the findings into a regression scope

The scope is built from the findings, not from the whole custom code inventory. Work through the steps below in order, and keep the output in your change impact log.

1. Run the checksExecute the clean core variant on the target-release packages with the note analyzer clean.
2. Classify by levelSort findings into B, C and D; keep the object name, package and calling process.
3. Apply the changelogFlag every C object that uses an internal object SAP changed incompatibly.
4. Map to business and interfacesLink each flagged object to a process, an interface or a batch job in your test scope.
5. Set the pack and sign offAdd the mapped tests to the regression pack and record the decision for each D and each changed C.

The changelog step is the one that changes your regression list. Internal SAP objects can change at any point in time during an upgrade. Incompatible changes include the deletion of objects, renaming or deletion of parameters or methods and others. SAP's changelog lists those changes, and the changelog information is integrated and considered in the clean core ATC check Usage of APIs, which can then detect in custom code the use of SAP objects and their associated components that have been incompatibly changed. Keep in mind that the changelog information is transferred via the Simplification Database infrastructure from the SAP Support Portal to your system. You can download it from the SAP Software Download Center and import it into your ABAP test cockpit check system. The check does nothing if the file is not loaded, and merely having an ATC variant is not enough.

A worked example: a custom order check calls an internal method. If that method appears in the changelog, ATC raises a warning against its use. The team then investigates a replacement and schedules regression testing before the release changes. In the test pack, that means the order check, the process it supports and any interface that feeds it, not the entire sales module. This is the point of the exercise. The clean core level tells you how much risk each object carries, and the changelog tells you when that risk becomes a test case.

Use the ATC history as your burn-down

A single run is a snapshot. Your sign-off evidence is the trend across releases. Record counts for A (from EarlyWatch), B, C and D for each release, along with the number of Level C objects cleared by changelog review. A falling D count and a shrinking changelog-flagged C list are what a CoE should show a steering committee.

SAP's RISE dashboard can take those counts. The dashboard now supports the manual import of check results from the ABAP Test Cockpit. Be careful with what it shows. So far, the RISE with SAP Methodology Dashboard only displayed customer objects that have findings from the clean core related ATC checks. Objects that are neither Level A nor have ATC findings were not shown in the RISE dashboard. Keep your own object list alongside the dashboard so the numbers can be reconciled.

What changed this week

SAP's Clean Core Operations white paper is now public. 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. That is the document to take to your operations owner, since ATC runs, transport gates and changelog reviews only stick if someone owns them.

SAP TechEd Berlin runs this week. The session titled "The journey with clean core continues for SAP Cloud ERP Private" is listed for Wednesday, October 28, with a virtual repeat on Thursday, October 29. It covers new guidance for data, integration, and clean core in relation to SAP's API policy. We will update this guide within a week of TechEd if the guidance changes the ATC checks or the level definitions.

Frequently asked questions

Does a Level C finding block an upgrade?

No, not by default. SAP treats Level C as conditionally clean when dedicated checks run before the upgrade, using the changelog approach. The decision is yours to record: keep the object, wrap it behind a released interface, or replace it. The regression scope should cover any object the changelog flags.

Do I need to rerun the clean core checks for every feature pack stack?

Run the checks against the target release before each upgrade, and keep the changelog current for that release boundary. SAP recommends that the changelog be considered during regular ATC quality checks, not only at upgrade time. The reported scope of the current changelog covers the move from S/4HANA 2023 to 2025, so confirm the boundary for your own target release before you rely on it.

Can I rely on ATC on SAP BTP alone?

For governance, SAP recommends central ATC on BTP for private cloud and on-premise landscapes. For systems on S/4HANA 2023 or later, the checks can also run on-premise. Systems below S/4HANA 2023 can only be analyzed through central ATC, so the BTP route is the only option for them.

Does ATC show Level A objects?

No. The clean core ATC results do not carry Level A findings, so you need another source for that part of the inventory. In the RISE dashboard, Level A is based on SAP EarlyWatch data, while B, C and D come from ATC. Reconcile the two before you publish a clean core number.

For a hands-on route through custom code governance, the free SAP Academy course Quality Engineering for Clean Core covers how testers can work with these results. To set up the regression pack that follows from your ATC output, see the SAP Custom Code (ATC) Remediation and Retest Tracker and the Release Regression Plan.

Sources

1. ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development, SAP Community, 2025
2. Configuring the ABAP Test Cockpit and Transport Gate in SAP S/4HANA, SAP PRESS Blog, 2026
3. ABAP Extensibility Guide: Clean Core for SAP S/4HANA Cloud, August 2025 update, SAP Community, 2025
4. Changelog for SAP objects: verify clean core level C compliance of your custom extensions, SAP Community, 2026
5. New Clean Core Extensibility KPIs arrive on the RISE with SAP Dashboard, SAP Community, 2025
6. SAP Cloud ALM's Clean Core Extensibility Assessment is getting more accurate, SAP Community, 2026
7. Introducing SAP Application Extension Methodology version 2.4, SAP Community, 2025
8. The Clean Core White-Paper Series Is Now Complete, SAP Community, 2026
9. ABAP Sessions at SAP TechEd 2026, SAP Community, 2026
10. Clean Core Levels A–D: how to classify your custom ABAP and what to do with it, SAP Community member blog, 2026
11. SAP News: Find the dependency before the upgrade, third-party newsletter, 2026 (scope statement to verify against SAP documentation)
12. Exploring Clean Core Extensibility Best Practices, SAP Learning