Clean Core: The New Threshold for ERP Systems in the AI Era

When ERP's "Dead Code" Breaks the AI Copilot

Klaus retired in 2019. The ZSD_ORDER_FIX_V4 function module he left behind has only one line of documentation: // FIXME: remove after 2015 upgrade. It's now 2027, and this function still runs every time a sales order enters the delivery process.

This isn't a gothic tale of technical debt—it's the real bottleneck for enterprise AI adoption today. A CIO discovered that the AI copilot could draft sales orders and suggest delivery dates, but when it triggered the pricing engine—three custom user exits, one Z table, and the wrapper logic of ZSD_ORDER_FIX_V4—it didn't throw an error. It simply went "blind." The order looked fine on screen, but it was destined to fail at the warehouse level.

The architect gave a blunt explanation: "The model was never trained on our Z logic. Embedded agents can't call unpublished function modules. No amount of prompt engineering will teach it what ZSD_ORDER_FIX_V4 does, because the only documentation retired in 2019."

A Few Key Terms in SAP ERP

The so-called Z namespace is the namespace SAP reserves for customer custom development. SAP standard objects start with specific letters (like MARA, VBAK), while any program, table, or function module starting with Z or Y was created by the customer. In ZSD_ORDER_FIX_V4, the Z indicates custom, SD refers to the Sales and Distribution module, and V4 suggests this is the fourth version. The number of Z objects is a direct indicator of "extension debt."

User Exit is a hook point SAP reserves in standard processes, allowing customers to insert custom logic without modifying standard code. BAdI (Business Add-In) is its object-oriented modern replacement, supporting multiple implementations and version management. The difference: user exits are "folklore"-style implicit extensions, while BAdIs are contractual, publishable extension points.

BTP (Business Technology Platform) is SAP's cloud platform for building extensions, integrations, and data applications outside the core system. Moving differentiated logic to BTP is precisely the physical vehicle that gives custom code "a contract"—services on BTP communicate with the S/4HANA core through published APIs.

Why AI Changed the Math: From Annual Upgrade Costs to Continuous Interest

For the past two decades, "Clean Core" has been a slogan on SAP marketing slides, politely ignored by customers who kept things running on twenty years of Z code. Custom code wasn't always technical debt—it was how ERP adapted to the business.

But AI's entrance changed the cost structure. Previously, the cost of custom code hit at upgrade time, roughly once a year, and the bill was testing effort. Now, the cost is continuous—every AI feature, every embedded agent, every "intelligent" capability is designed for standard processes and shrugs at your custom logic. The extension debt didn't grow, but the interest rate went up.

Here's the core insight: AI can work with anything that has a contract. It cannot work with "folklore." Clean Core is the process of turning folklore into contracts.

Clean Core Isn't About Removal—It's About Drawing Boundaries

The most common misreading of Clean Core is "no custom code allowed." In reality, it means: custom code lives outside the core, communicates with the core through published APIs, and keeps standard behavior standard. The differentiated logic the business actually needs doesn't disappear—it migrates to the BTP side, or into extension points designed for upgrades, where there's documentation, versioning, and—critically—where anything that can read an API can see it.

So what's actually in your Z namespace? Based on the typical distribution from industry migration assessments:

Category	Typical Share	Fate
Dead code, unused	~45%	Delete. No transport needed.
Duplicates standard	~25%	Retire. Use standard objects.
Trivially replaceable	~20%	Rewrite via public APIs / BAdIs.
Truly differentiated	~10%	Move to BTP extensions / side-by-side. Give it a contract.

Viewed this way, Clean Core is essentially an inventory problem: of your 4,000 custom objects, which encode genuine competitive advantage, and which are just 2007 workarounds for limitations SAP fixed in 2015? Every migration assessment we've seen points to the same conclusion—the vast majority of custom code is either dead, duplicating standard, or trivially replaceable. The small truly differentiated slice deserves rigorous engineering treatment. The rest is just risk with a transport number.

The Official Definition and Technical Boundaries of Clean Core

SAP's definition of Clean Core has three layers: No Modifications means not directly changing standard code—this is the baseline; No Implicit Extensions means not relying on unpublished internal interfaces, tables, or function modules, because these objects may be silently replaced during upgrades; Contractual Extensions means all custom logic interacts with the core through published APIs, BAdIs, or BTP services, with versioned, documented, discoverable interfaces.

