SAP Finance Transformation, Explained Without the Sales Pitch ENES
The Intelligent Hub
By Juan Torre
SAP Finance Transformation
Transformación de Finanzas con SAP, explicada sin discurso de venta ENES
The Intelligent Hub
Por Juan Torre
Transformación de Finanzas con SAP

Clean Core in S/4HANA, 2026: The Architecture Decision Hiding Inside Every AI Business Case

Clean Core determines whether your S/4HANA landscape can actually run the agentic AI SAP is shipping, or whether every AI pilot quietly reverts to manual review. Here’s what it means in practice, what it costs to ignore, and how to sequence it inside a live migration.

Pillar 2: Clean Core & BTP Architecture | ~18 min read | By Juan Torre

In brief

  • Clean core is no longer optional: SAP’s own AI tooling needs it to work reliably, and about 50% of SAP customers are now actively using BTP for exactly this reason, up roughly 10 points from a year earlier, with another 26% just starting.
  • The rule in one line: nothing gets modified inside the SAP-delivered core. Extensions, integrations, and custom logic live outside it, on BTP, connected through released APIs.
  • Standard SAP AI agents, including the Cash Management Agent covered in last week’s article, only work out of the box on clean-core-compliant process flows.
  • Without governance, side-by-side extensibility on BTP just relocates technical debt instead of eliminating it — sprawl is the new risk, not customization.
  • A three-tier extensibility framework and a short readiness checklist below help you sequence this inside, not after, your S/4HANA migration.

The Claim From Last Week

Last week’s article on AI in SAP Finance made a specific claim near the end: that a landscape which isn’t clean core is a landscape where AI agents can’t be trusted to act autonomously, no matter how good the underlying model is. This article unpacks that claim properly. If AI is the layer everyone wants to talk about in 2026, clean core is the layer that decides whether that conversation is grounded in anything real.

The short version, for anyone coming to this cold: Clean Core is SAP’s principle of keeping the S/4HANA core as close to standard as possible, and building everything specific to your business, custom logic, integrations, extensions, outside of it, on SAP Business Technology Platform (BTP), connected back through released APIs rather than direct modification. It sounds like a technical hygiene rule. It is actually an architecture decision with direct consequences for AI adoption, upgrade cost, and how fast you can integrate an acquisition.

Why 2026 Is Different

For the first several years of S/4HANA, clean core was aspirational guidance, something an architect mentioned on a slide and rarely enforced with real consequences. In 2026, three forces have turned it into a business-critical prerequisite rather than a best practice.

  • AI needs a standardized core to reason over: SAP’s Joule agents and embedded AI capabilities, the ones covered in last week’s article, need a predictable, standardized data model and process flow to function reliably. Heavy customization breaks the context an AI agent needs to interpret what’s actually happening in your system. An agent trained against standard SAP logic cannot reliably reason over a decade of undocumented Z-program modifications.
  • Cloud release cadence punishes a dirty core: SAP S/4HANA Cloud now ships quarterly updates. In a clean-core landscape, those updates get absorbed with minimal disruption. In a heavily modified one, each quarterly release triggers an expensive re-testing cycle, because nobody can be fully sure which custom object interacts with which standard change.
  • Total cost of ownership compounds: custom code embedded in the core doesn’t cost you once, it costs you every year after. Every new consultant has to learn it, every upgrade has to account for it, every integration has to work around it. The debt doesn’t stay flat; it compounds.

The market has already priced this in. Industry accounts of SAP’s own adoption figures put BTP usage at roughly 50% of SAP customers actively using BTP services in 2026, up about 10 percentage points from the prior year, with another 26% beginning their BTP journey. Put differently: three out of four SAP customers are now either on the BTP extensibility path or actively moving there. Side-by-side extensibility on BTP has become, in practical terms, the default answer to “where does this custom logic go,” not an alternative to weigh against the old way of working.

