Skip to main content
Discuss the technical scope

Technical guide

How should an extension decision be assessed under a clean core approach?

An extension decision starts by showing that standard capability genuinely falls short. After that, the business justification, the most stable extension route available, the upgrade impact of dependencies, the extension’s lifecycle and the approval process are assessed together. Clean core is not a rule that forbids custom development; it is the discipline behind this assessment.

  • Prepared by Castintech
  • Last verified 23 September 2026
  • 12 min read
  • Sources

In this guide

Sections

Scope and product context. This guide is a general assessment framework for extension decisions in SAP® software. The A–D level model described here was defined by SAP for use when extending SAP Cloud ERP Private [2]; for code written in the ABAP® programming language, its levels are mapped to ABAP Test Cockpit (ATC) findings [2][3]. The model does not apply directly to other products or installations; its validity for your landscape should be checked against your product and release scope. The other sections are product-independent decision principles and reflect Castintech’s assessment framework.

What does clean core mean, and what does it not mean?

SAP defines clean core as a set of guiding principles that support continuous business transformation and modernisation [1]. The principles aim to keep a system upgradable and open to change. Clean core does not mean “never write custom code”; it means choosing deliberately which extension is built, by which route, and at what accepted cost and risk.

SAP’s extensibility white paper likewise proposes a four-level classification instead of splitting extensions into just “clean” and “not clean” [2]. That approach accepts that the decision is not black and white: some business requirements may call for a lower level. What matters is that the impact is accepted knowingly and recorded.

