How many Z programs does your SAP system have? And how many of them could someone on your team explain — in detail, without hesitation — right now?
If the honest answer is “I’m not sure” or “only Maria knows that,” you’ve just identified one of the most underestimated technical risks in any organization running SAP ECC or S/4HANA.
Companies invest millions implementing SAP. They document standard processes, map business flows, train end users. But there’s a corner of almost every SAP system where critical logic hides in plain sight: the “Z world.” Hundreds or thousands of custom-built objects that nobody thought to document, that everyone relies on, and that — sooner or later — become the bottleneck of every migration, support escalation, or modernization project.
According to ASUG research, the average SAP ECC system carries more than 30,000 custom extensions. And between 40% and 70% of that code is never used. The organizations paying to maintain it often have no idea it even exists.
This article is about why a complete inventory of your SAP non-standard objects isn’t just a technical housekeeping task — it’s a strategic decision. And why the longer you wait, the more it costs.
The “Z World”: The Corner of SAP That Everyone Uses and Nobody Documents
In SAP, objects prefixed with Z or Y — or those belonging to a custom namespace like /COMPANY/ — are proprietary developments: code that didn’t come from SAP AG, but was created or commissioned by your organization to fill the gaps between the standard and your operational reality.
And there are always gaps.
No SAP implementation covers 100% of a company’s real processes. Industries have their own rules. Operations have nuances that no software vendor can anticipate. So, over the years, productive SAP systems accumulate:
- Z programs: reports, interfaces, mass processing jobs, integrations with external systems.
- Custom Function Modules and Classes: reusable business logic built in-house.
- Implemented Enhancements and BAdIs: subtle modifications to SAP’s standard behavior.
- Z Tables, Structures, and Data Elements: to persist information SAP doesn’t natively support.
- Custom SmartForms, SAPscripts, and Adobe Forms: printed documents like purchase orders, labels, invoices.
- Custom transactions, user menus, and authorization objects: the entire access layer built to spec.
In a mid-sized company with several years of productive SAP, this can represent hundreds or thousands of objects. Large enterprises or organizations with long SAP histories routinely exceed 5,000 or 10,000 active non-standard objects.
The problem isn’t that they exist. The problem is they’re almost never documented.
They get created to solve a specific problem. They work. They get forgotten. A year later, someone modifies them to solve another problem. And so it goes for a decade — until nobody knows exactly what each one does, what it depends on, or whether it’s still needed at all.
The Real Risk: When Knowledge Lives in People, Not Systems
There’s a concept in software engineering called the “bus factor”: how many people on your team would have to be hit by a bus for critical system knowledge to disappear?
In most SAP environments, that number is one. Or two.
There’s the ABAP consultant who’s been on the project for ten years and “knows the system.” She knows that program ZFACT_EXPORT_EDI has a special exception for customers in Group X. She knows the WMS interface doesn’t use the standard BAPI — it uses a custom function module someone wrote in 2011 because the BAPI had a bug. She knows why there’s a Z table with 400,000 records that nobody purges.
When she leaves — and eventually she will — that knowledge leaves with her.
What remains is a support ticket that takes three days to resolve because the current team has to read a 2,000-line program with no comments, line by line, to understand what’s failing. Or a migration project delayed by months because nobody can say with certainty which Z objects are active, which are obsolete, and which are business-critical.
ASUG research found that 45% of organizations say their most valuable custom code was deployed six or more years ago — meaning the people who built it have most likely moved on. Meanwhile, 29% of companies cite maintaining knowledgeable staff as a top challenge, and 33% struggle to find the expertise needed to maintain and enhance their custom developments.
SAP’s own Custom Code Migration documentation puts it plainly: “The code has been implemented many years ago, often expands over multiple pages, has very little or no documentation, the author of the code is not available anymore for questions.”
That’s not a technical limitation. That’s institutional amnesia — and it’s one of the most expensive silent costs in enterprise IT.
Clean Core in SAP S/4HANA: Without a Map, There Is No Route
If you’re running SAP ECC or planning a move to S/4HANA, you’ve almost certainly heard about Clean Core. It’s no longer a recommendation — at SAP Sapphire 2024, SAP leadership made clear that Clean Core is essentially mandatory for any modern ERP strategy.
SAP defines Clean Core as keeping the S/4HANA environment as close as possible to standard, with all extensions built externally through approved frameworks — primarily SAP Business Technology Platform (BTP) and ABAP Cloud. The guiding principle: any customization must be decoupled from the core so that upgrades remain stable, processes stay agile, and innovation can be adopted without friction.
In August 2025, SAP formalized this into a four-level maturity classification for custom code:
- Level A (Fully Compliant): Uses only publicly released, stable SAP interfaces. The gold standard for all new development.
- Level B (Compliant): Meets Level A criteria but also uses classic APIs (BAPIs, IDocs, RFCs). Generally upgrade-stable.
- Level C (Partially Compliant): Accesses SAP internal objects. Carries upgrade risk. Must be on a documented remediation roadmap.
- Level D (Non-Compliant): Uses explicitly prohibited patterns — direct modifications, write access to SAP tables, implicit enhancements. Must be eliminated.
The ABAP Test Cockpit (ATC) automates this classification, and in S/4HANA 2025, Clean Core checks are delivered natively. The enforced policy is unambiguous: no new D-level code; all C-level code must have a refactoring plan.
Here’s the catch: to classify your custom code, you first need to know it exists.
You can’t remediate what you haven’t inventoried. You can’t prioritize what to refactor, what to move to BTP, what to eliminate, and what to keep — if you don’t have a complete, accurate map of your Z landscape.
Organizations arriving at S/4HANA migration projects without that map face predictable consequences. A 2025 Horváth Partners study of 200 companies found that 60% of S/4HANA projects exceeded budget, and only 8% completed transformation on schedule. The leading culprit, consistently cited across multiple independent studies: undocumented and unmanaged custom code.
The custom code is usually not the enemy. The lack of visibility into it is.
Why a Manual Inventory Is Never Enough
The typical approach looks like this: a project kickoff meeting, a spreadsheet shared on SharePoint, an email to the ABAP team asking them to “document their programs,” a few weeks of half-hearted entries, and a file nobody updates after go-live.
It fails for predictable reasons:
First, it’s not exhaustive. Teams document the programs they remember or use most often. The long-tail of objects — legacy integrations, one-time reports that were never decommissioned, enhancement implementations from three consultants ago — never makes it into the spreadsheet.
Second, it goes stale immediately. SAP systems aren’t static. New objects get created, existing ones get modified, some get abandoned. A point-in-time manual inventory is outdated within weeks.
Third, it doesn’t capture dependencies. Knowing that ZREPORT_ORDERS exists is different from knowing that it calls function module ZFUNC_PRICING, which reads table ZCUST_MARGINS, which is updated by a batch job that runs every night. Manual documentation almost never captures this graph of dependencies.
Fourth, it doesn’t serve AI. As organizations move toward AI-assisted support and development, the format of documentation matters. A free-text Word document describing what a program “sort of does” isn’t useful for an AI agent that needs structured, indexed, vectorized knowledge to reason accurately about code.
The gap between “we have something documented” and “we have real visibility” is enormous — and expensive.
Clean Core Starts Before the Migration: The Hidden Cost of Unmanaged Z Code
The financial reality of unmanaged custom code is striking.
ASUG research found companies spend an average of $815,857 per year to maintain their most valuable SAP custom code. For 37% of organizations, this represents up to 50% of annual IT spend. And custom code support, across the customer base, can add 33% on top of standard SAP maintenance costs — before a single enhancement request is opened.
When migration begins, the costs accelerate. Implementation services — including custom code analysis, remediation, and adaptation — represent 40–60% of total S/4HANA migration cost (Tachyon Technologies). Panaya estimates custom code work accounts for approximately 40% of migration effort. And 43% of organizations in a 2025 SAPinsider benchmark cited remediating custom code as their top migration obstacle.
These numbers aren’t a reason to panic. They’re a reason to prepare. The organizations that manage migration costs effectively are the ones that started with a complete, current inventory — knowing exactly what they had, what was still used, and what could be retired before the migration clock started running.
In fact, a SAP Community case study documented one company retiring nearly 10% of their custom code before migration simply by identifying unused objects through usage analysis — objects that would have been carried forward, analyzed, adapted, and tested at significant cost if they hadn’t been identified first.
“Joule Knows SAP. It Doesn’t Know Your SAP.”
At this point, a reasonable question arises: can’t SAP’s own AI tools handle this?
SAP Joule is genuinely impressive. SAP built a purpose-specific large language model trained on 250 million lines of ABAP code and 30 million lines of CDS code, plus extensive SAP technical documentation. It can generate code, explain programs, write unit tests, suggest S/4HANA adaptations, and navigate ABAP Cloud development — all within the IDE.
But there’s an architectural boundary that Joule cannot cross: it has zero knowledge of your company’s specific Z/Y code.
SAP is explicit about this: customer data is never used for training, and it’s never shared with any third party. The ABAP LLM was trained on SAP’s own standard code — not on the custom function modules your team wrote in 2009, not on the Z tables that hold your pricing exceptions, not on the enhancement framework implementations that modify standard purchasing behavior in ways that only two consultants ever understood.
Joule can analyze a specific custom object when a developer manually selects it in the IDE and asks for an explanation. But that’s a single-object interaction — it doesn’t give Joule any systemic awareness of your custom landscape. It can’t proactively tell you which Z transactions are actively used. It can’t map the dependencies between your custom objects. It can’t explain why a specific customization was built or what business logic it encodes, unless that logic happens to be documented in code comments (which it almost never is).
As SAP partner Arvato Systems puts it: “In the case of standard solutions, SAP Joule is simply available at the touch of a button. For customized developments, on the other hand, providing the AI assistant can be quite challenging.”
This isn’t a criticism of Joule — it’s a structural reality. General-purpose and standard-code AI tools are powerful within their domain. They cannot substitute for a knowledge base built from your specific code.
Joule knows SAP better than any tool ever has. It doesn’t know your SAP. That distinction matters enormously.
SiDOC: From Chaos to a Complete Map of Your SAP Custom Code — in Under 10 Days
This is the problem that SiDOC, developed by Innova Apps, was built to solve.
SiDOC is a three-step solution that automatically inventories, documents, and activates the knowledge contained in your SAP custom code — turning your Z landscape from a liability into a queryable, AI-ready knowledge asset.
Step 1 — Extract: Complete Inventory in ~15 Minutes
An ABAP program (delivered as a standard SAP transport) is installed in the customer’s system and automatically extracts every non-standard object: programs, function modules, classes, tables, structures, data elements, domains, table types, transactions, enhancements, SmartForms, search helps, and authorization objects. It generates organized output files containing source code, metadata, and a complete object list. Filters by package, date, and object type give teams the flexibility to scope the extraction precisely.
The result isn’t just a list — it’s a structured, complete map of everything that exists in your Z landscape, generated automatically and free of human omission bias.
Step 2 — Document: AI-Generated Documentation Built for Humans and Machines
An AI-powered processing layer consumes the extracted objects and generates structured Markdown documentation for each one: purpose, inputs, outputs, step-by-step processing logic, business rules, dependencies, and authorization requirements. Front-end objects (JavaScript, TypeScript, UI5, Fiori) are also documented if they exist.
Critically, this documentation isn’t built for a filing cabinet. It’s built for intelligence. The documentation layer applies the practices that make AI retrieval accurate and reliable:
- Indexing and mapping: cross-referencing objects, dependencies, and business contexts so that queries return relevant, connected results — not isolated fragments.
- Precision through chunking: breaking documentation into semantically coherent fragments that can be retrieved with precision, without losing context.
- Embedding and vectorization: structuring the knowledge base for semantic search so that natural-language queries return accurate, grounded answers.
For an ABAP package with ~1000 ABAP objects, this entire process runs automatically in 1 hour. No consultant required. No manual effort.
Step 3 — RAG Intelligence: Ask Questions, Get Answers About Your Own Code
The documented knowledge base connects to an AI agent that understands your specific SAP environment — the one your team actually built, not a generic approximation of it. This agent can:
- Support ABAP teams: when a bug is reported, the agent identifies which programs and function modules are involved, explains the logic, and proposes the likely root cause — without the consultant having to spend hours reading legacy code they’ve never seen.
- Generate technical specifications: for new development requests, the agent produces specs that follow your existing coding standards, reuse documented logic where applicable, and flag conflicts with existing functionality.
- Accelerate new development: by surfacing relevant existing objects, the agent prevents developers from reinventing logic that already exists — a surprisingly common and expensive problem in large SAP environments.
- Answer business questions about code: roles like IT managers, functional consultants, and project managers can ask in natural language what a specific Z transaction does, what tables it reads, and what business rules it applies — without opening the ABAP editor.
The delta function ensures the knowledge base stays current: when objects are modified, only the changed components are reprocessed. Your documentation doesn’t become a snapshot that ages into irrelevance — it stays alive.
The Strategic Payoff: Three Dimensions of Value
The benefits of a complete, AI-ready custom code inventory compound across three dimensions that matter to different stakeholders.
For CIOs and IT Leadership: Clean Core Readiness with Real Data
Instead of walking into an S/4HANA migration planning conversation with estimates and assumptions, your team arrives with a complete, classified map of the Z landscape. Every object identified. Usage patterns analyzed. A-D classification applied. Remediation scope quantified. Budget estimates are grounded in real object counts. Scope discussions are based on actual complexity, not ballpark percentages. And the Clean Core roadmap — what to refactor, what to move to BTP, what to retire — is driven by facts, not guesswork.
For ABAP Teams and Support: Stop Paying for Archaeology
Every hour an ABAP consultant spends reverse-engineering legacy code they’ve never seen is an hour that didn’t go toward solving the business problem. With SiDOC, the understanding is already there. This doesn’t replace ABAP expertise. It amplifies it. A team of three consultants with SiDOC operates more effectively than a team of five without it, because the institutional knowledge that used to live in a departing consultant’s head is now accessible to everyone.
For Project Teams: Migration Planning Without the Surprises
Nothing derails a migration project faster than discovering undocumented complexity mid-stream. SiDOC eliminates that category of surprise. By the time the migration project starts, every Z object is known, documented, and classified. The work is scoped accurately from day one.
From Black Box to Strategic Asset: A Different Way to Think About Custom Code
There’s a persistent instinct in SAP organizations to treat custom code as a liability — “technical debt” to be minimized, hidden, or eventually eliminated. That framing misses something important.
Your Z landscape exists because your business processes are genuinely different from the SAP standard. Those customizations encode years of operational learning: exceptions, rules, integrations, and edge cases that make your system work for your business. In many cases, they represent genuine competitive process advantages.
The problem was never the customization. The problem was the invisibility.
A documented, inventoried, AI-indexed custom code landscape isn’t a liability. It’s an asset — one that can be governed, maintained, evolved, and leveraged. The same logic that makes your Z code difficult to manage today makes it valuable once it’s understood.
The goal isn’t to eliminate the Z world. The goal is to stop being afraid of it.
You Can Have It in Under 10 Days
One more thing worth saying clearly.
The gap between “we don’t know what’s in our SAP system” and “we have a complete, AI-ready knowledge base of every custom object” is not a six-month project. It’s not a major consulting engagement. It doesn’t require a dedicated project team or a lengthy requirements phase.
With SiDOC, the extraction runs in a couple of hours. The AI documentation layer completes in 3–4 hours. The RAG agent is operational from day one. For most organizations, the entire process — from zero visibility to full, queryable inventory — takes fewer than 10 days from installation to active use.
The investment is a fraction of what most teams spend in a single week of ABAP support hours trying to understand legacy code that should have been documented years ago.
Your SAP system has been accumulating custom knowledge for years. It’s time to make that knowledge work for you.
Interested in seeing what SiDOC would find in your SAP system? Book a conversation with the Innova Apps team — no commitment, no setup required.
About Innova Apps
Innova Apps specializes in developing applications that optimize supply chain processes for companies running SAP ECC and SAP S/4HANA. “Your SAP processes, made easier.”
