When IT changes something in SAP and Tax finds out later, there is a fix
A patch is applied. A custom development is adjusted. A version upgrade runs. Any of these changes can alter how SAP calculates, records or transmits a tax obligation. Without a formal tax checkpoint, this is not a communication gap: it is a missing governance process between two teams that optimize for different goals.
A patch, custom development or upgrade in SAP can change how a tax obligation is calculated, recorded or transmitted. What is missing is a formal tax checkpoint between IT and Tax. The SAP Tax Diagnostic maps, in 5 to 8 weeks, where that checkpoint exists and where it is missing, and ranks the highest-risk points first.
Choose your entry point by your role
Four entry points, one per role, going straight to the block that answers your question.
01Tax and accounting
The signature of the symptom and its cost: the tax assessment that arrives before the company notices the mismatch.
Go to section02IT and SAP manager
Why IT change management does not solve this alone, and where the tax checkpoint fits.
Go to section03Management and decisions
Tax and IT optimize for different goals: the root of the problem, the cost of inaction and where to start.
Go to section04Self-assessment
Five questions to check whether this risk already exists in your operation.
Go to sectionDirect links
The symptom has a recognizable signature
Bug-fix patch
A bug-fix patch applied by IT unintentionally changes how a tax rate is calculated.
Performance customization
A custom change made to fix a performance problem alters the processing order of a tax posting.
Version upgrade
A SAP version upgrade resets the default behavior of a field that fed the integration with GUEPARDO Tax.
In none of these three cases is there bad faith. In all three, there is a technical change in the IT log, with no matching record that Tax validated its impact before the change went into production.
The clearest sign that this is your problem: the change has already happened, but nobody can say, with a date and a name, who in Tax assessed its tax impact before go-live.
Tax and IT are not competing. They are optimizing for different goals.
Compliance
Tax needs compliance: the right tax rule, applied the right way, every month, with no exceptions.
Stability and performance
IT needs stability and performance: the system up, responding well, with no technical regression. Both goals are legitimate. Neither one is wrong.
The problem appears when a change that serves the IT goal has a tax side effect that nobody on the compliance side was asked to assess beforehand. This is not a lack of goodwill. It is the lack of a formal point, inside the technical change flow, where Tax must say yes before deployment.
Without that checkpoint, the mismatch between the two teams is not an occasional exception. It is the expected result of two competent teams working without a shared process.
The cost shows up later, when it is already more expensive to fix than it would have been to prevent
When a technical change alters tax behavior without a checkpoint, two consequences keep repeating.
The first is the tax assessment: the tax authority spots the mismatch before the company does, and the defense is harder because there is no record that the change was assessed from a tax point of view.
The second is rework: when the mismatch is found internally, someone has to rebuild what changed, when it changed and what the accumulated effect was, often by reviewing months of postings that are already closed.
Neither cost shows up at the moment of the technical change itself. They show up later, when the window for a simple fix has already closed.
The SAP Tax Diagnostic maps exactly where this checkpoint exists and where it is missing
Mapping
Mapping of the real flow of technical changes in the SAP environment.
Analysis
Analysis of where those changes can have a tax impact.
Prioritization
Prioritization of the highest-risk points by criticality (Critical, High, Medium, Monitor).
The whole process takes 5 to 8 weeks, run by a senior team, and ends with a concrete map of where Tax and IT governance really exists, and where it is only an assumption.
This is not a generic system audit. It is a specific mapping of the friction point between the two teams, with a clear priority on what to solve first.
For the CIO and the SAP Manager: this is not one more dependency, it is a process that reduces your own risk
The most common objection from IT leaders on this topic is direct: "we already have a change management process, wouldn't that solve it?" In most cases it does not, because IT change management was designed to protect system stability and performance. By default, it has no formal checkpoint that asks "does this change alter any tax behavior, and has Tax already validated it?"
Co-owner, not just executor
The Technical Buyer stops being only the person who carries out the technical change and becomes co-owner of the process design that keeps the problem from coming back, based on real technical knowledge (setup, integration with GUEPARDO Tax, architecture Clean Core) that only the people who run the system have.
Reduces your own risk, does not create a new dependency
This does not create a new third-party dependency. It creates a documented process that lowers the risk of the CIO being held responsible, after the fact, for a technical change whose tax effect was never assessed.
Five questions to check whether this risk already exists in your operation
01
Formal checkpoint in place?
Is there a formal point in the IT change management process where a technical change must be assessed for tax impact before it goes to production?
02
Is Tax told in advance?
If a change alters a calculation rule, a tax setup or the integration with GUEPARDO Tax, is Tax notified before deployment, or does it only find out at the next tax close?
03
Named owner?
Is there a named owner on the Tax side who must formally approve technical changes with a possible tax impact?
04
Rebuild process?
When a tax mismatch is found after a technical change, is there a documented process to rebuild what changed and since when, or does it depend on manual investigation case by case?
05
Was the last change recorded?
Did the last relevant technical change in the SAP environment (patch, custom development, upgrade) go through this tax checkpoint, with a record?
If the answer to two or more of these questions is "no" or "I don't know", the risk is already present in your operation, even if no tax assessment has happened yet.
Two Specialties directly linked to this problem
SAP Tax Diagnostic
Maps, in 5 to 8 weeks, where the Tax and IT checkpoint exists and where it is missing, and ranks the highest-risk points first.
AMS Fiscal Continuous Governance
This is the continuity model: it sustains ongoing monitoring after the checkpoint is designed, so a new technical change does not reopen the same gap months later.
From the checkpoint that is missing to the process that holds it
The problem, precisely: today there is no formal point in the SAP technical change flow where Tax must validate the tax impact before a change goes to production. A patch, custom development or upgrade follows the IT change management process, which protects stability and performance but has no such checkpoint by default.
The real cost of leaving it as it is: the gap between what Tax defined and what the system actually calculates is only noticed later, at the next tax close or, worse, in an audit, when the defense is harder because there is no record that the change was assessed from a tax point of view. Each month without the checkpoint is one more posting closed under this unassessed risk.
How we solve it, step by step:
- We map the real flow of technical changes in the SAP environment, without assuming that IT change management already covers tax.
- We analyze where those changes can have a tax impact (setup, integration with GUEPARDO Tax).
- We rank the highest-risk points by criticality (Critical, High, Medium, Monitor).
- Together with the CIO or the SAP Manager, we design the formal Tax and IT cross-validation point inside the existing flow.
Service that delivers this: the SAP Tax Diagnostic maps and ranks the risk in 5 to 8 weeks; continuity, so the gap does not reopen months later with the next technical change, is sustained by AMS Fiscal Continuous Governance.
What you receive: a concrete map of where Tax and IT governance really exists and where it is only an assumption, with a clear priority on what to fix first, not a generic system audit report.
First concrete step: a conversation with Tax and with whoever runs the SAP environment, to find out whether the checkpoint formally exists today, and to decide from there whether the SAP Tax Diagnostic is the next step.
Blog articles about Tax and IT with no shared owner
Frequently asked questions about Tax and IT mismatch
01We already have an IT change management process. Wouldn't that solve the problem by itself?+
In most cases, no, because IT change management is designed to protect system stability and performance, not to validate tax impact. A formal tax checkpoint, inside the existing IT flow, is exactly what tends to be missing.
02Is this a communication problem between the teams, or something more structural?+
It is structural. Tax and IT legitimately optimize for different goals (compliance and stability, respectively). Without a formal cross-validation point, the mismatch is the expected result of that difference in goals, not a one-off communication failure.
03How many companies really have this problem?+
The pattern shows up repeatedly in SAP operations with frequent technical changes. The SAP Tax Diagnostic confirms how far the risk extends in your operation.
04Does the CIO or the SAP Manager need to join the first conversation, or is this only a CFO topic?+
They need to join from the start. The Tax and IT checkpoint only works in practice if it is designed together with the people who run the technical environment, not imposed from outside.
05How do I know whether the mismatch is between Tax and IT or between units?+
If the gap is between the rule Tax defines and what IT implements in the same environment, this is the case for this problem. If it is between different CNPJs or units handling the same rule, the topic is Multi-CNPJ tax governance.
06Does this get solved with more meetings between the teams?+
Rarely. Without a formal point in the process where tax impact is validated before a change goes to production, alignment depends on memory and goodwill, and the mismatch comes back.
07Does a tax checkpoint in change management solve it?+
It is exactly the structural mechanism that treats the cause: a formal point where every technical change is assessed for tax impact before it enters production, instead of finding the effect at the next tax close.
08Does the Tax Reform make this mismatch worse?+
It tends to, because the transition to CBS andIBS increases the number of rule changes that must be reflected correctly in the system. Without the tax checkpoint, each change becomes a new chance for a mismatch.
09Who needs to be in the first conversation?+
Besides Tax, it is worth having the CIO or the SAP Manager, because the solution involves the IT change management process, not only the tax rule. This is not a topic for the tax area alone.
10Where do you start when treating the Tax and IT mismatch?+
With the SAP Tax Diagnostic, which maps where the defined rule differs from what is set up and finds where the tax checkpoint is missing in the change flow.
Related content
Multi-CNPJ tax governance
When each CNPJ becomes a different version of the same tax rule.
SAP Tax Diagnostic
Starting point for those who still have no real visibility of their own tax risk.
Map, do not assume
If you recognized this pattern, a structured diagnostic maps exactly where the Tax and IT checkpoint exists, where it is missing, and what to prioritize first.