Clean Core Is the Price of AI-Ready ERP
Why clean core went from SAP marketing slide to the hard prerequisite for enterprise AI. A story about Klaus, ZSD_ORDER_FIX_V4, and the copilot that went blind.
The retired developer's name was Klaus. He left in 2019. The only documentation for ZSD_ORDER_FIX_V4 is a comment that says // FIXME: remove after 2015 upgrade. It's 2027. The function module still runs every time a sales order hits delivery.
This is how your ERP dies: not with a bang, but with a Z-program nobody understands anymore.
For twenty years, "clean core" lived on SAP marketing slides — politely ignored by every customer with two decades of Z-code keeping the lights on. Custom code wasn't technical debt; it was how the ERP actually fit the business. Then enterprise AI arrived, and the joke stopped being funny. Every copilot, every embedded agent, every "intelligent" feature landing in S/4HANA assumes standard objects, released APIs, and predictable process flows. The customization that made the system yours is precisely what makes it invisible to the tooling everyone is buying.
Why AI Changed the Math
The demo was going fine. The copilot drafted a sales order. It suggested a delivery date. Then the pricing engine fired — three custom user-exits, a Z-table for delivery blocks, and ZSD_ORDER_FIX_V4 wrapping it all in a bow. The copilot didn't error. It didn't warn. It just… stopped seeing. The suggested delivery date was wrong. The pricing was wrong. The order looked clean on screen but would fail in the warehouse.
The CIO asked why. The architect said: "The model was never trained on our Z-logic. The embedded agent can't call unreleased function modules. No amount of prompt engineering teaches it what ZSD_ORDER_FIX_V4 does, because the only documentation is the developer who retired in 2019."
That's the quiet shift: custom code used to cost you at upgrade time, roughly once a year, and the bill was testing effort. Now it costs you continuously — every AI feature, every embedded agent, every "intelligent" anything arrives working for standard processes and shrugging at yours. The extension debt didn't grow, but the interest rate did.
Clean Core Is a Boundary, Not a Purge
The misreading of clean core is that it means "no custom code." It actually means: custom code lives outside the core, talks to the core through released APIs, and leaves standard behavior standard. The differentiating logic your business genuinely needs doesn't disappear — it moves to the BTP side of the fence, or into extension points designed to survive upgrades, where it is documented, versioned, and — critically — visible to anything that can read an API.
AI can work with anything that has a contract. It cannot work with folklore. Clean core is the process of turning folklore into contracts.
| Category | Typical Share | Fate |
|---|---|---|
| Dead, unused | ~45% | Delete. No transport needed. |
| Duplicates standard | ~25% | Retire. Use the standard object. |
| Trivially replaceable | ~20% | Rewrite via public API / BAdI. |
| Genuine differentiation | ~10% | Move to BTP extension / side-by-side. Give it a contract. |
Seen that way, the clean-core exercise is really an inventory question: which of your 4,000 custom objects encode real competitive differentiation, and which encode a 2007 workaround for a limitation SAP fixed in 2015? Every migration assessment we've seen lands in the same place — a decisive majority of custom code is either dead, duplicating standard, or trivially replaceable. The genuinely differentiating slice is small. That slice deserves proper engineering. The rest is just risk with a transport number.
Sequencing It Honestly
The trap is treating clean core as a separate virtue project — nobody funds hygiene. It only moves when attached to something the business already wants: the S/4 move, a new AI capability, an operating-model change. The practical sequence is unglamorous:
- Run the usage audit. Transaction
/UI5/UI2_CUST_ANALYSIS(or your tool of choice) — filter "last executed > 365 days." Those go first. - 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.
- Apply the forward 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.
- Contract the survivors. For the ~10% that stays: write the OpenAPI spec before you move the code. If you can't describe the interface, you don't understand the requirement.
You don't clean twenty years in one program. You stop making it worse and let attrition work. The companies getting this right aren't the ones with the purest systems. They're the ones who can answer, for any piece of custom logic: what it does, why it exists, and what API would replace it. That answer is what AI-readiness actually looks like in the ERP world. The models will keep improving on their own. Your Z-namespace won't.
Someone still has to document ZSD_ORDER_FIX_V4. The AI won't. The question is whether you do it before the next copilot arrives, or after it fails again.
Stay with us · poll
What's Your Take on ERP Modernization in the Age of AI?
Do you think your organization needs to prioritize cleaning up its ERP core for better AI integration?
No account needed — pick a take, then keep reading. We rotate these prompts so each piece feels like a conversation, not a clone.