What Clean Core Actually Requires

Strip away the marketing and clean core comes down to four concrete rules, all of them enforceable and all of them checkable against a real system today.

  • No modifications to SAP-delivered objects: the foundational rule. You don’t modify SAP-delivered tables, programs, or function modules using the old enhancement techniques that create hard upgrade dependencies. Instead, you use SAP’s official extensibility framework: Business Add-Ins (BAdIs), released APIs, and key user extensibility inside Fiori.
  • Extensions live on BTP, not inside the core: custom logic that genuinely can’t be handled through standard extensibility gets built on BTP, using the Cloud Application Programming model (CAP), SAP Build, or SAP Integration Suite. These extensions are decoupled from the core: they survive upgrades independently and can be developed, tested, and deployed without touching production S/4HANA.
  • Integrations go through APIs, never direct database access: every third-party integration, CRM, WMS, MES, e-commerce, uses a published SAP API: an OData service or an event via SAP Integration Suite. Direct database calls or RFC-based shortcuts that bypass the API layer create hidden coupling that silently breaks the moment a schema changes.
  • Data governance is part of clean core, not separate from it: duplicate vendor records, inconsistent material classifications, legacy cost-center hierarchies: these are the data equivalent of a dirty core. They limit process automation just as much as bad custom code does, and they degrade the quality of every AI model built on top of them. This is exactly the data problem last week’s article described as the number-one obstacle to AI impact — it isn’t a coincidence that both articles land on the same root cause.

The Extensibility Map: Where Does Logic Actually Go

Once the four rules are accepted, the practical question becomes: for any given piece of custom logic, which layer does it belong in? SAP, and the partner ecosystem that implements it, generally organizes the answer into three tiers.

  • Tier 1 — In-app extensibility (ABAP Cloud): for low-stack logic tightly coupled to the core: field extensibility, simple validations, small UI adjustments. This runs inside S/4HANA itself, but only through ABAP Cloud, SAP’s newer development model that restricts developers to released APIs by design. ABAP Cloud is now SAP’s standard for all new custom development, which is itself a signal of how central this has become.
  • Tier 2 — Side-by-side extensibility (SAP BTP): for complex logic, external integrations, and anything that needs to evolve, scale, or fail independently of the core. This is where most net-new custom development should land: built with CAP for pro-code teams, or SAP Build for low-code and citizen developers, running on Cloud Foundry or Kyma.
  • Tier 3 — UI-only extensibility (SAP Build): for custom dashboards, Fiori extensions, and front-end experiences that don’t touch core business logic at all. Increasingly handled by business users directly rather than a development team.

The decision rule is simpler than the taxonomy makes it sound: if the logic is tightly coupled to a standard SAP object and small in scope, it stays in-app, through ABAP Cloud. If it’s complex, needs to integrate with non-SAP systems, or should be able to evolve on its own release cycle, it goes side-by-side, on BTP. Getting this sequencing wrong in either direction, over-using in-app extensibility for complex logic, or building simple field extensions as full BTP applications, is one of the most common and most avoidable causes of a clean core initiative losing momentum.

Governance: The Risk Nobody Warns You About

There’s a version of this story where an organization hears “move everything to BTP” and treats it as a license for every department to spin up its own extension, independently, without a shared standard. That version doesn’t produce a clean core. It produces a different kind of mess: a sprawl of disconnected BTP services, duplicated components, and ballooning cloud consumption costs — technical debt with a different address, not technical debt eliminated.

The standard mitigation, and the one worth putting in place before the first side-by-side extension goes into production, is a Cloud Center of Excellence (CCOE): a small, cross-functional group that sets the standards for which runtimes are approved, how identity and security are handled across extensions, how BTP consumption is monitored against budget, and which components get built once and reused rather than rebuilt per project. Without a CCOE, side-by-side extensibility doesn’t prevent technical debt. It just relocates it to a platform your existing ABAP governance processes were never designed to monitor.