The extension decision path: standard capability, business justification, highest clean core level, dependencies and lifecycle, ending in a decision and exception record. Start: an extension request. The path runs top to bottom through six numbered stops. Decision point 1: does standard capability really fall short? If it meets the need, the path leaves extension altogether: configuration, a process variant or a small change to the process. The outcome of the check is recorded with its type of evidence; a documented trial is marked as evidence, an opinion as an assumption. Decision point 2: can the business justification carry the lifetime load of testing, documentation and upgrade checks? If not, a solution closer to standard may be the better choice. Decision point 3: the highest applicable clean core level. On a four-stop scale from A to D, A (highest) is assessed first; D is not recommended. If a lower level is required, a dashed exception path goes straight to the decision record with its reason and impact. Scope boundary: the A–D model is defined by SAP for extending SAP Cloud ERP Private; in any other environment its scope must be confirmed. Step 4: what dependencies affect at upgrade; step 5: lifecycle and ownership. End, step 6: the decision and exception record, holding the chosen route and level, justification and lifetime load, dependencies, lifecycle and owners, approving role and date, assumptions and the reason for any exception. A role defined in advance approves the exception; the requester and the approver are not the same person. The diagram has no loop. On mobile the diagram reads as three panels in order: 1/3 standard capability and business justification, 2/3 level, dependencies and lifecycle, 3/3 decision and exception record. Colophon: Castintech, D1, September 2026; technical explanatory diagram, not an SAP® product interface. D1 · EXTENSION DECISION The extension decision path Shows the questions an extension request passes through, from the standard capabilitycheck to the decision and exception record. decision point assessment step outcome open node evidence assumption scope boundary main path branch exception path 1 Does standard capability really fall short? The business need is written apart from the proposed solution;the outcome of the check is recorded with its type of evidence. documented trial opinion: stays an assumption MEETS IT Met by standard Configuration, a process variant or a smallchange to the process FALLS SHORT 2 Can the business justification carry the lifetime load? The justification comes from the difference it makes to thebusiness; the testing, documentation and upgrade-check load isnoted next to it qualitatively. CANNOT A solution closer to standard May be the better choice if the justificationcannot carry the total load CARRIES IT 3 What is the highest applicable clean core level? The highest level is assessed first. A lower level is chosen whena requirement makes it necessary, with its impact accepted. CLEAN CORE LEVEL A B C D FIRST highest not recommended The A–D model is defined by SAP for extendingSAP Cloud ERP Private; in any other environmentits scope must be confirmed. 4 What do dependencies affect at upgrade? Standard objects relied on, their levels and the chain of customobjects are listed; the focus of upgrade testing follows from this. 5 Are the lifecycle and ownership written down? Business and technical owner, test scope, review trigger andremoval condition are decided before the extension goes live. Decision and exception record Chosen route and level Justification and lifetime load Dependencies Lifecycle and owners Approving role and date Assumptions and steps to confirm them Reason for the exception andaccepted impact A role defined in advance approves the exception; the requester and the approver are not the same person. 6 LOWER LEVEL: REASON ANDIMPACT RECORDED Castintech · D1 · EN · September 2026 Technical explanatory diagram; it is not an SAP® product interface.
  1. D1, panel 1/3: an extension request first asks whether standard capability really falls short, then whether the business justification can carry the lifetime load. On mobile the diagram reads as three panels in order: 1/3 standard capability and business justification, 2/3 level, dependencies and lifecycle, 3/3 decision and exception record. Panel 1/3. Decision point 1: does standard capability really fall short? If it meets the need, the path leaves extension altogether: configuration, a process variant or a small change to the process. The result is logged with its evidence type; a documented trial is marked as evidence, an opinion as an assumption. Decision point 2: can the business justification carry the testing, documentation and upgrade load? If not, a solution closer to standard may be the better choice; if it can, the path continues in 2/3. Colophon: Castintech, D1, September 2026; technical explanatory diagram, not an SAP® product interface. D1 · EXTENSION DECISION 1/3 The extensiondecision path Shows the questions an extensionrequest passes through, from thestandard capability check to thedecision and exception record. decision point open node evidence assumption main path branch 1 Does standard capabilityreally fall short? The need is written apart fromthe solution; the result islogged with its evidence type. documented trial opinion: stays an assumption MEETS IT Met by standard Configuration, a processvariant or a small changeto the process FALLS SHORT 2 Can the businessjustification carry thelifetime load? Justified by its businessdifference; its testing,documentation and upgradeload is noted. CANNOT A solution closer tostandard May be the better choiceif the justification cannotcarry the total load CARRIES IT CONTINUES IN 2/3: LEVEL,DEPENDENCIES AND LIFECYCLE Castintech · D1 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
  2. D1, panel 2/3: the highest applicable clean core level is chosen on an A to D scale, starting from A; then dependencies and the lifecycle are written down. On mobile the diagram reads as three panels in order: 1/3 standard capability and business justification, 2/3 level, dependencies and lifecycle, 3/3 decision and exception record. Panel 2/3. Decision point 3: the highest applicable clean core level. On a four-stop scale from A to D, A (highest) is assessed first; D is not recommended. If a lower level is required, its reason and impact go into the record in 3/3. Step 4: what do dependencies affect at upgrade? Step 5: lifecycle and ownership are set before go-live. Scope boundary in the colophon: the A–D model is defined by SAP for extending SAP Cloud ERP Private; in any other environment its scope must be confirmed. Colophon: Castintech, D1, September 2026; technical explanatory diagram, not an SAP® product interface. D1 · EXTENSION DECISION 2/3 Level, dependenciesand lifecycle decision point assessment step exception path main path scope boundary 3 What is the highestapplicable clean corelevel? A lower level is chosen onlywhen a requirement makes itnecessary, with its impactaccepted. CLEAN CORE LEVEL A B C D FIRST highest not recommended Lower level: reason andimpact recorded (3/3) 4 What do dependenciesaffect at upgrade? Dependencies on standard andcustom objects are listed;upgrade testing focuses onthem. 5 Are the lifecycle andownership written down? Owners, test scope, reviewand removal condition are setbefore go-live. CONTINUES IN 3/3: DECISIONAND EXCEPTION RECORD The A–D model is defined by SAP forextending SAP Cloud ERP Private; inany other environment its scope mustbe confirmed. Castintech · D1 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
  3. D1, panel 3/3: the path ends in the decision and exception record, which holds the chosen route, level, justification, dependencies, owners, approval and assumptions. On mobile the diagram reads as three panels in order: 1/3 standard capability and business justification, 2/3 level, dependencies and lifecycle, 3/3 decision and exception record. Panel 3/3. Step 6: the decision and exception record, holding the chosen route and level, justification and lifetime load, dependencies, lifecycle and owners, approving role and date, assumptions and the reason for any exception. A role defined in advance approves the exception; the requester and the approver are not the same person. The diagram has no loop. Colophon: Castintech, D1, September 2026; technical explanatory diagram, not an SAP® product interface. D1 · EXTENSION DECISION 3/3 Decision andexception record outcome evidence assumption exception path main path OUTCOME OF STEPS 1–5 AND OFTHE EXCEPTION PATH 6 Decision andexception record Chosen route and level Justification and lifetimeload Dependencies Lifecycle and owners Approving role and date Assumptions and steps toconfirm them Reason for the exceptionand accepted impact A predefined role approvesexceptions; the requestercannot approve. Castintech · D1 · EN · September2026 Technical explanatory diagram; it is not anSAP® product interface.
