Your project is finished. Its stability is not yet proven.
Just went live? The next few months are your biggest tax risk window. The S/4HANA migration is done, GUEPARDO Tax is configured, the handover report is signed, testing passed, and the project team is wrapping up the contract, or already has. Still, one step is beyond what any implementation project can cover alone: the first real tax close, run on live operations, without the controlled scenarios of a test system.
AMS Fiscal (Stabilization) is specialist support for that first full tax cycle in production after an SAP implementation or migration project. It is SAP tax support for the first 90 days after project handover.
Critical window: before the first real tax close in production
After go-live, the first real tax close in production is the step the implementation project usually does not cover. AMS Fiscal (Stabilization) is specialist support for the first 90 days, with a direct line to a technical manager and the same team from the project, or part of it.
Pick your starting point by your role
Four entry points, one per role, each going straight to the section that answers your question.
01Tax and accounting
What stays open when the project ends, and the first real tax close in production.
Go to section02IT and SAP integrator
Why the integrator's scope ends at acceptance testing, and where stabilization begins.
Go to section03Management and decision
The cost of going without support, and the right next step for your situation.
Go to section04Assisted operation
How the support works, what it covers, and what it leaves out.
Go to sectionDirect links
What really stays open when a technical project ends
A migration or implementation project tests the system against the scenarios planned in its scope. Inside the project, you cannot test every real tax close scenario. Many only appear over a full operating cycle: seasonal tax calculation, a one-off change in a tax rule, an operating exception specific to one plant or CNPJ (the Brazilian company tax ID).
This gap sits between "the system works in testing" and "the system survives the first real close with no emergency fix." That is where regression risk lives. It is not a project failure. Every mission-critical project leaves this step open by design: proving stability under real use, not under a controlled scope.
Without close support in the first tax cycle in production, the most common pattern is this: a setup that passed acceptance testing, but was never run through one specific real scenario, causes an error that shows up only at the next close. Or worse, in a tax audit, with a fine and rework to correct past periods.
Seeing this mechanism is the first step in deciding who will watch this window closely. The project team that did the implementation usually does not stay available for it.
The likely cost of leaving the system without assisted support
Without intensive support in the months after the project, the most common pattern is that the same problem that started the project slowly returns. That includes gaps between tax and accounting figures, manual rework to cover exceptions the setup does not handle yet, and reliance on one person on the internal team to "remember" adjustments that should be documented in the system.
The real risk is not "the system stops." It is the internal team drifting back, without noticing, to the same side spreadsheet the project was meant to remove.
A tax rule applied wrongly in production, with nobody watching the first real cycle closely, can lead to a fine, rework to correct past periods, or an urgent need for someone who is no longer available to explain what was configured.
"Our SAP integrator already covers this." Why usually not
The scope of an implementation project has a start and an end by contract. It ends when the system passes acceptance testing and is handed over. Ongoing tax stabilization in the first months of real operation is a different discipline, with its own nature and timeline, and it is not usually part of an implementation project's delivery scope.
If you need to know how DFSpro works in practice with the SAP partner already in your operation, the full detail is in How we work with your team.
This is not a criticism of the project integrator. It is a difference in the kind of work, not in quality.
Stabilization is not Continuous Governance
Both offers belong to the same base service (AMS Fiscal Advisory), but they answer different moments.
| Offer | Duration | Nature | When to hire |
|---|---|---|---|
| AMS Fiscal Stabilization | Fixed, 90 days | Intensive post-go-live support, with the same project team in transition | Right after a migration to S/4HANA or an implementation or restructuring of GUEPARDO Tax |
| AMS Fiscal Continuous Governance | Recurring, no fixed end date | Advisory: periodic audit, response to regulatory change, setup review at a normal pace | An environment with proven stability that needs only long-term specialist upkeep |
If your system is still in the first months after a project, this service is the right fit. If stability is already proven and you only need routine specialist upkeep, the right service is Continuous Tax Governance.
Signs your operation is still in Stabilization
01
Manual fix at the close
The monthly tax close still depends on a one-off manual fix that was not planned in the original project scope.
02
Reliance on the people who built it
Any change to a tax rule, even a small one, needs a call to whoever did the implementation, because the internal team does not yet fully know the setup.
03
Multiple CNPJs with no full cycle validated
More than one CNPJ or plant runs on the same solution, and no full tax cycle has been validated in all of them yet.
04
Confidence not yet built
The internal team accepts that the system is right "in theory," but does not trust it enough yet to work without a second review.
05
Go-live under 6 months ago
The migration or implementation happened less than 6 months ago, and the first full tax close of the cycle has not been validated without an emergency fix.
06
First close not yet validated
The first full tax close since project handover has not happened yet, or it happened with a manual fix outside the original scope.
07
Operating exception not yet tested
A specific operating exception (one plant, one CNPJ, a rare type of operation) has not yet been tested in the new system under real conditions.
08
Recurring question about the setup
The internal tax team keeps asking the project team questions about the setup, because it has not yet fully absorbed the logic of the new system.
09
Project team already on the way out
The team that ran the project is closing the contract, or already has, and no one is clearly responsible for tax support in this transition period.
Seeing one or more of these signs does not mean the project failed. It means the operation is, as expected, at the step before real stabilization.
Who it is for
Large companies running SAP (ECC or S/4HANA) connected to GUEPARDO Tax, that recently went live or just finished a migration, setup, or regulatory compliance project, and that recognize at least one of the signs above.
What is the right next step for your situation
I already did the go-live and I recognize these signs
The right service is AMS Fiscal (Stabilization), with 90 days of assisted support and a direct line to a technical manager.
See how it works in the section below.
I am not sure how big the real risk is
Or my project has not really started yet. The right starting point is the SAP Tax Diagnostic, which maps and ranks risks before any decision to hire.
How DFSpro works in the post-go-live window
The answer to this window is assisted support for a fixed period, with a direct line to a technical manager and no ticket queue. It starts right after go-live and runs for as long as the first full tax cycle is still being validated in production.
The goal is not to fix what is already wrong. It is to follow the first real cycle closely, spot any needed adjustment before it becomes a habit, and pass documented knowledge to the internal team so it can run the system with growing independence.
How support works in Stabilization
A grace period of 90 days
A fixed period of assisted support, counted from project handover. It is not open-ended support.
Direct line to a technical manager
No tickets, no queue. The same team that ran the project (or part of it) stays available.
Knowledge transfer
Adjustments and gaps found in real use are documented, so the internal team gains more independence.
Scope and deliverables
Scope
Covers
- The transition period between the end of a technical project and the start of routine operation.
- Intensive support and a direct line to the technical manager.
- Fast response to any gap found in the first real close cycle.
Does not cover
- Long-term periodic audit.
- Response to ongoing regulatory change.
- Scheduled setup review at a normal pace.
That is the role of Continuous Tax Governance (see the comparison above), a different service with another timeline and pace.
Deliverables
Stability report
An objective picture of which close scenarios have already been validated under real operation.
Adjustment log
A record of the setup changes made during the period and the reason for each.
Transition plan
A plan to move to Continuous Tax Governance once stability is proven.
What supports this offer
What supports this offer is the method already proven in the other stages of our work.
What we can state with confidence is the working model itself: the same risk diagnosis and ranking used before any project, and the real ability to adapt the solution to each client's case, even when the standard product answer is not the best fit. In one real refund project for ICMS, Brazil's state value-added tax, a client chose a custom-built solution over the ready-made market option, to keep control of the source code and avoid recurring license costs. These case-by-case technical decisions are what support Stabilization, not a general results figure.
Where this fits
Stabilization is the middle phase of the journey:
How assisted operation follows the system
Stabilization is intensive support for a fixed period, right after a go-live. The focus is to contain incidents and stabilize the tax close, with the same project team and a direct line to a technical manager.
Containment
Incidents in the first weeks are handled fast, before they become a routine of manual fixes.
First real close
Support through the first full tax cycle in production, without the controlled scenarios of testing.
Root cause
Each gap is traced back to its source in the setup, instead of being fixed only at the symptom.
Handover
Once stability is proven, the decision on Continuous Governance, which keeps the system free of silent regression.
The duration depends on the tax cycle and the scope agreed with the client, and it is set case by case.
What assisted operation covers and what it leaves out
The boundary keeps stabilization from being confused with long-term upkeep, or with fixing a go-live that was troubled from the start.
What it covers
- The first full tax cycle in production, with dedicated support.
- Review of a ticket when something does not add up, separating setup issues from product behavior.
- Root cause investigation and correction of the setup involved.
- A clear escalation rule for each gap found.
What it does not cover
- Fixing a troubled go-live: the support covers the period after it.
- Long-term upkeep, which is Continuous Governance.
- Setting the company's tax position, which is the client's decision.
- Official product support, which stays with NTT DATA.
Questions to bring to your internal meeting
01My go-live went smoothly. Do I still need this?+
"No incident at go-live" tells you the system went live, not that it has already survived the first real tax close. Most of the risk in this window shows up afterward, when a specific scenario runs in production for the first time. The support exists to cover that gap, not to fix a troubled go-live.
02How long does the Stabilization phase usually last?+
There is no universal calendar deadline. The most reliable sign is not counting months. It is completing at least one full tax cycle (monthly and, where it applies, annual) in production with no emergency fix. That milestone, not a fixed date, marks the move to Continuous Tax Governance.
03Why 90 days, and not an open-ended period?+
Because Stabilization has a fixed period on purpose: it covers the window of the first real tax cycle after the project. Open-ended support is something else (Continuous Governance), with its own pace and contract.
04What is the difference between this and Continuous Governance?+
Intensity. Stabilization has a fixed period and is intensive, for the window right after go-live. Continuous Tax Governance is recurring and runs at a normal pace, for after stability has been proven. One comes before the other.
05What if my go-live was more than 6 months ago and I already closed the first full cycle?+
If the first tax cycle was already validated without an unplanned emergency fix, your operation is probably no longer in this specific critical window. The better fit is then Continuous Tax Governance, at a normal pace, not intensive support.
06Does this replace my current SAP integrator's support?+
No. It is a complementary discipline, specific to the Stabilization period. For the full detail on the relationship with your current SAP partner, see How we work with your team.
07Does the support cover the whole system or only tax?+
Tax only. The focus is the setup and the tax close in the first real cycle, alongside (not in place of) the partner who handles the general technical infrastructure of the system.
08Who exactly will support the system during the 90 days: the same team that ran the project, or a new team with no background?+
A senior DFSpro team does the work, with a direct line to a technical manager and no ticket queue. Keeping context between those who designed and those who stabilize is what avoids explaining the system from scratch, so raise this point directly before you agree to any support.
09What happens if a tax risk is found outside the original project scope during this period?+
Before you hire, find out whether this case is covered by the support or becomes a separate project. The answer changes the real financial risk of the 90 days.
10How is knowledge passed to the internal team throughout the support, and not only at the end?+
Steady transfer, not one handover on the last day, decides whether the internal team really comes out of the 90 days more independent.
11I have several plants or CNPJs. Does that change the support?+
It changes the scope, because each unit needs its own first tax cycle validated under real conditions. The support takes that into account instead of assuming that validating one covers the others.
12What changes in practice (pace, intensity, contact format) when the 90-day period ends?+
It is the move described in the comparison above: from fixed, intensive support to the recurring pace of Continuous Tax Governance, once stability is proven.
13Where do I start if I want this support?+
If you already see these signs, the direct service is AMS Fiscal Stabilization. If you are not clear on how big the risk is, start with the SAP Tax Diagnostic.
Related content
AMS Fiscal, Continuous Governance
Permanent specialist support once stability has already been proven.
SAP Tax Diagnostic
The starting point if you do not yet have a real view of your own tax risk.
ECC → S/4HANA Migration
Tax governance in a version migration, not only the infrastructure.
Talk to whoever will support your system
There is no generic form or ticket queue at the start of this process. The next step is to talk directly with whoever will support the system, understand exactly where your operation stands in stabilization, and match the format of the support to the 90 days that make sense for your case.