The key to this definition is "discoverability." AI agents and any external tool can only call published interfaces with metadata descriptions. Unpublished function modules exist at the ABAP level but are invisible at the API gateway level—this is the technical reason the copilot "can't see" ZSD_ORDER_FIX_V4. Clean Core isn't an aesthetic requirement; it's about making the core system observable and callable for AI and other automation tools.

An Honest Ordering: How to Start Rather Than One-Time Cleaning

The trap is treating Clean Core as a standalone "virtue project"—no one allocates budget for hygiene habits. It only advances when tied to something the business already wants: S/4 migration, new AI capabilities, operating model changes. The actual sequence isn't glamorous:

1. Run a usage audit. Transaction code /UI5/UI2_CUST_ANALYSIS (or your tool)—filter for "last executed > 365 days." These get priority.
2. Delete the dead weight. No ceremony. No "just in case." If it hasn't run in a year, it's not differentiation—it's folklore.
3. Apply a forward-looking rule. New logic goes outside the core unless there's a written reason it can't. "We've always done it this way" is not a reason.
4. Give the survivors a contract. For the ~10% you keep: write the OpenAPI spec before moving the code. If you can't describe the interface, you don't understand the requirement.

You can't clean up twenty years of accumulation in one project. You can only stop making it worse and let time do its work. The companies that get this right aren't the ones with the purest systems—they're the ones that can answer three questions about any piece of custom logic: what it does, why it exists, and what API can replace it. In the ERP world, that answer is what AI-ready looks like. Models will keep improving on their own. Your Z namespace won't.

Someone still needs to document ZSD_ORDER_FIX_V4. AI won't write it. The question is whether you write it before the next copilot arrives, or after it fails again.

Practical Context on Usage Audit Tools and Migration Assessments

The /UI5/UI2_CUST_ANALYSIS mentioned in the article is one of SAP's custom code analysis tools, part of the SAP Readiness Check and Custom Code Migration workflow. It scans the ABAP repository and flags objects that are unused, duplicate standard, or depend on deprecated APIs. A more complete toolchain includes the SAP Custom Code Migration App (based on the ABAP Test Cockpit) and ATC (ABAP Test Cockpit) check variants, the latter of which can detect S/4-incompatible syntax and deprecated objects.

The core metric for audits is the last execution timestamp. The ABAP system records the last run date for programs, function modules, and transaction codes. Filtering for "last executed > 365 days" is a pragmatic threshold: code that hasn't run in a year is almost certainly not current business-differentiating logic. But note that some code only triggers during annual closing or extreme exceptions, so audit results still need business confirmation and can't be mechanically deleted.

Writing the OpenAPI Spec First matters because it means defining the behavioral contract of a piece of logic in a standard interface description language before moving code. If a team can't write an OpenAPI document for a piece of logic, it means they don't understand the real requirement behind that logic—this is precisely the root of the ZSD_ORDER_FIX_V4 dilemma.

Frequently Asked Questions

Does Clean Core mean no custom code at all?

No. Clean Core means custom code exists outside the core, interacts with the core through published APIs, and keeps standard functionality standard. Differentiated logic migrates to BTP extension points, gaining contracts and version management.

Why does the AI copilot "turn a blind eye" to custom ERP logic?

AI models aren't trained on the enterprise's Z logic, and embedded agents can't call unpublished function modules. Without documentation and contracts, the model can't understand the behavior of custom code, leading to suggestions that look normal but actually fail.

Where should enterprises start with Clean Core?

Start with a usage audit. Identify code that hasn't run in over a year and delete it first, then write API contracts for the differentiated logic you keep. Tie Clean Core to business goals like S/4 migration or AI capability adoption, rather than treating it as a standalone project.

One-line Summary

Undocumented Z code makes AI copilots blind to ERP custom logic—Clean Core is the prerequisite for AI readiness.

Paragraph Summary

Using the ZSD_ORDER_FIX_V4 function left behind by a retired employee as an example, the article reveals the real bottleneck for enterprise AI adoption: AI copilots can draft orders and suggest delivery dates, but can't understand unpublished Z logic, causing pricing and delivery processes to look normal while actually failing. The core insight is that AI can only work with systems that have contracts, not "folklore"-style custom code, which turns extension debt from an annual upgrade cost into continuous interest. Clean Core doesn't prohibit custom code—it moves differentiated logic out of the core and gives it contracts through BTP extensions and published APIs. In a typical enterprise Z namespace, about 90% is dead code, duplicates of standard, or trivially replaceable, with only about 10% truly differentiated. The pragmatic path is to run usage audits to delete dead code, apply forward-looking rules to new logic, and write OpenAPI specs before migrating the differentiated logic you keep.