SAP clean core: what finance customizations you will have to give up

Somewhere in your FI landscape there is a user exit that three people have touched in ten years, and it is about to cost your company more than the standard program it patches. I have walked through these landscapes for a decade, and the pattern repeats: the customization that made you a hero in 2016 becomes the liability your CFO is paying for in 2026. Clean core is the accounting of fifteen years of custom code, and the finance team is the one holding the ledger. Here is what actually survives, what gets replaced, and what should die, with the decision method you need before the migration budget is locked.

What clean core actually means

SAP's own definition is simpler than the conference slides suggest: clean core is a set of guiding principles for continuous transformation. Keep the ERP as close to standard as possible. Push custom modifications to cloud extensions and side-by-side innovations. Audit which customizations are truly necessary. The definition is permissive about custom code; it is strict about where that code lives, because code that lives in the standard core breaks every time SAP ships an update.

That last part is the whole game. S/4HANA runs on a continuous innovation model: feature packs, quarterly updates, new capabilities arriving on a cadence ECC never had. Every modified standard object is a hostage in that model. The upgrade that used to happen every few years, with months of regression testing, now happens constantly, and every modification has to be re-tested, re-certified, and re-defended every single time. The partner who sold you the modification took the implementation fee. The maintenance bill is yours, forever.

The hinge that makes this concrete rather than theoretical is the Compatibility Packs, and the deadline has already passed. When on-premise S/4HANA customers migrated, SAP granted temporary usage rights to keep running classical ECC functions, per business process, through packs that carry their own SAP Notes and their own alternative paths. Those rights expired. SAP moved the date once, from December 31, 2025 to May 31, 2026, called it the final transition period, and did not move it again. Classic FI screens kept alive by those packs, legacy transaction flows around document posting and their neighbours, were supposed to be on Fiori or standard by then. If any of them are still running in your landscape today, you are running them without usage rights, and that is a contract conversation, not a project risk.

Why your FICO landscape is the problem

Finance customizations are not uniformly at risk. They fail in three specific families, and knowing the family tells you the verdict before you open a single program.

The first family is user exits inside rewritten standard programs. The FI document-posting flow was restructured around the universal journal, and the code your exit was attached to no longer exists the way you remember it. An exit that worked because it sat in a specific spot in a specific program does not survive the program being rewritten around it.

The second family is modified standard reports. Same story with a different ending: the report you adapted in 2014 is now a different program with different data sources, and your adaptation is either silently doing nothing or actively fighting the new logic.

The third family is Z tables that duplicate data now living in the universal journal. This is the one finance teams underestimate, because the table still fills, the report still runs, and nobody notices the duplicate until the first reconciliation fails at month-end on the new system.

The mental model that makes all three obvious: ACDOCA is the single source of truth now. Anything that duplicated it, bypassed it, or patched its predecessor is redundant by construction. The architecture makes that decision for you; the migration just makes it visible.

The layers of financial data resting on one foundation — postings, universal journal, and the reporting layers stacked above it

The four buckets

Here is the decision method, the spine of this article and the method I teach finance teams: classify every custom object into four buckets, and let the bucket decide the fate.

One: replace with standard or Fiori. Ask: has SAP shipped this capability in the last five years? For most report modifications and many exit workarounds the answer is yes, and the standard object is now better maintained than your version ever was. A Z report that reads BSEG through a copy of the old data model is not a feature; it is a museum piece with a transaction code.

Two: re-implement at a clean extension point. Ask: does the business process genuinely need this logic, and is there a documented BAdI or an in-app extensibility feature that hosts it? If yes, re-build it there, small, documented, testable. This bucket is where the real design work happens, because it forces you to say what the process must do, not what the program used to do.

Three: move side-by-side to BTP. Ask: is this a genuine differentiation, a process that makes your company money, that no standard object will ever cover? That is the only population that earns the cost and the architecture complexity of a side-by-side extension. Be honest about that cost; it is real, it needs its own operations model, and it has to be budgeted like the project it is.

Four: retire. Ask: does anyone actually use this? The uncomfortable answer, in most FICO landscapes, is that a large share of Z developments are obsolete, superseded by standard, or used by a handful of users. The migration is the one moment you can kill a Z object without a funeral. Nobody defends a custom program during cutover the way they defend it in a normal month. Use that.

You do not have to run this classification by hand. SAP Readiness Check 2.0 and the Custom Code Migration app quantify which custom objects are impacted per Simplification Item, and the central simplification note collects the rules. The tools give you the list. The buckets give you the decision. The finance team gives the list its business meaning, and that is a job no tool can do.

What survives is just as specific: documented BAdIs at supported extension points, Fiori key-user extensibility (custom fields and custom logic on standard apps), in-app extensibility, and side-by-side extensions on SAP BTP, re-platformed with the Custom Code Migration app. Those are the places SAP is telling you to put your differentiation, and they are the places that will keep working.

The verdict per family, so you can scan your inventory against it:

• User exits inside rewritten standard programs: retire, or re-implement at a clean extension point
• Modified standard reports: replace with standard or Fiori
• Z tables duplicating universal journal data: retire
• Documented BAdIs: keep, but audit them and document them properly
• Key-user and in-app extensibility: keep; this is the sanctioned home
• Side-by-side extensions on BTP: keep, and budget the re-platforming

Working with the standard

The mindset shift matters more than the tooling. For fifteen years the default answer to a finance requirement was "modify the standard program". The clean core default is different: configure the standard first, extend at a supported point second, and only then ask whether the requirement is worth its own home on BTP. That ordering changes which conversations happen. Instead of a technical debate about where to insert code, you get a business debate about whether the process is standard or differentiated, which is a much better debate to have.

