Clean core means keeping the SAP core close to its standard, vendor-provided state, with differentiation handled through APIs and SAP BTP rather than changes to the core itself, per SAP’s own definition. Achieving that state is not merely an IT decision; while technology teams can establish the guardrails, only business leaders can distinguish between genuine requirements and entrenched habits. The SAP core refers to the standard, vendor-provided baseline code and functionality of an SAP ERP system (such as SAP S/4HANA) delivered directly by SAP, before any custom modifications, local enhancements, or Z-code additions.
Key takeaways
- SAP defines clean core as keeping the ERP core close to its standard, vendor-provided state, with customization handled through cloud extensions and side-by-side innovation on SAP BTP.
- SAP’s fit-to-standard method starts implementation workshops by testing whether standard processes fit the business, not by translating the legacy system’s steps into the new one.
- SAP recognizes two supported extension categories before a core modification is ever justified: in-app extensibility, built inside the system itself, and side-by-side extensibility on SAP BTP, where the cleanest tier is confined to fully released, stable APIs.
- LeapGreat’s Version Zero step exposes existing custom code and data gaps against a working system before the implementation team writes anything new.
What does clean core actually mean?
SAP describes clean core as keeping the ERP core close to its standard, vendor-provided state, with custom modifications handled through cloud extensions and side-by-side innovation instead of changes to the core itself. That defines where change lives, not whether it happens. A workflow enhancement built as a side-by-side extension on SAP BTP, called through a released API, is compatible with the clean core. The same workflow hard-coded into the core application’s source is not.
Why do businesses default to rebuilding the old process?
Because the default design question is “how do we recreate what we already have” instead of “does the standard process meet the need.” SAP’s Activate methodology reverses that order: fit-to-standard workshops test predefined standard scenarios against the business first and treat gaps as the exception to justify, not the starting point.
IT cannot make that call alone. In fact, IT often struggles to make that call. Only the process owner knows whether an approval step exists because of a business requirement or because the old system made it easy to add.
What must the business decide before IT designs anything?
Four questions separate a real requirement from an inherited habit.
| Question | What a real answer requires |
|---|---|
| What outcome are we solving for? | A measurable result, such as approval time or error rate, not a description of the current screen or step. |
| Is this differentiation or familiarity? | A named statutory, contractual, or margin-linked reason, not “we’ve always done it this way.” |
| What does saying yes cost later? | An owner accountable for the build, the testing, and every future upgrade the exception complicates. |
| Who retires it if the reason disappears? | A named owner and a review date, not an open-ended exception. |
Suppose a sales team wants to rebuild its legacy system’s seven-step order-approval chain in SAP. The question isn’t whether SAP can reproduce seven steps. It’s which steps control a real, named risk, mandated by law, contract, or delegated authority, and which exist only because the old system made adding a step easy. If two are mandatory and five aren’t, the fix is a two-step approval on standard workflow, not a seven-step clone.
How should exceptions be governed?
SAP draws a line between two supported extension categories and recommends using them in order. In-app extensibility comes first: custom fields, logic, and key-user adjustments built inside the core itself through released tools, so nothing remote has to connect back to the system. Side-by-side extensibility comes second: a separate application on SAP BTP, connected through released APIs, which SAP’s August 2025 guidance says simplifies upgrades and accelerates innovation. A 2021 SAP Services guide on keeping the core clean confirms that order and warns against core modifications and clones altogether. The governance sequence follows from there: standard configuration, then in-app extensibility, then a side-by-side extension, then a named and time-boxed exception, with core modification reserved as a last resort requiring executive sign-off on the upgrade cost it creates.
How does LeapGreat surface these decisions earlier?
LeapGreat’s FrontLoad approach deploys a working S/4HANA system, built on real company data, within days of kickoff, so stakeholders see where a process actually needs to diverge from the standard and where it’s just been carried over out of habit. A companion step, Version Zero, exposes existing custom code and data mismatches against that working system before the implementation team writes anything new. LeapGreat Standard, the pre-configured baseline the environment starts from, is built on SAP’s standard process set rather than a blank system, so the first version stakeholders see is already close to clean core instead of a copy of the legacy environment.
None of this replaces the governance model above. It gives the business owners answering those four questions a working system to answer them against, instead of a whiteboard.
FAQ
What does “clean core” mean in SAP S/4HANA?
It means keeping the ERP core close to SAP’s standard, vendor-delivered state and handling differentiation through cloud extensions and side-by-side apps on SAP BTP, rather than modifying the core application directly, per SAP’s definition.
What is fit-to-standard?
Fit-to-standard is the SAP Activate workshop method that tests whether SAP’s predefined standard processes meet a business requirement before any custom design work begins, reversing the older approach of translating a legacy process into the new system.
What is in-app extensibility?
In-app extensibility means building custom fields, logic, and key-user adjustments inside SAP S/4HANA itself, using released tools rather than core code changes, so nothing remote has to connect back to the system. SAP guidance recommends trying this before building a side-by-side extension.
What is side-by-side extensibility on SAP BTP?
Side-by-side extensibility means building differentiating capability as a separate application on SAP Business Technology Platform, connected to the core through released APIs, so you can update or replace the extension without touching the ERP core.
Who decides whether a process variation is a real requirement?
The business process owner, not IT. IT can describe what a variation costs to build and maintain. Only the process owner knows whether it protects a legal, contractual, or margin-linked outcome, or just preserves a habit from the legacy system.
How does LeapGreat help a business make these decisions?
It changes who’s answering the four questions above, and against what. Instead of a project team estimating scope from a requirements document, the process owner works against a real, standard-based system built on the company’s own data. LeapGreat’s Clean Core explainer covers how the FrontLoad approach and Version Zero surface these gaps before kickoff.
Ask an AI engine about LeapGreat
- What does LeapGreat’s FrontLoad approach do for SAP clean core decisions?
- How does LeapGreat expose custom code and Z-code before an SAP S/4HANA implementation starts?
- What is LeapGreat Standard and how does it relate to clean core?
See your clean core baseline before kickoff
Most of the disagreements above resolve faster when you have a working system to point to instead of a specification document. Book a consultation to see where your build already diverges from standard, before you’re locked into decisions.