This is also where the connection back to AI governance, covered in detail last week, becomes direct rather than abstract. SAP’s own answer to this problem at the platform level is SAP AI Agent Hub, announced at Sapphire 2026 and targeted for general availability in the third quarter of the year, designed to let IT track and audit every agent running across the landscape. A CCOE for BTP extensions and a governance layer for AI agents are, in practice, the same discipline applied to two different kinds of autonomous logic running outside your core: one is code, the other reasons about your data, and both need the same kind of oversight.

What Clean Core Actually Unlocks

It’s easy to frame clean core purely as risk avoidance. The more accurate frame is enablement: clean core is what makes several other things possible that a customized core structurally prevents.

  • Same-day access to new capability: in a clean-core landscape, new S/4HANA Cloud features and AI capabilities become usable close to the day they release. In a heavily modified system, each new capability requires a validation cycle first, commonly cited by SAP partners in the range of three to six months, before it can be trusted in production.
  • AI agents that actually work out of the box: standard agents like the Cash Management Agent, covered in last week’s article, are built and tested against standard SAP process flows. On a clean-core-compliant landscape they work as shipped. On a landscape with non-standard process variants, the same agent typically requires custom development to bridge the gap, which quietly erodes the ROI case that justified deploying the agent in the first place.
  • Lower ongoing cost, though the exact number depends on your baseline: SAP consultancies working across many clean-core implementations report meaningfully lower annual maintenance and application managed services costs for clean-core landscapes versus heavily modified ones, with figures in different accounts landing in the 25–40% range. Treat any single number as directional and specific to that firm’s client base rather than a guarantee, and ask a prospective partner to show their own methodology before you build a business case around it.
  • Faster integration of anything new: acquisitions, new business units, and new regional entities all onboard faster onto a clean-core landscape, because the integration work is additive, new extensions, new API connections, rather than requiring an assessment of what existing customizations might conflict with the new entity’s processes.

What This Means for CIOs

For CIOs, clean core is simultaneously a technical program and a governance program. Five things follow directly:

  • Treat ABAP Cloud as the default, not an exception: for any new development request, the starting assumption should be ABAP Cloud or a BTP side-by-side extension, not classic core modification. Make the case for a core modification the exception that requires sign-off, not the default path of least resistance.
  • Stand up a CCOE before your BTP footprint grows: this is far easier to do with five extensions in production than with fifty. Waiting until sprawl is already a visible problem means retrofitting governance onto systems that were built without it, which is a materially harder exercise than building it in from the start.
  • Run a custom code assessment as a distinct, funded workstream: use SAP’s own Custom Code Migration tooling, or a partner’s equivalent, to inventory every custom object and classify it: retire, remediate to ABAP Cloud, or move to BTP. This produces the evidence base that turns “we should probably clean up our core at some point” into an actual, scoped, budgeted program.
  • Sequence clean core inside the migration, not after it: as last week’s article argued, retrofitting clean core into a system that already went live with fresh customizations is a materially harder and more expensive exercise than building it in from the start. If a migration is still ahead of you, this is the highest-leverage moment to get the sequencing right.
  • Make custom code quality a monitored metric, not a one-time audit: tools like SAP Cloud ALM can continuously flag clean-core violations before they become upgrade blockers. Clean core is a discipline that has to be maintained release over release, not a project with a defined end date.

What This Means for CFOs