Text description of the diagram

Start: an extension request. The path runs top to bottom through six numbered stops. Decision point 1: does standard capability really fall short? If it meets the need, the path leaves extension altogether: configuration, a process variant or a small change to the process. The outcome of the check is recorded with its type of evidence; a documented trial is marked as evidence, an opinion as an assumption. Decision point 2: can the business justification carry the lifetime load of testing, documentation and upgrade checks? If not, a solution closer to standard may be the better choice. Decision point 3: the highest applicable clean core level. On a four-stop scale from A to D, A (highest) is assessed first; D is not recommended. If a lower level is required, a dashed exception path goes straight to the decision record with its reason and impact. Scope boundary: the A–D model is defined by SAP for extending SAP Cloud ERP Private; in any other environment its scope must be confirmed. Step 4: what dependencies affect at upgrade; step 5: lifecycle and ownership. End, step 6: the decision and exception record, holding the chosen route and level, justification and lifetime load, dependencies, lifecycle and owners, approving role and date, assumptions and the reason for any exception. A role defined in advance approves the exception; the requester and the approver are not the same person. The diagram has no loop. On mobile the diagram reads as three panels in order: 1/3 standard capability and business justification, 2/3 level, dependencies and lifecycle, 3/3 decision and exception record. Colophon: Castintech, D1, September 2026; technical explanatory diagram, not an SAP® product interface.

Step 1: Does standard capability really fall short?

An extension request often arrives as a ready-made solution: “add this check to that field.” The first step is to separate the business need behind it from that solution. Once the need is clear, check whether standard configuration, an existing process variant or a small change to the process would meet it.

Questions answered at this step:

  • Which business outcome does the need protect or deliver?
  • Can standard configuration meet it, and who checked this, on which release?
  • Could a change to the process cost less overall than an extension?
  • Is the need temporary, for example specific to a transition period, or permanent?

Record the outcome of this step with its type of evidence as well. Does “standard capability falls short” rest on someone’s opinion or on a documented trial? An opinion stays in the decision log as an assumption, with a plan to confirm it.

Step 2: What is the business justification?

SAP recommends prioritising extensions for business-differentiating processes [1]. By that logic, an extension should be justified by the difference it makes to the business, not by the fact that it is technically possible. The justification is written around three questions: which process, what difference, and what would be lost without it, in terms the business owner understands.

For management, this step is an investment decision. An extension is not built once and forgotten: it is tested, documented, checked at every upgrade and eventually removed. If the justification cannot carry that total load, a solution closer to standard may be the better choice. To make the decision easier, a qualitative note of the extension’s lifetime load sits next to the justification: which tests, documents and upgrade checks it will need.

Step 3: At which level can the extension be built?

If an extension is needed, choose the most stable route available. SAP recommends using the highest applicable level when extending SAP Cloud ERP Private [2]. A lower level can be chosen when a specific business or technical requirement makes it necessary, and its impact on upgrade stability and clean core compliance is accepted [2].

LevelShort descriptionATC behaviour
Level A Only released interfaces and extension points are used; SAP provides them under a stability contract (a technical term, not a commercial agreement)No finding
Level B Classic APIs and classic extension points are used; stability rests not on a contract but on SAP product experts nominating these APIsPriority 3 finding (information)
Level C SAP internal objects are accessed; considered conditionally clean. A changelog for SAP objects helps reveal incompatible changes in a new releasePriority 2 finding (warning)
Level D Objects or techniques that are not recommended are used, such as modifications and writing directly to SAP tablesPriority 1 finding (error)

