Topic page
Custom code inventory and technical debt in SAP® software: from list to decision
Custom code written over the years in the ABAP® programming language on SAP® software becomes, in most organisations, an invisible part of how business processes run. When a transformation, upgrade or maintenance decision comes up, the first thing people ask for is usually a list. This page explains how that list becomes a decision tool, and which kinds of evidence need to be kept apart.
- Prepared by Castintech
- Last verified 23 September 2026
- 8 min read
- Sources
On this page
Sections
What is the difference between an inventory and a raw object list?
A raw object list tells you which custom objects exist in the system. An inventory lets you make a decision about each one: is it used, who owns it, what does it depend on, what breaks if it changes, and what should happen to it?
The number of rows hints at the workload; only the answers to those questions settle the decision.
The difference matters to management. A plan based only on object counts can spend effort adapting code that nobody uses, and still miss a small object that carries a critical process.
Which dimensions make an inventory usable for decisions?
An inventory produces decisions when four dimensions are assessed together: evidence of use, business ownership, technical dependency and change risk. When one of them is missing, the decision rests on an assumption about it. Unless that assumption is written down, it can later be read as if it were evidence and end up supporting the wrong decision.
| Dimension | Question answered | Typical evidence |
|---|---|---|
| Use | Does this code actually run, and how often? | Runtime usage records |
| Ownership | Which process and which team need this code? | Confirmation with the process owner |
| Dependency | Which standard objects, interfaces and other custom objects does it rely on? | Static analysis and where-used lists |
| Change risk | What breaks if the code, or what it relies on, changes? | Code check findings, test coverage, change history |
Does running code mean necessary code?
No. A program that runs regularly does not prove that the business process still needs it. A scheduled job may be producing a report nobody reads; an interface may be sending data to a system that is no longer used. Evidence of use becomes evidence of need only when the business owner confirms it.
The reverse also holds: code that runs rarely is not necessarily unneeded. An object that runs once at year-end closing or for a statutory report may not show up at all in a short measurement window. That is why the period covered by the usage data is stated explicitly in the inventory.
Why keep static and runtime evidence apart?
Static evidence shows what the code can do and what it depends on; it comes from the source, without running the code. Runtime evidence shows how much, and under what conditions, the code actually runs. They answer different questions and cannot stand in for each other; a decision looks at both together.
Static analysis produces findings for unused objects too, while runtime data misses any use outside the measured period. In the decision table the two kinds of evidence sit in separate columns, so it stays visible which one is missing.
Why is code check output not the whole decision?
SAP describes the ABAP Test Cockpit (ATC) as a tool for static and dynamic quality checking of ABAP code and related repository objects [1]. For a move to SAP S/4HANA® software, checks are also provided that help identify critical uses of simplified SAP objects [2].
This output is valuable, but it does not say how much a finding matters to the business, whether the code is used or who owns it.
The tool’s scope also depends on the release. According to SAP documentation, some checks may not be available on older releases, in which case the code can be analysed remotely from a more current central check system [3]. The ATC workflow also includes requesting and approving exemptions for findings [3]. If the reason for an exemption is not recorded in the inventory, the same decision gets reopened at the next review.
What does an inventory show in a clean core context?
SAP’s clean core extensibility model classifies extensions on four levels, in the context of SAP Cloud ERP Private [5]. Level A uses only released interfaces and extension points; Level D uses objects or techniques that are not recommended [4][5]. According to SAP documentation, ATC finding priority maps to these levels: Level A produces no finding, Level D produces a priority 1 finding [4][5].
This classification adds an upgrade-risk axis to the inventory, but it does not replace use and ownership. If an object classified at Level D is never used, the first decision may be to consider retiring it rather than adapting it. The model and its product scope are covered in Extension decisions under a clean core approach.
Actual product screen
Scroll horizontally to read the screen, or select the image to open it at full size.
What the screen shows The “Released Objects” tree in the development environment’s project explorer: objects grouped by type and listed with their counts.
Decision it explains Whether an object in the inventory relies only on released objects is checked against this list; a clean core assessment builds on that distinction.
Data The image contains no business data; only object categories and counts are visible. The project name is 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
How does technical debt relate to transformation priority?
Technical debt is the part of today’s solution that makes future change more expensive. In the inventory, each item of technical debt is recorded together with the decision it makes harder: an upgrade, a process change or retiring a system. Technical debt that is not tied to a decision stays nothing more than a number on a priority list.
Transformation priority is therefore set not by the density of findings alone, but by the link to critical processes and by change risk. The maintenance timeline is a planning input too. Which dates apply to which product scope is set out, with sources, in Technical uncertainties before a transformation.
Which outputs are useful for management decisions?
What matters to management is less the number of objects and more the spread of decision categories and the questions still awaiting a decision. These outputs separate the decisions expected from management from the questions still waiting for evidence, so management can set priorities without going into technical detail. At the end of an inventory, expect:
- the spread by decision category: keep, adapt, return to standard, retire, investigate
- objects with no identifiable owner, and the processes they relate to
- objects with no evidence of use that still appear linked to a critical process
- findings that directly affect an upgrade or transformation
- a list of decisions resting on assumptions, and the steps that would confirm them
The method for building the inventory and the classification criteria are covered in Assessing a custom code inventory.
Text description of the diagram
Start: the raw object list; unnamed marks for programs, classes, tables and interfaces. The number of rows hints at the workload; it does not settle the decision. Objects that together perform one business function are grouped inside three dashed decision units; objects that fit no unit stay on a separate list and are not connected to the spine. Every decision unit passes the same evidence standard: evidence of use (with its measurement period; no usage record only shows it was not seen in the measured period), business ownership, dependencies with direction, change frequency, link to a critical process and technical risk (code check findings with check variant and date). The spine leads to decision point 1: is the evidence complete and consistent? If so, the unit goes to one of four outcome categories: keep, adapt, return to standard or retire; each category's next step is written down. If evidence is missing or contradictory, the unit is not forced into a category; a dashed path goes to the 'investigate' node, where the missing evidence and the decision owner are identified. Priority is set by assessing the link to a critical process and technical risk together. There is no loop. The objects are representative and unnamed; the diagram is not a table or an inventory screen. On mobile the diagram reads as three panels in order: 1/3 from raw objects to decision units, 2/3 the same evidence standard, 3/3 decision category. Colophon: Castintech, D2, September 2026; technical explanatory diagram, not an SAP® product interface.
What does this page not claim?
This page is a general technical explanation. It does not predict the outcome of an inventory, the amount of code or the length of a transformation. We do not claim that any tool produces an inventory decision on its own. Product- and release-dependent information carries its source and last verification date and should be rechecked in your own landscape.
Frequently asked questions
How much usage data does an inventory need?
No single period is right for every organisation. The measurement window is chosen so that it covers periodic processes such as month-end, quarter-end and year-end closing. Periods that are not covered are stated in the inventory, and decisions about objects tied to those periods are confirmed with the business owner.
Can unused code be deleted straight away?
A missing usage record is not enough on its own. There may be use outside the measurement window, an indirect call from other code, or a legal retention requirement. First confirm with the business owner, then plan a retirement step that can be reversed.
Is code without ATC findings necessarily sound?
No. The absence of findings shows that the issues the chosen check variant looks for were not found. Logic errors, performance behaviour and business-rule fit outside the check scope are assessed separately.
Who should own the inventory?
The development team can produce the technical part, but decisions on ownership and need come from the process owners. An inventory that names these two roles separately causes fewer loops back during the decision process.
Is one inventory enough?
No. New development, upgrades and process changes make an inventory go stale. Record when and with what evidence the inventory was last updated, and check that date at the point of decision.
Related guides and pages
- Assessing a custom code inventory: classification and prioritisation method
- Extension decisions under a clean core approach: scope of the level model and upgrade impact
- Technical uncertainties before a transformation: using maintenance timeline information with the right scope
- Integration approach
- Our working approach
Sources
Bracketed numbers in the text refer to the sources below.
- 1
Quality Checking with the ABAP Test Cockpit (ATC) — help.sap.com, ABAP platform documentation.
Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026
- 2
Static Code Checks in the Context of an SAP S/4HANA Migration — help.sap.com, ABAP platform documentation.
Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026
- 3
Usage Scenario and Technical Requirements — help.sap.com, ABAP platform documentation.
Source date: document version 2025 FPS01 (February 2026) Last verified: 23 September 2026
- 4
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
- 5
Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP white paper, section 3.3 (pp. 19–22).
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
Last verified: 23 September 2026
SAP, ABAP, and SAP S/4HANA 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.