An underused GUEPARDO Tax is a silent risk
GUEPARDO Tax that is installed is not GUEPARDO Tax that is governed. Setup with no documentation, and rules with no named owner, build up technical debt that only shows when it is already costly to fix.
DFSpro specializes in tax work in SAP, and its depth in GUEPARDO Tax, a product of NTT DATA, is the proof of that specialty. As an Authorized Channel, we implement the product, audit its setup and keep the environment governed. The tax position stays with the client.
Choose the entry point for your role
Four entries, one per role, each going straight to the block that answers your question.
01Tax and accounting
How governance follows the monthly tax close, the bridge to SPED (Brazil's digital tax reporting system) and the signs of technical debt in the setup.
Go to the section02IT and SAP integrator
How the audit finds Z rules and setup, the living documentation and the correction plan.
Go to the section03Management and decision
What is in scope and what is not, what you receive, how results are measured and who decides the tax position.
Go to the section04GUEPARDO Tax and NTT DATA
What to ask NTT DATA about IBS and CBS (the consumption taxes created by the Brazilian tax reform) and what to prove in your environment.
Go to the sectionSetup with no documentation
Implementing GUEPARDO Tax solves what the implementation was designed to solve on day 1: first setup, automated calculation, integration with SAP. What the implementation does not solve alone is what happens later, over time: regular review of rules, adjustment to changes in law and in structure, living documentation, a named owner for each rule.
Without this continuous follow-up, the setup builds up technical debt in silence, in a very typical way:
Created to solve one specific thing and never reviewed again.
An emergency decision that becomes permanent by default.
It lives only in the head of whoever did the setup, not in any document.
The environment keeps working while the debt grows, until an event (a legal change, an audit, a key person leaving) exposes the accumulated cost.
This is not a failure of the product or of NTT DATA. It is the difference between a system that is implemented and a system that is governed, and it applies as much to an environment DFSpro implemented as to one that arrived ready from another channel.
This kind of debt is especially dangerous during a migration from SAP ECC to S/4HANA: an orphan tax rule, with no owner and no documentation, is exactly what gets carried into the new environment without anyone noticing. If your company is migrating or will migrate, auditing the tax layer before go-live keeps the first close after migration from turning into an incident. See how DFSpro handles the tax layer in the migration.
Consequences of inaction
Silent technical debt does not go away on its own: it only gets more expensive with time, above all when the person who understood the original rule has left the company.
Rework at the tax close
Manual checking of rules that should run with no intervention, month after month.
Fear of changing anything
Worry about changing a rule because nobody understands its side effects on the rest of the setup.
Higher audit risk
No documented trail of why each rule exists and who approved it.
Growing cost of correction
The more people leave the company without documenting what they knew, the more it costs to rebuild the original reasoning behind each rule.
What DFSpro does, in practice
"GUEPARDO Tax governance" is not a single label: it is two separate lines of work, done by the same team on the same environment. Implementing the tool when it does not yet exist in the client's environment. And keeping the setup correct once it is in production. The two can be hired together or separately.
In practice, this is concrete activity, not adjectives:
- Identify the tax rules that must exist in SAP before any setup: ICMS, ICMS-ST, DIFAL, and ancillary obligations by CNPJ and by branch.
- Set up GUEPARDO Tax to reflect those rules, always testing in a test environment before any change reaches production.
- Document each rule created, with its purpose and a named owner, so the decision does not stay in the head of one person.
- Review that setup on a regular basis: when the law changes, when the company opens a new CNPJ or branch, or when the operation changes shape.
- Analyze a ticket when something does not match at the close, separating what is a setup adjustment from what is the behavior of the product itself.
None of these activities requires re-implementing anything from zero in an environment that already works. It is continuous work on what already exists, or building what does not yet exist, when DFSpro itself is the one implementing.
GUEPARDO Tax implementation, when the environment does not exist yet
DFSpro implements GUEPARDO Tax. It is not only governance over what is already live: when the client does not have the tool yet, or is switching to GUEPARDO Tax from another tax product, the initial implementation (rule setup, integration with SAP, tests in a test environment, move to production) is work DFSpro does itself.
This is different from saying DFSpro is the only door to buy or install the product. NTT DATA, the sole owner of GUEPARDO Tax, keeps its own implementation channels, and a client can reach the tool by another route. What changes is where DFSpro works: it works at both ends, implementing when called to implement, and governing afterward, with the same team and the same technical standard in both lines.
This implementation experience is not theoretical: there is a technical capacity certificate, signed by a client in the supplementary health sector, that recognizes the support, maintenance and implementation services DFSpro provided on the GUEPARDO Tax tax solution. It is proof of delivery on record from the party that hired us, not a promise from sales material.
After go-live, the boundary changes name but not team: whoever implemented is who keeps governing, so there is no second learning curve at the moment the implementation project ends and the governance contract begins.
Continuous governance: what is reviewed, and how often
Continuous governance is not a single audit repeated from time to time. It is a cycle that runs alongside the client's tax operation, with fixed checkpoints, not an isolated event on the calendar.
A cross-check between what GUEPARDO Tax calculated and what it should have calculated, given the tax scenario of the period.
New rate, new ancillary obligation, change in the tax reform: review of the affected rules before the next close is hit.
Setup of the unit within the standard already documented, instead of copying an old rule with no review.
Requested in a rush for a one-off exception, it goes into the documentation and review queue of the next cycle, so it does not become hidden technical debt.
Each rule has a named owner, on the DFSpro side and, where it applies, on the client side. A rule with no owner is exactly the pattern the consequences section, above, describes as a silent risk.
The monthly close, before closing
The tax close is not a single event on the calendar. It is a sequence of steps that rest on each other, and the source of most close problems is not one isolated step, it is what goes unnoticed between one step and the next.
Master data check
Before processing, a check of CFOP, CST, NCM and the tax registration of each branch. A registration error enters the calculation and only shows up as a difference later, when it is more costly to fix.
Calculation in GUEPARDO Tax
Processing of the contracted obligations (ICMS, ICMS-ST, PIS/COFINS, IRPJ/CSLL, depending on scope), sequenced by volume, branch and period so the environment is not overloaded. How the calculation works for each tax, with the legal basis, is on the page about tax calculation in SAP.
Check of the calculated result
A cross-check between what GUEPARDO Tax calculated and what the rule in force says to calculate, field by field. The tool's result is not accepted on trust, it is compared.
Tax × accounting reconciliation
Reconciliation of the calculated amounts with the accounting ledger, to find differences before generating any file, not after it is transmitted.
After the close: where friction appears
Generation and validation of SPED
Generation of the ancillary obligation files and validation that what was transmitted matches the calculated result, field by field. A difference here often needs more than one round of correction in the same month.
Handling of one-off exceptions
When something does not close under the standard rule, the exception is recorded as a candidate for review in the next governance cycle. It is not a manual adjustment made outside the system, at closing time.
Record of the cycle
What was adjusted and what stayed open that month feeds the documented trail, the same trail used in the next governance audit.
Formal close
Closing of the cycle with end-to-end traceability: every final value explainable, field by field, as to why it is that value.
The point where most time is lost is usually not the calculation itself, it is the difference between what GUEPARDO Tax calculated and what SPED requires, found too late to fix without pressure. A badly sequenced job pushes the close into the night. A side spreadsheet taking over part of the calculation becomes, in practice, the real tax system of the company, without anyone having formally decided that. And IT called in every cycle as an emergency on-call is a symptom that none of these steps is really under governance, only held up by manual effort repeated every month.
Two points of friction often appear in the calculation and check step. The first is a branch that handles the same tax, almost always ICMS-ST, differently from the neighboring branch, because the tax determination setup was never standardized across units. The second is the legitimate tax credit left on the table, calculated in a spreadsheet, with a different criterion per branch and with no reconciliation to the books, which means real money the company fails to recover every month without noticing.
How a governance engagement starts
From first contact to a reviewed setup, the path is always the same, and only the starting point changes: a new implementation, or an environment that already exists.
SAP Tax Diagnostic
First survey of the tax operation and of what already exists in GUEPARDO Tax, or of its absence.
Scope and priority
Definition of what needs implementation, what needs correction, and what is already right, in order of risk.
Execution
Setup, whether implementation or correction, with a test in a test environment before any change in production.
Recurring governance
Entry into the continuous review cycle, within the AMS Fiscal Advisory contract.
Signs of technical debt
A technical checklist to recognize whether the setup of your GUEPARDO Tax environment has built up technical debt:
How the environment is usually supported before governance arrives
No company decides, on purpose, to leave its setup without an owner. The most common pattern is a mix of stopgap solutions that work until they stop working:
Reactive support
Called only when something breaks: it fixes the symptom of that ticket, it does not review the rule that caused the symptom.
Informal "key user"
Holds the knowledge of the setup: it works until that person leaves, goes on vacation, or becomes the bottleneck of every decision.
Consulting on demand
Called in loose hours: it solves the one request, with no continuity or memory from one ticket to the next.
"If it closed, it is fine"
A criterion that does not tell a correct close from a close that only looks correct, because nobody compared the result against the rule in force.
Continuous governance replaces this mix with a single point of responsibility: each rule has an owner, a trail and a scheduled review, instead of depending on someone remembering to review it on their own.
Most common technical risks found in audits
After audits in real environments, some patterns repeat often enough to become a map of where to look first, even before the full survey begins.
What the audit finds most often
- A Z rule created to solve a one-off exception of one client or period, never turned off after the exception stopped existing.
- A tax condition duplicated in more than one access table, with a different result depending on which one is read first.
- Tax determination by CNPJ copied from one branch to another with no adjustment to the real tax regime of that unit.
- A custom field used to store a tax exception, with no documentation of why it exists.
- A calculation that matches in GUEPARDO Tax but differs from the SPED generated, because the manual adjustment happens outside the system, at closing time.
What comes out of a round of governance
- A rule map with a named owner, on the DFSpro side and, where it applies, on the client side. A rule with no owner stops existing as a category.
- Living documentation, updated at every change, not reviewed once every few years, written to be read by whoever arrives later.
- A correction plan prioritized by real risk: what most exposes the close and the defense in an audit goes first in the queue.
None of these patterns is rare. The audit exists to bring this kind of finding to light before it shows up as a difference in a real close or in a tax inspection.
Why seniority matters here
A misunderstood Z rule does not show up as an error on screen. It shows up as a slightly wrong value in a tax field, months later, in a close that has already closed. Understanding this kind of signal takes someone who has seen the pattern before, not someone learning the product inside the client's environment.
DFSpro works with consultants who specialize in GUEPARDO Tax, not SAP generalists who also touch the product when another front leaves them spare time. It is the same team behind the technical capacity certificate cited in the proof of method section, further below, with several specialist consultants involved in a single large project.
This has a direct effect on the speed of diagnosis: a symptom that takes a generalist team extensive investigation can usually be recognized in minutes, not days, by people who have seen the same pattern in another environment.
Why the reading does not stop at the system
Douglas Oliveira, Executive Director and founder of DFSpro, has a background in Accounting and learned GUEPARDO Tax working as a consultant at FH Consultoria Empresarial, the creator of the product and today part of NTT DATA Business Solutions, before founding DFSpro. This double origin, accounting and product, is the practical reason the governance DFSpro provides does not stop at the behavior of the system.
When a tax value comes out wrong, the question is not only "what did the Z rule do". It is also "what did the tax law require to be done". Separating the two is what decides, in a ticket, whether the fix is a setup change or a case to open with NTT DATA.
What this changes in how the team is allocated: GUEPARDO Tax is the module DFSpro implements and governs today, and the same team takes care of it end to end; there is no priority to negotiate between different products inside the same company, because governance has GUEPARDO Tax as its object.
Governance, Stabilization and Advisory: same family, different contracts
AMS Fiscal is the name of DFSpro's recurring contract, split by the moment of the client's operation, not by company size: AMS Fiscal Continuous Governance for those who already have a stable environment and want to keep the setup correct over time; AMS Fiscal Stabilization for those who have just gone through a go-live or a migration and need closer follow-up right after; and AMS Fiscal Advisory as the umbrella that covers both lines when the client wants them together.
The work behind the Governance line: setup audit, living documentation and continuous review. Those in the moment right after a go-live will find the detail of the Stabilization line on the matching page.
Setup audit and correction plan
Technical audit
A full survey of the Z rules and tax setup in use, mapping origin, purpose and owner (when one exists).
Living documentation
Production of the documentation that should have existed since implementation: what each rule does, why it exists, who is responsible for maintaining it.
Correction plan
Prioritization of the gaps found by real risk, with an executable correction plan before any broad change in the environment.
SPED and ancillary obligations under governance
GUEPARDO Tax calculates the tax, but the company is still the one that answers for the ancillary obligation: the SPED Fiscal file, SPED Contribuições, EFD-Reinf, delivery on time, with no difference between what was calculated and what was transmitted.
Continuous governance includes checking that bridge: whether the tax setup of GUEPARDO Tax is generating the right records for SPED, whether a rule change on one side left the other side out of date, and whether the close can explain, field by field, why each calculated value is that value. The same logic applies before changing the product release: when to decide and what to prove.
It is this cross-check between setup, calculation and delivered ancillary obligation that often exposes the difference between a GUEPARDO Tax that works well on its own and a GUEPARDO Tax that is truly integrated into the real tax operation of the company.
What it is and what it is not
What it is
Implementation of GUEPARDO Tax when it does not yet exist, audit of existing setup, documentation of rules, continuous governance, a correction plan for technical debt.
What it is not
A replacement for NTT DATA as owner and maintainer of the product, or the definition of tax strategy (a decision that stays with the client, with its own legal and tax support; the division of work is in how we divide the work with your team). Nor is it setup or assessment of SAP Joule: that governance of an AI assistant is covered in its own specialty, and is not part of this scope.
direct deliverables of this audit
What you receive
- Complete documentation of the audited setup (rules, purpose, owner).
- Correction plan prioritized by risk.
- Recommendation for continuous governance (periodic review, one owner per rule).
Who this service is not the right answer for
Honesty about scope avoids starting work that will not help. This service is not the right answer for those who have not yet decided whether to use GUEPARDO Tax and are still evaluating tools; that is an earlier step, a product decision, not governance.
It is also not the right answer for a simple tax operation, a single CNPJ, with no history of accumulated Z rules, where the cost of a formal audit is greater than today's real risk. And it does not replace the tax decision itself, which always stays with the client, with its own legal and tax team: DFSpro configures and proves the behavior of the system, it does not decide the tax position.
In those cases, the most honest path is usually another: for those deciding between tools, the recommended reading is about the product itself; for a simple operation, lighter follow-up is enough; for a tax decision, the right partner is legal and tax, not system setup.
How to tell whether governance is working
A clear indicator, no secret formula: less manual checking time at the close, month after month, because fewer rules are left in doubt.
| Indicator | What changes |
|---|---|
| Manual adjustments outside GUEPARDO Tax | A drop in the number, close after close. |
| Rule documentation | Updated within the defined deadline, not months after the change in law. |
| Root cause ticket with NTT DATA | Response time measured and communicated, never silent. |
| New rule | None created without a named owner. |
None of these indicators promises to remove tax risk completely, and that promise would not be true: well-governed GUEPARDO Tax reduces risk, it does not bring it to zero.
Proof of method
DFSpro's authority on this subject comes from the method described above and from direct, continuous work on the product, in real SAP environments.
GUEPARDO Tax, maintained by NTT DATA, has a technical standard that can be checked in public. The governance and implementation DFSpro does run on that standard, every day, in a real environment:
- Public registration at INPI, BR512013001325-9.
- ABES certificate.
- Official CBS pilot, by invitation of the Receita Federal (2025).
These credentials belong to NTT DATA, not to DFSpro. They are cited as the standard of the environment DFSpro implements and governs, never as a certification of its own. Full detail in What GUEPARDO Tax is.
The scale of DFSpro's work on the product is measured in volume, not in client names: dozens of active implementation and governance contracts in GUEPARDO Tax, plus hundreds of finished contracts over the team's time on the product.
Where this takes you on the journey
The service matches Stage 4 of the Tax Stabilization Journey (Focal Project). After the implementation or the setup audit and correction plan, the natural next stage is continuous Stabilization, with recurring governance already running.
Governing GUEPARDO Tax connects with the rest of the journey like this:
What GUEPARDO Tax is
The page that explains the NTT DATA product and what it solves inside SAP.
SAP Tax Diagnostic
The survey that maps how the setup is today, before any adjustment.
AMS Fiscal Advisory: continuous governance
The recurring contract that keeps the setup correct over time.
GUEPARDO Tax facing IBS/CBS
The behavior of the system during the transition of the tax reform.
How the project unfolds
Each implementation follows a sequence of phases with deliverables and clear exit criteria, from solution design to go-live and the stabilization period. This phased structure is the same one the SAP market uses and it reduces the risk of rework: each step moves on only after the previous one is validated.
Survey
The tax rule in force and what is already set up in the environment, before any change.
Solution design
Tax rule turned into setup and validated with the client's tax team before it goes into SAP.
Build and test
Always in a test environment, never directly in production.
Go-live
With close follow-up, not a delivery followed by silence.
Stabilization
A period in which the team follows the first real calculation cycle to catch any deviation early.
What to expect after go-live
At the end of the implementation, DFSpro offers a two-month warranty from go-live, covering the correction of programming errors and faults in the technical solution delivered in the project. In implementations with several go-lives, successive waves by CNPJ or by branch, each wave has its own warranty period, counted from the start of production of that stage.
Support is provided during business hours, Monday to Friday, from 9h to 18h, on business days. This warranty period is separate from the continuous governance service described in the sections above: the warranty covers what was delivered in the project, while governance is the recurring work that keeps the setup correct after the warranty ends.
What to ask NTT DATA and what to prove in your environment
What GUEPARDO Tax does or will do for IBS and CBS is information from NTT DATA, owner of the product, and only it can declare it. DFSpro, as an Authorized Channel, implements the product and governs the environment.
Ask through the official channel
Draft the list before the conversation and ask for a written answer: which taxes and documents NTT DATA declares it covers, in which SAP environment and from when, what depends on action by your company and where the official material behind each answer is.
Cite with date and source
Write "NTT DATA declares", with the date and the channel of the answer. An answer given by voice only enters the record after it is confirmed in writing, and a new answer replaces the old one.
Prove it in your environment
What counts is the behavior on your documents. Separate real cases for each regime, write the expected result before running, and keep the evidence of the comparison. Reading the result is the job of the company's tax team, not the consultant.
Record what stayed open
While NTT DATA has not confirmed a point, it stays as an open item, with an owner and a review date. The transition plan moves forward only on what was declared and proved.
In implementation and governance, DFSpro designs and configures the environment, proves the behavior and delivers the record of that proof. For what the law requires, start with these pages.
Tax Reform (CBS/IBS)
The law, the schedule and what changes in each phase.
Reform laws and sources
The official text and where each subject is in LC 214.
Training in GUEPARDO Tax and Tax Reform
For the team that uses the product to understand what to ask and prove.
Official sources read on the Planalto site on 16/10/2026: Constitutional Amendment 132, of 20/12/2023; Complementary Law 214, of 16/01/2025, which creates IBS, CBS and the Selective Tax; Complementary Law 227, of 13/01/2026, on the IBS Management Committee (CGIBS) and the IBS administrative process.
The modules of the GUEPARDO ecosystem: what is in DFSpro's governance
GUEPARDO is not a single product. It is a family of NTT DATA modules on the same tax core, each solving a different part of the tax and financial cycle. DFSpro is an Authorized Channel for GUEPARDO. GUEPARDO Tax is the module it implements and governs today, because that is where the risk that shows in SPED and in audits lives.
The team's experience in this module backs the seniority described in the section "Why seniority matters here". The other products in the family are described, with the NTT DATA source, in the GUEPARDO products and DFSpro's role. To find out which module fits what your operation needs to do, use the tool that points to the GUEPARDO module.
Under continuous governance by DFSpro
- GUEPARDO Tax: calculation of taxes (ICMS, ICMS-ST, IPI, PIS, COFINS, IRPJ, CSLL, ISS and withholdings), generation and validation of SPED and other obligations, tax calendar and audit trail.
- Setup that supports these calculations: CST, NCM, CFOP and tax substitution rules inside GUEPARDO Tax itself, with an owner and a recorded change history.
- Tax x accounting reconciliation and management of PIS, COFINS and ICMS tax credits, when run inside GUEPARDO Tax.
Apart from, when they exist in the client's environment
- GUEPARDO e-Invoicing (see what NTT DATA publishes about the product), Global Trade, Process Automation, Audit, Analytics, and the financial extensions for payment and collection of the Serrala line.
- The company's tax strategy: calculation regime, tax positions, use of incentives. That decision always stays with the client; DFSpro designs, configures and proves the behavior of the system for the rule the client decided to apply.
- Master data quality outside GUEPARDO Tax: product, supplier, NCM and CFOP records badly set up at the source feed errors into the tax engine, but fixing it is usually a master data project, not tax governance.
Where the environment comes from changes the starting point
The starting point of a GUEPARDO Tax governance is not the same for every client. An environment implemented by DFSpro itself arrives with setup documented from day one: each rule is born with an owner, a version and a reason, because that is already the delivery standard of the implementation project.
An environment inherited from another channel, from a previous partner, from a key user who left the company, or kept for years only through reactive tickets, usually arrives without that trail. The initial audit described in the section "How a governance engagement starts" exists to rebuild that history before any correction.
What changes in practice, depending on the origin of the environment:
The initial audit is faster, and mainly serves to confirm that nothing changed outside the formal process since go-live.
The audit usually reveals setup with no recorded reason and duplicated rules, the same symptoms described in the section "Signs of technical debt".
The first job is to survey what exists today, not to compare against a documented baseline.
What is usually missing, and what the client prepares
What is usually missing when the environment already has a history
A rule with no record of who created it, when and to solve what, still running with no confirmation that it applies. Knowledge held by one person who is no longer at the company, or is about to leave. A history of an earlier attempt that did not work: a pack of hours with no commitment to results, a module abandoned after implementation, or an increase in the internal team that created more rework.
What is needed from the client to start
Access to the SAP environment with GUEPARDO Tax: read access for the initial audit and, later, setup access for the team authorized to correct. A named internal owner on the tax or IT side, even if day-to-day operation stays with DFSpro, because governance with no internal counterpart turns into dependence on an outside person. Ticket history and existing documentation, when there is any, even if incomplete: the lack of documentation does not stop the start, it only changes the size of the initial audit.
The transition does not require ending the contract with the previous provider before starting. DFSpro takes over governance from the audit; the pace of ending a previous contract, if there is one, is the client's own decision.
Questions to guide the decision
01Is it worth re-configuring with a third party, or is it a risk to touch what is already live?+
The initial audit is diagnostic, with no change to any rule in production. Any correction proposed afterward goes through a test environment before it goes to the real environment.
02Does the partner that implemented GUEPARDO Tax not already solve this?+
Implementation support usually handles technical tickets and product faults. Continuous governance (periodic rule review, living documentation, a named owner per rule) is a separate and recurring job, not a one-off ticket.
03Does this replace NTT DATA support?+
No. DFSpro's work is on the setup and governance of the client's environment, without replacing the official NTT DATA support.
04What if the problem is in GUEPARDO Tax itself, not in the setup?+
If the analysis of a ticket shows the cause is in the product, not in the setup, DFSpro builds the root cause evidence and opens the ticket directly with NTT DATA. The client does not become a technical go-between for the two companies: whoever talks to NTT DATA is DFSpro, with the diagnosis already done. In these cases, DFSpro's response deadline is paused while waiting for the NTT DATA product team to reply, because the clock cannot run against someone who does not control the code of the tool.
05What is "governance" of GUEPARDO Tax, beyond having it installed?+
It is keeping the setup correct over time: new tax rules, new CNPJs and branches, changes in law. Having the tool installed does not guarantee it keeps reflecting the real operation month after month.
06We already have GUEPARDO, but we feel it is underused. Is that common?+
It is one of the most common patterns. Many operations use a fraction of what the tool offers because the setup stopped in time or was never adjusted with rigor after implementation.
07Does DFSpro implement GUEPARDO from zero or only do governance?+
Both. DFSpro implements GUEPARDO Tax when the environment does not yet exist, and provides continuous governance over what is already in production, whether implemented by DFSpro or by another channel. They are jobs with different methods and timelines, but with the same team and the same technical standard.
08Who should answer for the setup: Tax or IT?+
It is a joint decision: Tax defines the correct rule, IT or setup implements it. Governance exists precisely so that this responsibility does not go without an owner between the two areas.
09How does GUEPARDO governance connect with the Tax Reform?+
The transition to CBS andIBS requires reviewing the tax determination and calculation inside GUEPARDO. Keeping governance up to date is what lets you adapt the product to the new model without emergency rework.
10Do we need to change our GUEPARDO provider to talk to you?+
No. DFSpro works on the environment you already have, without requiring a change of product provider or any change to the existing contract.
11Where does a GUEPARDO governance engagement start?+
With the SAP Tax Diagnostic, which maps how the setup is today, where it differs from the real operation and what to prioritize before any adjustment.
12How do I know whether GUEPARDO Tax is set up correctly?+
The check requires crossing setup, source data in SAP, the tax rules applied, ancillary obligations, calculations and close evidence. The diagnostic identifies where the tool works as a system and where it still depends on a side control.
13Why does GUEPARDO Tax not remove tax risk on its own?+
Because a tool that is implemented is not the same as operational tax governance. Without process, setup review, traceability and recurring validation, inconsistencies can stay off the radar.
14What is the difference between hiring governance and understanding GUEPARDO Tax?+
Governance is the implementation, setup and continuous governance service DFSpro provides on GUEPARDO Tax. The page "What GUEPARDO Tax is" is educational: it explains the NTT DATA product to those who do not know it yet or are evaluating competing software, and it sells nothing.
15Does DFSpro also sell the GUEPARDO Tax license, or only do governance?+
DFSpro sells the GUEPARDO Tax license as an authorized channel of NTT DATA, the sole owner of the product, and also provides implementation and continuous governance services. The lines can be hired together or separately: those who already have GUEPARDO Tax through another channel can hire only governance.
16Does putting an AI assistant in SAP remove the need to review the GUEPARDO Tax setup?+
No. An assistant reads what the environment already has, and an out-of-date tax rule stays out of date, only said more fluently. Our position is governance before automation: reviewing the setup, giving each rule an owner and documenting what is in use comes first. On SAP Joule, see SAP Joule in tax operations.
17What should we ask NTT DATA about GUEPARDO Tax and IBS and CBS?+
Ask in writing, through the official channel, which taxes and documents it declares it covers, in which SAP environment and from when, what depends on action by your company and where the official material is. Keep the answer with its date. What does not come confirmed stays as an open item, and does not turn into an assumption.
18How do we keep NTT DATA's answer to show the auditor later?+
Keep the question, the answer, the date, the channel and the name of who received it in the same record. Cite it as "NTT DATA declares", with the source beside it. If the answer changes, record the new one with its own date and review the transition plan.
Related content
Training in GUEPARDO Tax and Tax Reform
Technical training so the client team can operate on its own.
AMS Fiscal, Continuous Governance
Permanent specialist follow-up after stability has already been proven.
GUEPARDO Tax that is installed is not GUEPARDO Tax governed
DFSpro audits the setup of your environment, implements what is still missing, and delivers a correction plan prioritized by risk.