The table is a condensed description of the official definitions [2][3]; for exact definitions and object type coverage, refer to the documents in the sources. In practice, which level an object shows up at should also be checked against the check variant and release in use.

According to the SAP white paper, Level A extensions can be built in two domains: outside the core system on a separate platform (side-by-side), or inside the core system using released local APIs (on-stack) [2]. Which suits a case depends on how close to core data the extension needs to work and on the organisation’s operating model.

Actual product screen

API State tab of a class; release state Released for Contract C1.

Scroll horizontally to read the screen, or select the image to open it at full size.

What the screen shows The “API State” tab in the properties view of a standard class: in the system-internal use contract (Contract C1), the release state is “Released” and use in cloud development is “Yes”.

Decision it explains When choosing the extension level, whether the standard object relied on has a release contract is checked on this tab and written into the decision record.

Data The image contains no business data; an SAP standard class and its source code comment are visible. The project label and the last-change fields are masked in the source image by SAP.

Product: ABAP Development Tools Source: SAP-samples/abap-cheat-sheets © 2022 SAP SE or an SAP affiliate company and abap-cheat-sheets contributors License: Apache License 2.0, used without modification

Step 4: What do dependencies affect at upgrade?

An extension’s upgrade risk depends on the stability of the objects it touches. Released interfaces come with a technical stability contract, whereas SAP does not guarantee long-term stability for its internal objects [2]. So for each extension, list the standard objects it relies on and the level at which each is classified.

The dependency list also decides where upgrade testing should focus. For extensions that rely on Level C objects, whether the new release contains an incompatible change is checked via the changelog [2], and that check is written into the upgrade plan as a step.

Dependencies on other custom objects belong on the list too. A change to one custom object can affect the extensions built on top of it; if that chain is invisible, upgrade testing focuses on standard objects only and may miss the real breaking point.

Step 5: How is the extension’s lifecycle planned?

Every extension will one day change or be removed. So when it is created, decide who owns it, how it is tested, where it is documented and under which conditions it will be reviewed, before it goes live. If standard capability later comes to meet the need, retiring the extension is considered as an option.

A lifecycle record should hold:

  • the business owner and the technical owner
  • the scope of the automated tests that protect the extension
  • review triggers: an upgrade, a process change, new standard capability
  • the removal condition and the processes removal would affect
  • where the documentation lives and when it was last updated

Step 6: How is governance set up?

Governance keeps decisions from depending on what individual people happen to know. Write down in advance who may approve an extension at which level, how exceptions are recorded and how the rules are enforced during development. If the rule is not written down, the same debate is held again with every request, and decisions can follow whoever pushes hardest.

For the ABAP environment on SAP Business Technology Platform (SAP BTP), SAP’s published governance recommendation describes a central ATC check system, a blocking mode in the development system for priority 1 and 2 findings, and the use of exemptions or a baseline for legacy code [4]. That recommendation is written for that environment; how similar governance would be set up elsewhere is assessed separately against the product and release scope.

Castintech’s approach puts three rules first: apply the rules to new development from the start, track legacy code against its own baseline, and record every exception together with its reason. That way the weight of legacy code does not block new development, and new development does not make legacy problems worse.

What does a decision record look like?

The template below is filled with a fictional example; it is not taken from a real project.

FieldExample content
Request Add a field and a related validation rule to a specific document type
Business need Information left incomplete at entry creates correction work in later steps
Standard capability check Standard configuration options reviewed; evidence type: documented trial
Justification The need concerns process quality, not a differentiating process; a process change is assessed first
Chosen route and level Level A if a released extension point can be used; if not, options and their impact are recorded separately
Dependencies Standard objects used and their levels; related custom objects
Lifecycle Business and technical owner, test scope, review trigger, removal condition
Approval Approving role and date
Assumptions Unconfirmed assumptions and the steps to confirm them

Common wrong assumptions

  • “Clean core means removing all custom code.” It does not. The aim is to choose extensions deliberately and build them through stable routes; for a differentiating process, an extension can be the right decision.
  • “No ATC findings means the extension is ready for upgrade.” The absence of findings is limited to the scope of the chosen check variant. Business logic, test coverage and performance are assessed separately.
  • “The level model applies the same way to every SAP product.” The model is defined in the context of SAP Cloud ERP Private; if it is used elsewhere, its scope should be confirmed.
  • “Level D extensions must be rewritten immediately.” Use and need are confirmed first. For an extension nobody uses, the first option is to retire it.
  • “Once approved, an extension is permanent.” As standard capability, processes and releases change, the justification for the extension is reassessed.

