Clean Core in S/4HANA: where tax tends to break the clean core
Clean Core is SAP's guideline for keeping the S/4HANA core (the current generation of SAP's ERP) standard and stable, and moving differentiation into well-built extensions. In theory, it applies to everything. In practice, the Brazilian tax layer is one of the layers that collects the most exceptions.
How SAP's classification applies to tax, where the risk tends to show up, and how to review the tax layer before a migration or an upgrade.
Clean Core is SAP's guideline for keeping the S/4HANA core standard and moving differentiation into well-built extensions. The Brazilian tax layer is one of the layers that collects the most exceptions. DFSpro reviews the tax layer before a migration or upgrade and does the ABAP development within the Clean Core rules.
Pick your entry point by your role
01Tax and fiscal
Standard or deviation.
Go to the section02IT and SAP architecture
Where the rule should live.
Go to the section03Accounting and audit
Deviation record and proof.
Go to the section04Project management
Upgrade, notes and regression.
Go to the sectionTax is where the local rule meets the global standard
S/4HANA is designed for global processes. Brazilian tax is local, changes often and is full of exceptions by state, product and operation. That meeting creates pressure to extend the core: an adjustment here, a special rule there.
Each adjustment, on its own, looks reasonable. Piled up and undocumented, they become technical debt. According to SAP News, the goal of Clean Core is to keep the core clean, standard and stable through upgrades, while still allowing differentiation where it counts.
In tax, the cost shows up at two moments: at migration, when each rule must be understood before it is moved, and at every upgrade, when a rule can stop working without warning.
The four SAP levels and how they read in tax
The middle column sums up the definition published by SAP. The right column shows how each level usually appears in the tax layer.
| Level | Definition published by SAP | How it reads in tax |
|---|---|---|
| A | Fully compatible extensions, using only public and stable interfaces, either side by side (SAP BTP, the SAP Business Technology Platform) or inside S/4HANA with ABAP Cloud (SAP's programming language, cloud model). | The goal for a new rule. It requires a public interface that supports the scenario. |
| B | Compatible extensions that also use SAP's classic APIs, which are documented and usually stable. | Common in tax integrations. It needs monitoring at every upgrade. |
| C | Extensions that access SAP's internal objects. | It tends to show up in legacy rules that nobody dares to touch. It needs an inventory and an exit plan. |
| D | Extensions that are not recommended: modifications, writing to SAP tables, implicit enhancements. | The biggest source of risk. If any exist, they must be mapped before the migration. |
Source of the definition: SAP News, August 2025, cited above. SAP may revise the model.
Three risk patterns that the review looks for
Patterns that tax project practice shows often, with no claim to be a closed list.
Special rule with no owner
A calculation or exception built to solve one case, with no record of its purpose, and that nobody reviews anymore.
Master data worked around
A master data field that the process does not fill in correctly, plus extra logic that compensates for it instead of fixing the record.
Custom tax interface
An integration with a portal, bank or external system that depends on internal behavior that SAP may change.
None of these items is an error by definition. They become a problem when they are not inventoried and when the decision to keep them was never made explicitly.
Localization standard or deviation: the test that tells them apart
The Clean Core discussion often gets stuck on one word: what is "standard"? For Brazilian tax, we propose a test based on the result, not on the code.
| Situation | Reading | What gets recorded |
|---|---|---|
| The tax result is correct with the localization setup alone | Standard. Configuring is not extending. | The configuration and the date of the last check. |
| The result is correct only with custom code | Deviation. | It goes into the inventory, with level A to D, owner and reason. |
| The standard would cover the rule, but the master record is not filled in | A master data defect, not a deviation. | The fix is in the master record. See tax master data. |
| The standard does not cover the rule today, but coverage is expected | Temporary deviation. | The exit condition, such as an upgrade or a rule change. |
SAP describes Clean Core as the extension kept apart from the application, reaching business objects through defined and stable interfaces (SAP Learning, read on 16/10/2026). What the Brazil localization covers is read in the system, in the installed version. The calculation itself has its own page, the one on tax calculation and Brazil localization, and setup is covered in tax setup.
Where a new rule should live
Before deciding how to build, you decide where the rule lives. The order of preference is the one with the smallest deviation.
In the standard
First stop: does setup solve it? If yes, the rule does not become an extension and the upgrade risk goes away. Move on only when there is a written reason that the standard does not reach the scenario. This is our criterion, not an SAP requirement.
Inside S/4HANA
SAP describes the on-stack extension as inside the ERP, with the ABAP Cloud model and released APIs. In our reading, it makes sense when the rule needs the document data at calculation time and takes part in the same process. SAP Learning calls key user extensibility in-app.
Alongside the core (side-by-side)
SAP describes applications decoupled from the core, running on SAP BTP. In our reading, this fits what talks to outside systems, such as a portal, a bank or a city hall, or what changes often and cannot wait for the core's upgrade cycle.
Official source: SAP News, "How to Extend SAP S/4HANA Cloud the Right Way", of 12/08/2025, read on 16/10/2026, and SAP Learning, read on 16/10/2026. Neither lists the released APIs or says which Brazilian tax scenarios have a released interface: that is read in the system. How to build is covered in ABAP and tax customization, and integration with external systems in tax integration with SAP BTP and API.
Six questions before approving a tax deviation
If an answer is "I don't know", the deviation is not ready to be approved. This is our checklist, not SAP's.
- Does the standard solve it with setup? If it does, the conversation ends here.
- Is there a released interface for the data the rule needs? Without one, the rule tends toward SAP level B, C or D, and the decision must say so.
- What happens at the close if the rule fails? Does it block issuing, distort the tax calculation or just delay a report? The answer sets how strong the proof must be.
- Is there an alternative that does not use an internal SAP object? If there is, the cost and risk comparison goes into the decision.
- Is there an exit date? An upgrade, a rule change or replacement by the standard. A deviation with no exit condition becomes permanent without anyone deciding that.
- How is it proven? Scenario, expected result and actual result, before it goes live.
The answer to each question belongs to the client, and so does the tax position behind the rule. DFSpro builds the checklist, measures the impact and records the decision. The proof of each scenario is covered in tax testing in SAP.
Reviewing the tax layer in four steps
The scope is the tax layer. DFSpro does the ABAP development and customization of the tax layer, within the Clean Core rules. The overall S/4HANA architecture and the rest of the project stay with the integrator and the client's technical team.
Inventory
List the special rules, programs and interfaces that touch the tax layer, with the owner and purpose of each.
Classification
Place each item on levels A to D, with help from the technical team, and flag the ones that depend on an internal object.
Decision
For each item, decide whether to keep it, replace it with the standard or retire it, and record the reason.
Tax test
Check the calculated value in the real scenario of the operation, not just that it runs without error.
What this review is and what it is not
The boundary keeps tax from being confused with a technical code review.
What it is
- A map of tax rules and extensions with a recorded decision.
- A reading of the tax risk of each item, in language for the tax team.
- Input to the migration plan, with what stays and what goes.
What it is not
- A review of ABAP code quality, which belongs to the technical team.
- A definition of the extensibility strategy for S/4HANA as a whole.
- A guarantee of tax compliance: the tax interpretation belongs to the client.
When the result is that the tax layer is already clean, it serves as evidence for the migration project and for the audit.
How long to watch before retiring a rule
A seasonal tax rule looks idle until the day the close calls it. SAP Learning describes how to record the real usage of custom code.
- Two tools. The ABAP Call Monitor (SCMON) and Usage and Procedure Logging (UPL). The page advises against using both at the same time.
- A window of 6 to 18 months. The page says to keep the chosen tool running for that period, including at least one year-end close.
- Aggregation. Transaction SUSG aggregates the data, and the SCMON data is deleted after a short time, according to SAP Learning.
- Criterion. According to the page, usage by end users is the factor that decides what goes.
In tax, the window must cover the whole cycle: the monthly calculation, the quarterly close and the annual tax and accounting filings, such as the ECD and ECF. A rule called once a year does not show up in a survey of a few weeks, and retiring it for that reason is a typical inventory mistake.
Official source: SAP Learning, "Collecting Usage Data for Custom Code", read on 16/10/2026. It is S/4HANA Cloud course material: check whether it applies equally to the client's environment, whether SCMON or UPL is already active and for how long.
Upgrades, SAP Notes and regression: what to reread at every update
Core update
SAP describes level C as the one that accesses SAP's internal objects, and says it plans to offer a changelog of those objects. That is a plan, not a delivery that has been checked. Level D covers modifications, writing to SAP tables and implicit enhancements, and is the highest risk.
SAP Notes
Localization fixes can change the result that a custom rule depends on. In our practice, the list of notes for the tax component is read before every upgrade and cross-checked against the deviation inventory. The calendar of the reform notes is in SAP Notes for the tax reform.
Tax regression
After each upgrade, the inventory scenarios run again and the result is compared with the expected one. Running without error is not enough: the tax value is what counts, and the company's tax team decides which result is valid.
Official source: SAP News, of 12/08/2025, read on 16/10/2026. The text does not describe the content of the SAP Notes or of the changelog; SAP Community points to SAP Note 3578329 for development standards in Clean Core.
The deviation record: what the auditor will ask for
A deviation without a record is a deviation without an owner. The minimum record fits on one line per rule.
| Field | What it holds |
|---|---|
| Identification and where it lives | Name of the rule and the layer: standard, inside S/4HANA or alongside. |
| Tax reason | The client's rule that justifies it, with the tax decision signed by whoever answers for it. |
| Level and date of classification | Level A to D, who classified it and when. The level needs a date, to know under which version of the definition it was classified. |
| Owner of the result and owner of maintenance | Two names, as in the Z extension checklist on this page. |
| Reassessment condition | The upgrade, SAP Note or rule change that forces a review. |
| Last proof | Date, scenario, expected result, actual result and the tax team's decision on any difference. |
The record is reviewed at every upgrade and every rule change that touches the rule. It is what turns the inventory into evidence that can be used in an audit. How this cycle is sustained day to day is covered in AMS Fiscal and governance.
Clean Core, migration and tax reform on the same calendar
The three fronts compete for the same project window.
Suggested order of work
Reviewing the tax layer before migrating usually avoids carrying into S/4HANA a rule that the reform would make useless. The specialty ECC to S/4HANA migration covers the flow, and the CBS and IBS Tax Reform covers the calendar. For the cutover plan, see tax work at the S/4HANA cutover.
What to do with each Z extension at the migration cutover
Before the cutover, know which Z extensions touch tax, invoices or tax filings, who answers for each one, and how to prove they are still correct.
Inventory by real usage
SAP treats removing unused custom code as a step. In DFSpro's assessment, add what the tax team uses and the repository does not show.
Two names per extension
One answers for the tax result, the other for maintenance. In our practice, an inherited extension should get an owner before the cutover.
Regression before the cutover
Write down the expected result and run it in the source system, to have the reference.
Regression after the cutover
Repeat the scenarios in the new system. The company's tax team decides which result is valid.
DFSpro decision checklist by destination
Keep
It passes regression in the new environment, with no code change.
Adapt
Regression compares before and after the adjustment, and the owner signs.
Replace with standard
Regression proves the same result. With GUEPARDO Tax, confirm coverage with NTT DATA in writing.
Retire
It goes before the cutover, with a recorded decision and evidence that nothing depended on it.
DFSpro inventories, measures the impact and proves the regression. The decision belongs to your company.
Official source read on 16/10/2026: SAP Learning, “Analyzing Customizations after System Conversion”.
Official sources read for this page
Blog articles on Clean Core and the tax rule
What is in the service and what stays with the client
What it does
- Builds the decision criteria and the deviation record.
- Inventories and classifies with the client's technical team.
- Configures the standard and builds the compatible extension when it is needed.
- Proves each scenario, before and after every upgrade.
What it does not do
- Decide the tax position behind the rule. That belongs to the client.
- Assign an official SAP level.
- Promise stability in future upgrades or what SAP will deliver.
- Guarantee tax compliance.
Frequently asked questions about Clean Core in tax
01When does it make sense to review Clean Core in the tax layer?+
Before migrating from ECC to S/4HANA, before a large upgrade and whenever there is a special rule that nobody can explain. At those moments each rule must be understood to be moved, and reviewing first avoids carrying an ownerless exception into the new environment.
02How is the service carried out, step by step?+
In four steps: an inventory of the rules, programs and interfaces that touch tax; a classification of each item on SAP levels A to D; a recorded decision to keep, replace with the standard or retire; and a tax test of the calculated value in the real scenario, not just of a run without errors.
03What does DFSpro deliver at the end?+
A map of the tax rules and extensions with the decision on each one recorded, a reading of the tax risk of each item in language for the tax team, and input to the migration plan, with what stays and what goes. If the layer is already clean, the result becomes evidence for the project and for the audit.
04Does DFSpro develop and review tax ABAP, and how does that fit with Clean Core?+
Yes, in the tax layer. DFSpro does the ABAP development and tax customization within the Clean Core rules, preferring a compatible extension over modifying the core. The overall S/4HANA architecture and the code quality of the rest of the project stay with the integrator and the technical team.
05We already have an SAP integrator. Do we still need this?+
The integrator handles the overall architecture and the technical part of the project. The review looks at the tax layer, where Brazil's local rule meets the global standard, and works alongside the integrator, without replacing it. To align who does what, see the working model with your team.
06Do we need to clear all extensions before migrating?+
Not necessarily. The decision is made item by item: keep, replace with the standard or retire, always with the reason recorded. A compatible, documented extension can stay. What cannot happen is migrating without knowing what exists and who answers for each rule.
07How do SAP levels A, B, C and D enter the decision?+
They work as a risk ruler. Level A is the goal for a new rule, B needs monitoring at every upgrade, C needs an inventory and an exit plan, and D, which covers modifications and writing to SAP tables, is the biggest source of risk and must be mapped before the migration. The classification is made with help from your technical team.
08What happens if we migrate without reviewing the tax layer?+
The rule is carried over along with its problem. Each accumulated exception becomes migration work, and a rule that depended on an internal SAP object can stop working at every upgrade, without warning. The cost shows up in the project and, later, in the tax close.
09Does this change with the tax reform?+
Yes. Rules that will be replaced by CBS and IBS, the new consumption taxes created by the tax reform, can be retired instead of migrated, and that reduces what is moved if the decision is made early. The full calendar is in the specialty CBS and IBS Tax Reform.
10Who on our side takes part and what do we need to have ready?+
Whoever answers for tax and whoever supports SAP, with access to the list of programs, special rules and interfaces that touch tax. Nothing needs to be documented: the inventory is the first step. The technical team helps with the classification on levels A to D.
11What is the difference between doing this in-house and hiring DFSpro?+
In-house, the knowledge of the rules is usually scattered, and the team has little time outside the project. DFSpro brings a repeatable tax method and a risk reading for the tax team, and the decision on each item stays with the client. The tax interpretation also belongs to the client.
12How much does it cost and how long does it take?+
It depends on what exists in the environment: the number of special rules, programs and interfaces, the number of CNPJs (Brazilian company tax IDs) and the SAP version. That is why there is no ready price or timeline. The scope is defined in an initial conversation, and the timeline is confirmed at the start of the work.
13How do we start?+
With the SAP Tax Diagnostic, which inventories the rules and extensions that touch tax and shows what to move, replace or retire. You can send the request through the contact page.
14Who decides what to do with each Z extension at the migration cutover?+
Your company decides. What changes is who signs each part: the tax team signs the expected result, IT signs the maintenance, and the process-owning area answers for the risk of going ahead with what was not proven. DFSpro provides the evidence for that signature.
15How do you prove that a Z extension is still correct after the cutover?+
The proof is a side-by-side comparison of the same scenario in both systems. For each extension, keep the scenario, the expected result, the result obtained in both environments and the tax team's decision on any difference. Without that set, the extension is not proven, only tested.
16Does localization configuration count as an extension in Clean Core?+
SAP's levels A to D classify extensions. For the tax review, we treat setup as part of the standard, and it only enters the inventory when it changes the tax result in a way the standard would not do on its own. This is our criterion, not an SAP definition.
17When should the tax rule sit alongside S/4HANA instead of inside it?+
In our reading, when it talks to outside systems, such as a portal, a bank or a city hall, or changes more often than the core. SAP describes side-by-side as decoupled applications running on SAP BTP. The choice case by case depends on whether there is a released interface for the data, which is checked in the system.
18How long must we watch before retiring an extension?+
SAP Learning advises keeping the usage record for 6 to 18 months, including at least one year-end close. In tax, the window must also cover the annual filings. If the environment does not yet record usage, that is the first point to check.
19Does a level A extension guarantee the rule will not break in an upgrade?+
That is not a guarantee we can give. SAP describes level A as an extension that uses only released, stable interfaces, but the tax result still depends on master data and configuration. Regression of the scenarios after every upgrade remains the proof.
Know what exists before you migrate
The SAP Tax Diagnostic inventories the rules and extensions that touch tax and shows what to move, replace or retire.