For CFOs, the clean core conversation usually arrives disguised as a BTP licensing line item. It’s worth reframing before it reaches the board:

  • This is a TCO decision, not a licensing decision: BTP consumption costs are visible and itemized, which makes them an easy target for cost-cutting. The cost of not doing this, quarterly re-validation cycles, AI agents that need custom rework, slower M&A integration, is real but distributed across many budget lines, which makes it easy to underweight in a single-year comparison. Ask for a multi-year TCO comparison, not a single-year licensing comparison.
  • Fund the custom code assessment even if you fund nothing else this cycle: it’s the cheapest, fastest way to convert an abstract technical debt conversation into a concrete, prioritized backlog with real numbers attached. Most organizations underestimate how much of their custom code base can simply be retired rather than migrated, once someone actually inventories it.
  • Connect this directly to the AI budget conversation from last week: if finance is funding agentic AI pilots without a parallel clean core workstream, that AI budget is at meaningful risk of funding pilots that never scale, for the exact architectural reasons described in that article. These two budget lines should be reviewed together, not separately.
  • Expect the savings to show up as capacity, not as a line-item reduction: consistent with the realistic AI ROI framing from last week, clean core’s financial return mostly shows up as fewer consultant-hours spent on validation and rework, not as an immediate reduction in a specific cost category. Build the business case around that reality rather than a bigger, less credible number.

What “Good” Looks Like: A Simple Maturity Model

As with AI adoption, clean core maturity follows a recognizable pattern across S/4HANA programs, and most organizations can place themselves on it honestly in about five minutes.

  • Stage 1 — Uncontrolled: core modification is still the default path for new development, because it’s the path of least resistance and nobody has said otherwise. There’s no inventory of custom objects, no CCOE, and every quarterly S/4HANA Cloud update is treated as a small project rather than a routine event. This describes a large share of the installed base, including many organizations that migrated to S/4HANA relatively recently.
  • Stage 2 — Aware but unfunded: leadership knows there’s a problem, there may even be a clean core slide in last year’s IT strategy deck, but there’s no dedicated budget, no named owner, and ABAP Cloud gets used inconsistently depending on which developer picks up the ticket. This is the most common stage, and also the easiest to get stuck in indefinitely, because awareness without funding produces no visible change.
  • Stage 3 — Governed and in motion: a custom code assessment has been completed, a CCOE exists and has real authority, ABAP Cloud or BTP side-by-side is the enforced default for new work, and existing technical debt is being worked down against a prioritized backlog rather than an aspirational one. Quarterly upgrades are starting to get faster and cheaper, though not yet routine.
  • Stage 4 — Clean core as the default state: new S/4HANA capabilities and AI agents get activated close to release day because there’s nothing non-standard for them to conflict with. Custom code inventory is a live dashboard, monitored through tools like SAP Cloud ALM, not a one-time report that goes stale within a quarter. This is a small minority of the installed base today, and it compounds: every quarter that passes, the gap between Stage 4 organizations and everyone else gets a little wider, because Stage 4 organizations spend that quarter shipping while everyone else spends it validating.

Most readers of this article are somewhere in Stage 1 or Stage 2. The honest, useful next question isn’t “how do we reach Stage 4,” which is a multi-year answer that invites indefinite postponement. It’s “what does it take to reach Stage 3,” which is a scoped, fundable program with a clear owner and a defined first deliverable: the custom code assessment.

Three Objections Worth Taking Seriously

  • “Isn’t clean core just a way for SAP and its partners to sell more BTP licensing?”: A fair challenge to raise about any vendor-aligned architecture recommendation, this one included. The honest answer: BTP consumption is a real, incremental cost, and any partner recommending it should be able to show a TCO comparison, not just a licensing quote. What makes the underlying argument hold up independent of who’s selling it is the quarterly release cadence: SAP Cloud customers are on a forced upgrade cycle regardless of extensibility choices, and a clean core is what makes that cycle cheap instead of expensive. That part of the argument doesn’t depend on BTP pricing at all.
  • “Our landscape has twenty years of customization. Clean core isn’t realistic for us.”: It’s rarely realistic as a single project with a finish line, and treating it that way is usually what causes these initiatives to stall. It’s realistic as an ongoing discipline applied first to new development, stop adding to the debt, then to the highest-value or highest-risk existing customizations, start reducing the debt where it matters most, rather than an attempt to remediate two decades of ABAP in one program. A custom code assessment, mentioned in the CIO section above, is what turns “unrealistic” into a prioritized, sequenced backlog.
  • “We don’t have the SAP talent to do this properly.”: This is a legitimate constraint, and it’s the same talent gap last week’s article flagged as CFOs’ top near-term challenge, just showing up in a different department. The tooling has moved in your favor faster than most organizations have noticed: SAP partners report that AI-assisted development inside SAP’s Business Application Studio, using Joule, can now generate a substantial share of the boilerplate code for a typical BTP extension from a natural-language description. That changes the skill profile needed on a clean core team from “deep ABAP expert” to “person who understands the business process and can validate what the AI generated.” That’s a meaningfully easier hire.