The practical version of this shows up in the first weeks of the inventory. A typical FICO landscape of a few hundred Z objects sorts itself fast: a large share are obsolete or superseded, a smaller share are genuine process logic, and a handful are the crown jewels that make your company's finance different. The teams that do the inventory honestly end up defending ten objects instead of four hundred. That is the point of the exercise.

Also worth naming: key-user extensibility changed the conversation for good. Custom fields and custom logic on standard Fiori apps mean a requirement that used to force a development can now be delivered by the finance team itself, in the standard app, with the next release. That capability is the reason so many modifications can be retired rather than replaced.

What finance teams get wrong

Three mistakes, and all three are expensive.

The first was assuming the Compatibility Packs would quietly renew. They did not. The usage rights for on-premise customers ended on May 31, 2026, and SAP Early Watch Alert tracks the transition, so the vendor knows your status before your own project office does. The plans that said "we will deal with the packs later" are the plans now explaining themselves to a license auditor. If you are still on compatibility scope, the remediation is no longer a roadmap item; it is remedial work with a clock already behind it.

The second is treating clean core as an IT project. The highest-risk object in most FI landscapes is the document-posting flow, and the decisions about what replaces it are business decisions about how finance wants to post in 2027. IT can inventory the code. Only finance can say what the process must do, and only finance can sign off the replacement.

The third is underestimating the economics. The SAPinsider S/4HANA Migration Benchmark Report 2025, based on 170 organizations, found that 62% cite high project cost as the key migration challenge and 55% cite project duration, up from 37% in 2024. Reducing or eliminating custom code to create a clean, agile core is among the top-cited migration strategies, and clean core setup and analysis tools are expected to be among the most deployed technologies in the next 12 to 24 months. SAP has also moved to requiring certified S/4HANA extensions to be clean core compliant, which turns clean core into an ecosystem and licensing gate as much as a best practice.

A concrete example of what the audit turns up: a Z table built to store document data for a report the standard suite now covers, a nightly job that copies data into it, and a user exit that populates it during posting. Three objects, three families, one underlying requirement that standard now handles. The table retires, the job retires, the exit retires, and the requirement is met by the universal journal and a Fiori app. Multiply that by fifty and you have a migration budget line that just disappeared.

The objections, dealt with fairly

"Clean core is vendor lock-in." There is a real argument here: SAP pushes clean core toward S/4HANA Cloud and BTP, and on-premise customers lose the freedom to modify standard. But the upgrade-cost argument cuts the other way. Modified standard objects break at every feature pack, and the Compatibility Pack expiry settled the question in May 2026 regardless of what anyone believes about SAP's motives. You can argue about intent. You cannot argue with a date that has already passed.

"Some customizations are business-critical." True, for genuine differentiation: industry-specific processes, legal reporting, process logic that makes you money. The answer is not to modify standard objects; it is to re-home that logic into in-app extensibility or side-by-side on BTP. That carries its own cost and complexity, and this article is not pretending otherwise. The alternative, keeping modifications inside rewritten standard code, is deferred breakage dressed as a strategy.

"User exits still work, the panic is overblown." Many enhancement points do survive S/4HANA, and you should not go to war against every exit. The real risk concentrates in three places: modified standard programs, implicit enhancements inside rewritten code, and Z programs and tables that depended on the old data model. Audit those three families hard, and the rest of the inventory will largely take care of itself.

"We can just stay on ECC." Until the end of 2027 with mainstream maintenance. Extended maintenance is premium-priced through 2030, and after 2030 you are on customer-specific maintenance, which is a polite way of saying you pay more and get less. The ecosystem moves on regardless of your calendar: the talent market, the auditors, the AI innovations, all of it lands on S/4HANA first.

The conversation to have this quarter

Run the inventory now, before the migration budget is locked. Not because the migration is tomorrow, but because every decision made during the inventory is a decision the project will not have to make under cutover pressure, and because the inventory itself is the cheapest consulting you will ever buy.

Run it like a finance exercise: named owner per object family, a deadline, and a sign-off. The user exit family goes to the FI lead. The Z tables go to the data team. The modified reports go to whoever actually reads them, which is how you discover that half of them have not been run since 2022.

The conversation you want to have with your CFO ends with a spreadsheet in which the largest column is "retire", a handful of objects in "re-implement", and a small, intentional list in "side-by-side". Then the first feature pack upgrade after go-live passes without a regression, and the finance team's custom surface is small enough that a new consultant can understand it in a week instead of a quarter.

You do not have to defend the code you wrote in 2016. You get to decide what it becomes in 2026. That is the opportunity, and it is sitting in your inventory.

Sources

• What is a clean core? (SAP)
• SAP announced final transition period for Compatibility Packs for SAP S/4HANA on premise (SAP News Center, December 2025)
• SAP S/4HANA Compatibility Pack: What You Need to Know (SAP Community)
• Compatibility Scope: What happens after expiry of use rights? (SAP Community)
• Let's Talk About Clean Core (SAP Community)
• SAP S/4HANA Migration 2025 Benchmark Report (SAPinsider, Holland & Chawla Bhasin, February 2025, n=170)
• SAP S/4HANA Clean Core: Principles, Benefits, and Best Practices (SAP PRESS blog)
• SAP Customisation in S/4HANA: What's Possible, What's Changed, and How to Do It Right (ITChamps)