Checklist

  • The business need is written separately from the proposed solution
  • A standard capability check was made and its evidence type recorded
  • The business justification and lifetime load of the extension are written down
  • The highest usable level is identified; if a lower level was chosen, its reason and impact are recorded
  • The validity of the level model for the landscape is confirmed against product and release scope
  • Dependencies on standard and custom objects are listed
  • The focus points for upgrade testing are defined
  • The business owner and technical owner are named
  • Review triggers and the removal condition are written down
  • The approving role and the exception record are complete

Limits of this guide

This guide is a general technical explanation. The A–D level model and its ATC mapping rest on SAP documentation and apply in the context of SAP Cloud ERP Private. The other sections are Castintech’s assessment framework and should not be read as SAP’s view. We do not claim any particular timeline, cost or upgrade outcome. Product-dependent information may have changed since the last verification date.

Frequently asked questions

Is a Level B or Level C extension a mistake?

No. SAP itself states that lower levels can be used for specific requirements, provided their impact on upgrade stability and clean core compliance is accepted [2]. What matters is that the reason for the choice and its impact are on record.

Should existing extensions be assessed with this framework too?

Yes, especially before an upgrade or a transformation. The order differs, though: use and ownership are confirmed first, and for unused extensions the first option is retirement. The method is set out in the custom code inventory guide.

Where does level information come from?

According to SAP documentation, the levels map to ATC findings [2][3]. For the levels to show on the system dashboard in SAP Cloud ALM, ATC results have to be imported [3]. Which tools are available in your landscape should be confirmed separately.

Is a side-by-side extension always better?

Extensions that run outside the core system can make it easier to stay decoupled from the core, but they bring network, authorisation, monitoring and operating overhead. The choice depends on how close to core data the extension needs to work and on the organisation’s operating model.

Who should make the extension decision?

The process owner decides whether it is needed; the technical architecture owner decides the route and level. Exceptions that require a lower level are approved by a role defined in advance, and the same person should not be both requester and approver.

Sources

Bracketed numbers in the text refer to the sources below.

  1. 1

    ERP clean core strategy — sap.com.

    https://www.sap.com/products/erp/rise/methodology/clean-core.html

    Source date: not stated on the page Last verified: 23 September 2026

  2. 2

    Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP white paper, section 3.3 (pp. 19–22) and note 8 (p. 51).

    https://www.sap.com/docs/download/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.pdf

    Source date: no explicit publication date in the document; p. 52 shows “(08/26)” and “© 2026” Last verified: 23 September 2026

  3. 3

    Extensibility — help.sap.com, SAP Cloud ALM application help.

    https://help.sap.com/docs/cloud-alm/applicationhelp/extensibility

    Source date: not stated on the page Last verified: 23 September 2026

  4. 4

    Keep Clean Core Governance with ABAP Test Cockpit — help.sap.com, SAP BTP developer’s guide.

    https://help.sap.com/docs/btp/btp-developers-guide/keep-clean-core-governance-with-abap-test-cockpit

    Source date: not stated on the page Last verified: 23 September 2026

  5. 5

    SAP Cloud ERP Private — sap.com product page.

    https://www.sap.com/products/erp/cloud-erp-private.html

    Source date: not stated on the page Last verified: 23 September 2026

  6. 6

    SAP Business Technology Platform — sap.com product page.

    https://www.sap.com/products/technology-platform.html

    Source date: not stated on the page Last verified: 23 September 2026

Last verified: 23 September 2026

SAP and ABAP are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.

This content has been independently prepared by Castintech.

Independence note

  • Castintech does not claim any partnership, authorization, endorsement or sponsorship relationship with SAP SE.
  • SAP and the SAP product names mentioned on this page are trademarks of SAP SE or its affiliates.
  • The work Castintech offers is independent technical consulting and support.

Cookies and measurement

Apart from what the site needs to work, measurement or advertising tags only run if you allow them. No measurement tags are active on this site right now. Details