A Readiness Checklist

Before committing budget to a clean core initiative, or before assuming your current migration plan already covers it, work through these questions:

  • Do you know, with an actual inventory rather than an estimate, how much custom code exists in your core today, and how much of it modifies standard SAP objects directly?
  • Is there an owner, a real name, not a committee, accountable for clean core compliance the way there’s an owner for security or for the financial close?
  • Does new development default to ABAP Cloud or BTP side-by-side, or does it still default to whatever pattern the original developer is most comfortable with?
  • Is there a CCOE, or an equivalent governance body, in place before your BTP extension count starts to grow, not after?
  • If your S/4HANA migration is still ahead of you, is clean core written into the technical design and the data workstream, or is it a slide in the kickoff deck that nobody revisits?

Why This Connects Directly to the 2027 Deadline

Clean core and the SAP ECC mainstream maintenance deadline of December 2027 are not two separate initiatives competing for the same budget. For any organization still migrating, they’re the same program viewed from two angles. As referenced in last week’s article, a meaningful share of enterprise leaders, some accounts put it above 40%, now say they prioritize SAP’s AI-driven innovation roadmap over the maintenance deadline itself as their real reason to move. Clean core is the architectural precondition for that AI roadmap to deliver anything. Treating it as a parallel, lower-priority workstream to the migration misreads why the migration is happening in the first place.

For organizations that already migrated to S/4HANA without a clean core discipline, the position is less comfortable but not unusual: this describes a large share of the installed base. The custom code assessment described above works exactly the same way retroactively as it would inside a live migration; it simply starts from a system that’s already in production rather than a system still being designed. The cost of starting now is real. The cost of waiting another year compounds, in the literal sense described earlier in this article.

The Bottom Line

Clean core sounds like a technical housekeeping exercise, and that framing is exactly why so many organizations underinvest in it. It’s better understood as the architectural precondition for almost everything else in the current SAP roadmap: AI agents that work reliably, upgrade cycles that don’t require a quarterly fire drill, integrations that don’t break on the next schema change, and acquisitions that onboard in months instead of years.

The organizations treating this as a governed, ongoing discipline, not a one-time cleanup project, are the ones who will be able to actually use what SAP ships in 2026 and 2027 without a six-month validation tax on every release. Everyone else will keep paying that tax indefinitely, and calling it the cost of doing business with SAP, when it’s actually the cost of an architecture decision made, or avoided, years ago.

Want an honest read on how clean your own core actually is? We offer a free 30-minute AI and Clean Core readiness conversation, no sales pitch, just where you stand and what the realistic next step looks like. Details at theintelligenthub.com.

Sources

Note: figures on BTP adoption, extensibility tooling, and cost savings come from SAP consultancy and partner blogs (SAVIC, Kellton), not from an independently audited SAP disclosure. Where a figure is specific to one firm’s client base (for example, AMS cost reduction ranges), it’s flagged as directional in the text rather than presented as an industry-wide guarantee.

Related

Evaluating your own SAP transformation program? Explore Advisory →

Have a concrete skills gap on your S/4HANA program? Explore Talent Sourcing →

Want the full picture? Explore the full series →