Is tax in the scope of your RISE or GROW with SAP?
RISE and GROW change the cloud model, the operation and the pace of updates. Brazilian tax law stays the same, and someone must prove that the new system follows it.
The tax decision belongs to your company. Our role is to design, configure and prove the tax behavior in SAP throughout the migration.
Go straight to the part your role needs to read
Four entry points to the same subject: each role sees a different part of tax in RISE and GROW.
01Tax and tax law
What stays with the company and how the Brazil localization appears in each offer.
See the section for this role02IT and architecture
Extension model, clean core and the future of custom tax code.
See the section for this role03Accounting and controlling
The update window and the tax proof for each release.
See the section for this role04Board and committee
The questions for the integrator and for SAP before the scope is closed.
See the section for this roleTax shortcuts in RISE and GROW
What changes in tax when you move to RISE with SAP or GROW with SAP
The cloud model, the way you extend the system and the pace of updates change. The tax obligation does not change, and neither does who answers for it.
What changes
Where the system runs and who operates it. Which extensions are allowed. When each SAP update arrives and how tax prepares for it.
What does not change
The law, the tax position, the classification of each operation, the retention of books and the duty to file obligations on time.
What needs an owner
Each tax rule in the current system, each extension that touches tax and each electronic document: replicate, reconfigure or retire.
This is the tax point of view. The migration work has its own pages: ECC to S/4HANA migration, tax in the S/4HANA cutover e tax clean core.
RISE and GROW start from different points, and tax feels the difference
One is a migration path for companies that already have SAP. The other is an entry point to the public cloud.
| Offer | How SAP describes it | Who SAP recommends it for | What weighs on tax |
|---|---|---|---|
| RISE with SAP | A guided path, with methodology, expert guidance and migration assistants, to take an ERP on your own premises to the cloud. The core can be SAP Cloud ERP or SAP Cloud ERP Private. | SAP customers moving from ECC, from S/4HANA or from SAP ERP in their own environment. | The starting point is an inventory of what already exists: rules, extensions and tax data that need a decision before the change. |
| GROW with SAP | SAP's entry point to the cloud ERP, built on SAP S/4HANA Cloud Public Edition, with pre-configured market practices and standardized implementation with partners in the GROW Fast format. | Companies new to SAP, or growing, that want to start in the cloud. | The standard weighs more. A Brazilian requirement that it does not cover becomes a scope item, with an owner and a defined solution. |
SAP also uses the names SAP Cloud ERP (public cloud, managed by SAP) and SAP Cloud ERP Private (private cloud). Which offer to buy is a decision for the company and its integrator. DFSpro steps in on tax, whichever choice is made, and the work is always the same: inventory, configuration, proof and follow-up.
SAP pages on RISE with SAP, GROW with SAP and SAP Cloud ERP Private. The descriptions above are SAP's, and what each package includes should be confirmed with SAP and with the integrator.
Infrastructure leaves your hands, and the tax proof stays with you
What SAP publishes about how each offer works and what it means for whoever looks after tax.
Cloud managed by SAP
SAP describes SAP Cloud ERP as a cloud ERP managed by SAP, and Cloud ERP Private as a cloud managed by SAP, on a hyperscaler, in a private data center or in a sovereign cloud.
Project tools
GROW Fast uses SAP Central Business Configuration to deploy and maintain the configuration and SAP Cloud ALM to manage the project, according to SAP.
SAP Activate methodology
SAP organizes the implementation in phases: discover, prepare, explore, realize, deploy and run. The fit-to-standard analysis happens in the explore phase.
Migration assistants
In RISE, SAP lists assistants for system analysis, custom code, data, configuration, testing and rollout, with automated localization in the model comparison.
What this changes for tax is the division of work. Infrastructure and part of the software lifecycle pass to SAP. The tax rule, the data and the proof that the result is right stay with the company and whoever implements it.
How much of each task SAP carries out depends on each company's offer and contract. DFSpro does not describe that contract. Tax needs to read the closed scope and ask where it names tax setup and tax testing, including who is responsible for acceptance.
SAP.com: pages on RISE with SAP, GROW, SAP Cloud ERP Private and SAP Activate.
SAP tools speed up the assessment, and tax checks the result
Four of the assistants SAP lists for RISE and what each one asks of tax.
| SAP assistant | What SAP says it does | What tax checks |
|---|---|---|
| System analysis | Builds a baseline of the customer's system, as a clear starting point. | Whether the baseline sees the tax rules the company really uses, and not only the ones that are configured. |
| Custom code | Modernizes custom code to reduce technical debt and allow a clean core. | Whether the code that calculates or adjusts tax was handled with a test of the result, and not only with a syntax fix. |
| Testing | Automates the scope, data and execution of tests. | Whether the automatic scope includes the critical tax scenarios and whether the test data has the edge cases. |
| Rollout | Manages global rollouts, with model comparison and automated localization. | Whether the comparison with the standard model considered the Brazilian requirement of each unit. |
The tool speeds up the assessment, but it does not know the tax position or the rule for each of the company's operations. What it suggests is a candidate for a decision, and the person who decides is still someone in the company.
SAP page on RISE with SAP, section on migration and modernization accelerators.
The tax effort changes with the starting point
The same offer asks for different work, depending on what the company already has.
ECC with a lot of custom code
Older tax setups usually have more exits, Z fields and custom reports. The main work is to inventory, decide and rewrite in the allowed model, with a test of each rule.
S/4HANA already running
The company already lives with the new data model, but may still have extensions at levels C and D. The work is to classify each one and bring the rule to the clean level.
Company new to SAP
With no legacy, tax starts in the standard. The risk changes: what the Brazilian operation requires and the standard does not cover must enter the scope from the start, with an owner and a solution.
Several companies and countries
A standard model has to live with local requirements. The rollout compares the model with each unit, and Brazilian tax must be part of that comparison.
The four situations call for the same method: inventory, recorded decision, setup in the allowed model and proof. What changes is where the effort is and how much of tax already exists to be carried over. To repeat the standard in new units, see tax rollout in SAP.
DFSpro does SAP implementation, including for companies that do not yet have SAP, as well as migration, rollout and tax governance.
What is SAP standard and what stays with the customer and the implementer
Six tax topics, read side by side: what SAP publishes and what the company and the integrator still need to do.
| Tax topic | What SAP publishes | What stays with the customer and the implementer |
|---|---|---|
| Brazil localization | Localization versions with invoice fields, calculation schemas and news by release, documented in the SAP Help Portal. | Confirm, in the closed scope, what the localization covers for your operations and who covers the rest. |
| Electronic documents | In the Public Edition, SAP Document and Reporting Compliance, outbound invoicing option for Brazil, is the only messaging system available. | Enable the integration, register certificates and prove NF-e, CT-e and NFS-e in each establishment and city. |
| Tax calculation | In the Public Edition, Brazilian calculation uses an external engine, through a pricing condition and integration with SAP Integration Suite. | Choose the engine, validate the result against the client's rule and keep checking it at each change in the law. |
| Tax master data | The Business Partner (A2X) now has Brazilian fields, such as CNAE, CRT and the PIS/COFINS regime, according to release 2608. | Define the data owner, clean the base and prove the load before the cutover. |
| Tax extensions | Extension models (key user, developer and side-by-side) and clean core levels from A to D. | Inventory what exists, decide what stays and rewrite in the allowed model, with a test. |
| Position and classification | Does not apply: the interpretation of the law is not part of any system. | Decide. The tax position and classification of each operation belong to the client, without exception. |
SAP Help Portal (SAP Document and Reporting Compliance), SAP Community (releases 2508 and 2608 of the Public Edition) and a blog by a SAP product expert on the external calculation engine.
The Brazil localization changes shape with the offer and the release
What SAP publishes for Brazil in the public and private cloud.
Public Edition (base of GROW)
A blog by a SAP product expert says that, in the Public Edition, Brazilian calculation is done by an external engine, connected through a pricing condition (TXSC) and SAP Integration Suite. The scope item is 43D.
Cloud Private Edition (RISE)
SAP keeps documentation of news in the functional localizations for S/4HANA and for the Cloud Private Edition, with a section for Brazil and items on schemas such as TAXBRA.
Release 2608 of the Public Edition
SAP reports new scope items for several countries, Brazil among them. The list by country is in SAP note 3720572.
Localization as self-service
Since release 2508, SAP describes the Configuration Localization Tool as available and mentions self-service configuration for electronic freight invoices in Brazil.
Each offer, each release and each country changes what is in the standard. So the useful question is not whether the system has a Brazil localization, but which operations, states and documents of your business it covers today.
The comparison between native calculation, an external engine and a mix is in tax calculation and Brazil localization in SAP. The setup of the current model is in tax setup in SAP.
SAP Community posts on localization in the Public Edition (28/08/2025 and 26/08/2026), a product expert blog on the external calculation engine and the documentation of news in the functional localizations in the SAP Help Portal.
In the public cloud, issuing NF-e, CT-e and NFS-e goes through a single channel
What SAP documents about issuing in the Public Edition and what is left for each company to solve.
| Aspect | What SAP documents | What is left for the company |
|---|---|---|
| Messaging channel | The only messaging system available for the Public Edition is SAP Document and Reporting Compliance, outbound invoicing option for Brazil. A third-party system cannot be connected. | Decide what happens to the current issuing solution before the migration. |
| Models covered | NF-e (model 55), CT-e (model 57) and NFS-e for São Paulo and Rio de Janeiro. For other cities, SAP points to Partner Enablement. | Map in which cities the company issues and who covers the ones left out. |
| Enablement | Administrator profile, communication arrangement and a token generated by SAP BTP, valid for 12 hours. | Look after certificates, access and communication arrangements, with a defined owner. |
| Parameters by city | For cities outside São Paulo and Rio de Janeiro, SAP points to Partner Enablement. | Each city hall has its own issuing rules. The table of parameters by city is a DFSpro deliverable. |
Whoever uses another issuing solution today must decide what happens to it before migrating. The exit path from GRC is in GRC NF-e to DRC migration, and incoming invoices in automatic entry of NF-e, CT-e and events.
What tax needs to prove: that each document goes out with the right number, XML and event in each establishment, and that receiving works. More on the subject in electronic tax documents in SAP, NFS-e by city e national standard NFS-e.
SAP Help Portal, documentation of SAP Document and Reporting Compliance, outbound invoicing option for Brazil.
In the cloud, a good part of tax runs through integrations that someone must maintain
Four connection points where tax often finds out late that nobody was the owner.
External calculation engine
In the Public Edition, Brazilian calculation depends on a third-party engine connected through SAP Integration Suite. The integration needs monitoring, and the result needs checking against the client's rule.
Issuing channel
Communication with SAP Document and Reporting Compliance goes through a token generated in SAP BTP and through communication arrangements. An expired certificate or a badly set arrangement stops issuing.
Surrounding systems
Supplier portal, WMS, TMS, e-commerce and bank talk to the ERP through interfaces. Each one must use a released API, and whoever maintains it must be defined.
Logging and tracing
When an invoice is rejected, someone must see where it stopped: in the ERP, in the channel or at the city hall. End-to-end tracing is designed before the cutover, not after the first error.
The design of tax integrations, including in SAP BTP, is in tax integration with SAP BTP, Integration Suite and API.
SAP Help Portal documentation on the issuing channel and a blog by a SAP product expert on calculation by an external engine.
The partner master gains tax fields, and the data owner is still you
Customer, supplier and product carry tax in their name. Wrong master data becomes wrong tax on the invoice.
What SAP added to the partner master
- The Business Partner API (A2X) gained Brazilian tax fields in release 2608 of the Public Edition.
- For customer and supplier: CNAE, company size, CRT number and PIS/COFINS declaration regime.
- Also ICMS taxpayer, main industry type and legal nature.
What is still the company's work
- Name the owner of each tax field in the master data before the load.
- Fix what is wrong at the source, instead of carrying the error into the new system.
- Prove the load with a checked sample and a log of differences.
- Keep the rule on who changes the data after the cutover.
The detail of tax master data is in tax master data in SAP.
SAP Community, localization post for release 2608 of the Public Edition, dated 26/08/2026.
In the cloud, extending the system has rules, and custom tax code falls under them
Three extension models and four cleanliness levels, as SAP describes them.
| Extension model | What it is for | Who usually does it | Relation to the core |
|---|---|---|---|
| Key user (in-app) | Custom fields, simple logic, screen adjustments and reports, with low-code tools. | Business expert or consultant. | Coupled to the core, through published APIs and extension points. |
| Developer (on-stack) | Development in ABAP Cloud, such as custom Fiori apps. | ABAP developer. | Coupled to the core, through published APIs and extension points. |
| Side-by-side (SAP BTP) | Custom applications outside the core, connected through remote APIs. | Developer with Java, Node.js or ABAP. | Loose: the core stays intact. |
For custom code that already exists, SAP classifies extensions in four clean core levels, from A to D. The classification and the cleanup plan are in tax clean core in S/4HANA.
Tax extensions usually live in places that the new model restricts: invoice field adjustments, calculation rules, tax calculation reports. The tax job here is to list each one and say what it does, so the technical team can decide where it will live. The topic in depth is in tax clean core in S/4HANA.
SAP Community, posts by SAP product experts on extensibility in the Public Edition (15/08/2024) and on clean core levels (25/08/2025).
What to ask for each type of tax extension
Inventory before choosing the model: without it, the extension migrates by inertia or disappears without notice.
Custom field on the invoice
Is there a field in the master data or on the invoice that tax uses for a calculation or report? Does it have an owner, and does the new model's field extension support it?
Calculation rule written in code
Does any tax rule live in custom code? Does standard setup or the external engine cover the rule, or does it still call for an extension?
Custom tax calculation report
Who uses the report? Does the audit still ask for it? Which data source will it read from in the new model?
Interface with an external system
City hall, calculation engine, bank or portal: who maintains the interface, and does it use a released API or depend on direct database access?
Form and printing
Does the printed layout of the invoice or the auxiliary document have a legal requirement? Who maintains it in the new model?
Screen and approval flow
Does the tax approval flow depend on a custom screen? Can it become configuration, not code?
Each line ends with one of three decisions: replicate, reconfigure or retire. The company decides, and the record with an owner and a date is what the audit will read later. Development is detailed in ABAP and tax customization in SAP e tax integration with SAP BTP and API.
SAP updates the system on its own calendar, and tax needs to be ready
In the cloud, an update stops being a company project and becomes a routine with a set date.
Public Edition (base of GROW)
Two major updates a year, in February and August, numbered by year and month: release 2608, for example, is from August 2026. Between them, fix packages every two weeks.
Cloud Private Edition (RISE)
A two-year release cycle, with innovations delivered every six months. Each release receives maintenance for seven years, according to SAP.
What SAP describes for the public cloud, point by point
| Point | What SAP describes | What this asks of tax |
|---|---|---|
| Advance notice | SAP notifies the IT contact and publishes an event about six weeks before the major update of the test environment. | A name from tax on the list of people who receive the notice, so the calendar does not depend on IT alone. |
| Regression | The update takes two to four weeks between the test environment and production, so the customer can test before production is updated. | The tax test fits in this window, so the scenarios and the test data must be ready before the notice. |
| Fortnightly fixes | On maintenance weekends, one fix brings only adjustments and the next one also brings new features. | Who follows the tax impact of the new features that arrive without a project. |
| Transports | Import is only possible from release N to N or N+1. An old transport must be recreated. | A tax adjustment made in development must reach production on time, or it will be redone. |
| Availability phase | In the update week, the system is accessible, but there are limits: no transport import and no data migration in production. | A cutover or tax load in the same week as an update requires a plan, not improvisation. |
Each SAP update calls for a tax regression test
Six steps that repeat at each release, with the evidence kept.
- 01
List of tax scenarios
The scenarios the company cannot get wrong: issuing by establishment, return, devolution, incoming invoices, month-end tax calculation and bookkeeping.
- 02
Test data
Real documents, masked when needed, with the edge cases: tax substitution, incentives, exports, complementary invoices.
- 03
Regression right after the update
As soon as the test environment is updated, the scenarios run again, and each difference gets a cause and an owner.
- 04
Document check
Number, XML, event and issuing channel response, for each type of document and each establishment.
- 05
Tax calculation check
Does the month's balance match the one from the previous release? Do books and accounting postings tell the same story?
- 06
Decision to release
Production is only updated after the evidence exists. Whoever answers for tax in the company decides on the release.
The design of scenarios and test data is in tax tests in SAP.
The tax calendar and the SAP calendar must be on the same page
Five events where the two schedules meet.
| Event | On the tax side | On the SAP public cloud side | Question for the plan |
|---|---|---|---|
| Month-end close | Tax calculation and reconciliation for the month depend on complete data. | Fortnightly fixes can land on any weekend. | Does any fix or update fall on close days? |
| Filing obligations | Each obligation has a deadline set by its rule and its own data base. | Major update in February and August, with two to four weeks of regression. | Does the regression window overlap any important deadline? |
| Change in the law | A new rule calls for an adjustment of the rule and of the layout. | SAP states that the platform delivers regulatory updates on its own calendar. | Who checks that the SAP adjustment meets the rule for your operation? |
| Cutover or load | Balances, numbering and open items need checking. | In the update week there are limits on importing transports and migrating data. | Does the tax load coincide with the week of an update? |
| Audit | Asks for evidence for each period. | Each release brings news and changes that SAP lists in the release documentation. | Is the evidence for each release kept with a date and an owner? |
The two schedules, the tax one and SAP's, must be in the same calendar, with one owner. Whoever looks at only one of them finds the other in the middle of a close.
Tax joins in the explore phase, when gaps are still cheap
The SAP Activate phases and what tax needs to have ready for each one.
Discover and prepare
Scope and plan. Tax must be on the list of participants from here on, and not only in the testing phase.
Explore
Fit-to-standard analysis: the pre-configured process is compared with the company's, the gaps appear and the extensions needed are decided.
Realize
Iterations of setup, data and testing. The expected tax behavior must be written down before the test.
Deploy and run
Final tests, cutover and adoption. Afterwards, tax follows the first close and each update.
What tax brings to the fit-to-standard analysis
- The list of operations, states, document types and regimes of each establishment, with approximate volume.
- The scenarios where the company's rule differs from what the standard assumes, with the legal basis for each one.
- The current tax extensions, with an owner and recent use.
- The ancillary obligations of the first period and the dates of each one.
- What the audit asks for as evidence.
When tax only shows up in the testing phase, the gaps have already been decided without it. Each tax gap accepted with no record comes back as a calculation difference.
The migration itself has its own pages, with the full work
Four pages on the site cover taking the environment to S/4HANA.
Tax usually loses at six points, and all of them start in the scope
Project risks that the cloud does not remove, and that tax can anticipate.
Scope without tax by name
The contract speaks of Brazil localization, but does not say who configures, tests and proves tax. What nobody took on becomes a defect at the first close.
Standard gap accepted with no record
An operation that the standard does not cover is accepted in a meeting, with no owner. Months later, nobody remembers why.
Extension migrated without a test
Custom tax code is rewritten for the new model and tested only as a screen. The tax difference shows up in the tax calculation.
Update in the wrong month
The SAP update lands in the week an obligation is due and nobody had a workaround plan for issuing.
City outside the standard channel
The company issues NFS-e in cities that the standard channel does not cover, and the alternative interface did not enter the scope.
Assumed responsibility
Each party thinks the other looks after tax. The result only shows when the first close has a difference.
All six are scope and owner risks. None depends on the SAP product, and all are solved before the cutover, with a recorded decision, a named owner and evidence filed for the audit.
Who decides, who delivers and who proves
The project slips when two parties assume the other one looks after tax.
| Role | What it decides | What it delivers |
|---|---|---|
| Project committee | Whether a cutover or update goes ahead with an open tax item, and who takes the risk. | Project dates that respect the tax dates. |
| The company's tax and tax law team | The position, the classification of operations and which data prevails when there is a difference. | The expected result of each scenario and acceptance of what was proven. |
| Accounting and controlling | What difference the reconciliation tolerates and which opening balances count. | Checked opening balances and the first-period reconciliation. |
| Company IT | Access, environments, certificates and retention of the history. | Test environments and the extension inventory. |
| Integrator or implementer | The technical design of the implementation and the schedule. | Setup, load and extensions in the allowed model. |
| DFSpro | How tax will be proven and when it counts as ready. | Tax inventory, scenarios, regression at each release and follow-up of the first close. |
Three tables and fifteen questions before closing the scope
Each table covers a piece of the risk, and different answers to the same question show where alignment is missing.
To the integrator
- Where does the scope name tax setup and tax testing?
- Who proves NF-e, CT-e and NFS-e in each establishment?
- Which extension model covers each current tax extension?
- How does the plan handle SAP's half-yearly update?
- What support exists for tax after go-live?
To SAP and the cloud partner
- Which Brazil localization scope items apply to my offer and release?
- How do we issue NFS-e in cities outside the standard channel?
- Which calculation engine does my offer accept?
- What is the update calendar for my environment?
- Which notices and maintenance windows do I receive?
To the internal team
- Who represents tax in project decisions?
- Who answers for the tax master data of customers, suppliers and products?
- Which scenarios can tax not get wrong?
- Which obligations are due in the month of the cutover?
- What evidence will the audit ask for?
From the tax inventory to regression at each release
Four fronts that take tax to the new system and keep it proven at each release.
- 01
Tax inventory
Rules, extensions, data and documents of the current system are mapped with your team, and each item gets a recorded decision.
- 02
Design and setup
The expected tax behavior is written down, and setup and extensions are built in the model allowed by the chosen offer.
- 03
Proof
The scenarios the company chose run with evidence, from the document to the payment slip, in the test environment and in production.
- 04
Regression and governance
At each SAP update, the tax test repeats, and tax governance follows the changes in the rules.
DFSpro does not choose the offer, does not interpret the law for the client and does not replace the integrator. The way of working with your team is in how we work with your team.
O SAP Tax Diagnostic serves as a starting point when the scope is still unclear. After the cutover, the routine moves to the AMS Fiscal Continuous Governance.
If your environment runs GUEPARDO Tax (a product of NTT DATA), it goes into the inventory. As an NTT DATA Authorized Channel, DFSpro sells the product license, implements it and answers for its governance.
Where the information on SAP comes from
SAP pages, SAP Help Portal documentation and posts by SAP product experts. DFSpro does not describe SAP contracts or prices.
SAP Help Portal
SAP Community, SAP product experts
What DFSpro proves and what the company decides
Our work ends where the tax decision begins, which always belongs to the client.
We step into the tax side of the move to the cloud: we design, configure and prove. Choosing the offer, defining the project strategy and handling the tax position belong to the company and the integrator.
DFSpro proves
- That the setup and the tax extensions produce the agreed result.
- That each electronic document is issued and received correctly.
- That the tax test repeats at each update, with evidence.
The company decides
- The tax reasoning behind each operation.
- Which offer to buy and with which integrator.
- Whether to go ahead with an open item at the cutover or the update, and who takes that risk.
- What difference is acceptable at the first close.
Frequently asked questions about tax in RISE and GROW with SAP
Understanding RISE and GROW for tax6 questions, 01 to 06
01Does Brazilian tax law change when the company moves to the SAP cloud?+
No. The rule is the one in the law. What changes is the cloud model, the way you extend the system, where the rule is implemented and the pace of updates. Responsibility for the position, the data and the filing of obligations stays with the company.
02Does the Brazil localization come ready in the cloud?+
It depends on the offer, the release and the contracted scope. SAP documents, for example, that in the public cloud issuing NF-e, CT-e and NFS-e uses a single channel, and that calculation uses an external engine. What covers your operations is confirmed in the scope.
03What is the difference between RISE and GROW for tax?+
In RISE, the company already has SAP and the work starts from an inventory of what exists. In GROW, the company enters through the public cloud standard, and what the Brazilian operation requires and the standard does not cover becomes a scope item. In both, tax proof is essential, because the obligation does not depend on the technology choice.
04Does DFSpro serve companies that do not have SAP yet?+
Yes, DFSpro does SAP implementation. It also migrates, does rollout and governance. In a new project, tax design enters from the start, so the gap in the standard is decided early.
05Do I need to redo the tax setup when migrating?+
In general you need to review it. Whoever converts the system carries over the existing setup, which needs a decision rule by rule. Whoever starts from a new standard designs tax in the standard. In both cases, each decision is recorded, with a person responsible.
06Does the tax reform change anything for tax in the cloud?+
The calendar and the rules for CBS and IBS follow the law. In the cloud, what matters is that updates arrive on SAP's calendar, and the tax test must follow them at each release.
Operating in the cloud6 questions, 07 to 12
07Do my current tax extensions keep working?+
Only the ones the allowed model supports. The first step is to inventory each extension and say what it does. The technical team decides whether it becomes configuration, a key user extension, ABAP Cloud or an application in BTP. The company decides whether the rule still exists.
08What changes in the update window?+
In the public cloud, SAP updates the system twice a year and applies fixes every two weeks. The company needs a tax regression plan for each release and a calendar that avoids the month obligations are due.
09Who tests tax after each update?+
The company answers for the test and for acceptance. The tax team defines the scenarios, and the consultancy or the integrator can run them and record the evidence. Production should only be updated after the tax regression is checked.
10Does tax need to worry about the SAP migration assistants?+
It needs to check their result. SAP lists assistants for system analysis, custom code, testing and rollout, and they speed up the assessment. But none of them knows the company's tax position, so what they suggest is a candidate for a decision, and validation is always human, done by someone who knows the operation and the rule.
11Does the public cloud accept any tax calculation engine?+
SAP describes the integration with an external engine through its own mechanism, and a SAP product expert replied, in a SAP Community comment from October 2024, that calculation procedures created by the customer are not valid in the public cloud. The current answer should be confirmed with SAP and with the engine vendor.
12What if an update affects invoice issuing?+
The workaround plan is written beforehand: who decides the pause, how the urgent operation goes on and who releases the return. That is why the regression test happens in the test environment, before production is updated.
Contracting and getting started8 questions, 13 to 20
13I already have an integrator. Do I still need DFSpro?+
It depends on what their scope says. There are scopes where tax is treated only as generic customization. It is worth checking whether tax setup and tax testing are named and who answers for the first close. DFSpro reinforces tax and does not replace the integrator.
14Does DFSpro decide whether to go to RISE or GROW?+
No. Choosing the offer belongs to the company and its integrator. DFSpro shows what changes in tax on each path and proves the system behavior, but the tax decision and the purchase decision belong to the client.
15What should I bring to the first conversation?+
The integrator's scope or proposal, the list of establishments and document types, the inventory of tax extensions, if there is one, and the tax calendar for the cutover period. With that, the conversation covers your scenario, not a generic one.
16Do I need GUEPARDO Tax for this work?+
No. The work serves any SAP environment. Whoever uses GUEPARDO Tax, a product of NTT DATA, has the integration included in the inventory. License, implementation and governance of the product can also be done by DFSpro, an Authorized Channel.
17How is the scope of the tax work defined?+
By the number of establishments, document types, tax extensions and releases that need to be proven. Price and timing are handled in a direct conversation, after the scenario is understood.
18How long before the cutover does tax need to join?+
From the explore phase, when the gaps in the standard are decided. Joining at the testing phase is late: the decisions on scope, extensions and data have already been made without tax, and each one comes back as a calculation difference.
19Does DFSpro continue after the cutover?+
It can continue. The tax regression test at each release and the governance of tax rules continue as routine, through AMS Fiscal Advisory. The company decides whether to hire this continuity or to take on the routine with its own team, according to the capacity and preference of the tax area.
20Can I start with just a diagnostic?+
Yes. The diagnostic shows where tax has no owner and what needs to enter the scope before the decision. It is an independent entry, and the company decides what to do with the result.
Bring the scope of your RISE or GROW and point out what tax does not yet cover
In a direct conversation, we look at the scope, the tax extensions and the cutover dates. Price and timing depend on what is understood there.
To go deeper first: ECC to S/4HANA migration e tax calculation and Brazil localization.