Is tax in your cutover plan for S/4HANA?
Tax calculation, tax books and accounting postings do not move on their own. They depend on setup, extensions and master data, and each one must be decided, loaded and proven before go-live.
Migration strategy and tax decisions stay with your company and your integrator. DFSpro steps in to prove, with evidence, that tax works in the new system.
Start with the question your role needs to answer
Four entry points to the same plan: each role sees a different part of tax in the migration.
01Tax and tax law
The readiness questions, the reconciliation of the first period and who accepts the risk.
See the section for this role02Accounting and controlling
What crosses the cutover: balances, payment slips, bookkeeping and the reconciliation between tax and accounting.
See the section for this role03IT and integrator
The phases, the four risks and what the integrated test needs: test data, key users and extensions.
See the section for this role04Executive board and migration committee
Why tax needs its own window and what to ask the team before freezing the scope.
See the section for this roleTax shortcuts in the cutover
Tax enters the cutover as a step, not as a detail
Tax needs its own place in the cutover plan: a window, an owner, test data and a definition of done that the first close can prove.
What goes into the plan
A tax assessment from the start, its own cutover window, test scenarios, an inventory of extensions and checked opening balances.
Who answers
Someone inside the company, with the authority to say that the cutover cannot happen with a tax issue still undecided. The integrator and the consultancy support.
What it proves
The first close after go-live. It shows whether tax calculation, books and accounting postings tell the same story in the new system.
The migration work itself, with the full offer, is in ECC to S/4HANA migration. Here you will find the plan, the risks and the proof on the tax side. What changes in tax when you move to RISE with SAP or GROW with SAP: tax in RISE and GROW with SAP.
The schedule measures infrastructure, and tax only shows up at the close
Six project habits that push tax to the end of the queue.
Treated as just another module
In the plan, tax becomes one line next to purchasing and sales. But it runs through all of them, and one tax issue can stop a whole operation.
The result only shows at the close
A calculation error does not bring the system down. It shows up in the month's figures, when the filing deadline is already running.
Nobody with authority on the committee
Without someone in the company who answers for tax, the issue becomes a footnote in the project status report.
Testing done by IT alone
A technical test confirms that the screen opens and the invoice goes out. Knowing that the tax is right takes someone who knows the rule.
Calendar of works
The cutover date comes from the infrastructure windows. The tax calendar, with closes and filings, comes later, if at all.
An extension nobody sees
Custom code that calculates or adjusts tax is not in the scope, because nobody sees it as part of tax.
Starting early changes where the problem is found. In the assessment, the question costs one meeting. After the cutover, it costs a close with differences.
What tax asks in each phase, from assessment to support
In each phase tax asks different questions, and whoever does not ask them in the right phase asks them at the close.
- 01
Assessment
Which obligations must run in the first period? Which custom developments exist? Who owns each tax master data item? What evidence does the audit expect to see?
- 02
Design
For each tax rule in use, the decision is to replicate, reconfigure or retire it. The decision is recorded, with an owner and a reason. The tax position is the client's.
- 03
Build
Setup, extensions and master data load happen here. The question is whether each item built has its expected tax behavior written down before it is tested.
- 04
Testing
The integrated test needs test data, key users and scenarios that cover the cycle from document to payment slip. A technical test alone does not prove tax.
- 05
Cutover
The tax window has its own steps: what to freeze, what to load and what to check before invoicing is released. It stays away from the middle of a close.
- 06
Go-live
Invoicing resumes under close watch. Is there any issue that prevents issuing or posting? Who decides to release, and with what workaround plan?
- 07
Support
The first close validates the result. The intensive support after it needs an owner and a deadline set before project support ends.
Each phase ends with a document that tax can show
The phase only ends when the record the audit will ask for exists.
| Phase | What tax must have when leaving the phase | Evidence that stays | Who answers in the company |
|---|---|---|---|
| Assessment | List of first-period obligations, inventory of extensions and a map of master data owners. | Assessment document with dates and owners. | Tax and tax law, with IT. |
| Design | A recorded decision for each rule: replicate, reconfigure or retire. | Decision log signed by whoever answers for the rule. | Tax and tax law. |
| Build | Setup and extensions with the expected behavior in writing. | Specification of each item and unit test result. | IT, with tax checking. |
| Testing | Real scenarios covered, defects fixed and the scenario repeated. | Test plan, data used and result of each scenario. | Key users from tax and accounting. |
| Cutover | Opening balances, numbering and open items checked. | Window checklist with time and owner. | Tax, accounting and IT. |
| Go-live | Decision to release invoicing and a workaround plan for open items. | Minutes of the decision and a list of open items with owners. | Whoever answers for the company on the committee. |
| Support | Reconciliation of the first period and support with a deadline and an owner. | Reconciliation report and a log of differences with their cause. | Tax and controlling. |
Data, testing, extensions and scope are the risks that repeat most
In our reading, there are four families of risk. Each one has an opening question and an owner on the company side.
Data
Master data, tax rules and opening balances that arrive wrong at the load. Cleanup belongs to the company and starts before the load.
Testing
No test data and no key users. Without them, the test confirms the happy path and leaves out the tax exceptions.
Extension
Development and reports from the old system that calculate, adjust or book tax and that nobody has inventoried.
Scope
Tax with no name in the integrator's contract, no owner on the committee and no time of its own in the schedule.
Bad tax data shows up at the load, and cleanup belongs to the client
Five families of data that the cutover carries along, and one question for each.
Material master
NCM, origin, taxable unit and other tax attributes. When two records exist for the same item, which one counts, and who decides?
Partner master
CNPJ, registrations, tax regime and address. If the new system changes the master data structure, the tax fields need a defined destination.
Tax determination
The rules that choose the tax treatment by operation, by state and by type of movement. Who confirms that the loaded rule gives the expected result?
Opening balances
Tax calculation balances, credits to recover and assets with credit to take. Were they checked against the old system, line by line?
History and retention
Are invoices, files, books and tax calculations from earlier years still available for tax authorities and audits? In which system?
The client decides which data is valid when two sources disagree. DFSpro shows the difference, designs the load rule the client approved and proves that the load followed it. More on the topic: tax master data in SAP.
The integrated test asks for test data and key users that are available
Five conditions the tax test needs before it counts as proof.
- 01
Real scenarios
A list of the operations the company actually runs, by state and by type of movement, with the expected value written by someone who knows the rule.
- 02
Test data
Data similar to production, without exposing personal data. Without test data, the test covers the happy path and misses the exceptions.
- 03
Key users
Whoever runs and checks the test needs reserved time. A key user who splits the week between testing and daily work delivers an incomplete test.
- 04
Full cycle
From the document to the payment slip and the accounting entry. Stopping at the authorized invoice leaves out the tax calculation and the reconciliation.
- 05
Repetition
Each defect fixed requires repeating the scenario. The plan needs several test cycles for this, not just one.
The proof that the system gets each scenario right, with evidence: tax tests in SAP.
Extensions and reports from the old system usually need review
What was built on the old system does not migrate just because it is old. It migrates because it has an owner and a test.
Inventory
Which programs, reports, extension points and custom tables touch tax, invoices or bookkeeping? The list comes from the people who use them, not only from the repository.
Real use
What nobody has run for years can go. The SAP guide recommends removing code that is no longer used.
Review
Each extension kept needs an owner, expected behavior in writing and a test. The SAP check does not find every case.
Right place
Where the rule fits in the new system: configuration, a market solution or custom development. The decision has an owner, and the tax decision is the client's.
Tax extensions, one by one: ABAP and tax customization in SAP. The clean core approach applied to tax is in clean core in S/4HANA applied to tax.
The scope must say where tax is and who answers for it
Scope risk is about contract and governance, and it is solved before the design.
Tax by name
Does the integrator's scope name tax setup and tax testing, or only the word customization? The answer shows who answers for what.
Written boundary
What stays with the integrator, with the tax team, with the company's IT and with the specialist consultancy. A written boundary, with an owner.
Freeze
A scope frozen without the answers from the assessment is usually reopened later.
Change midway
If the scope changes during the project, who reassesses the tax impact, and how fast does it go back to the committee?
Tax scope is usually clear when each deliverable has a verb and an owner: assess, decide, configure, test, approve. A deliverable with no verb, such as follow tax, leaves room for two readings at the first close.
The SAP technical guide has a tax effect in each step
What SAP writes about the conversion and what each item asks of whoever looks after tax.
| SAP item | What the guide says | What it asks of tax |
|---|---|---|
| Simplification items and consistency check | The catalog describes, by area, what changed compared with the previous ERP, with the preparation steps and the steps after the conversion. The check is mandatory, and the guide recommends running it early. | Bring tax the list of items that touch finance, sales and purchasing, and read each one with someone who knows the process. |
| SAP readiness check | The guide recommends running it before the project, to identify relevant items, do an overall analysis of custom code and check add-on compatibility. | Use the result as a map for the tax assessment, not only as an IT report. |
| Custom code analysis | The check compares custom code against the S/4HANA simplifications. The guide warns that it does not identify every case, asks for the code to be tested in the new system and recommends removing unused code. | Inventory the extensions that touch tax and decide what goes before adapting. |
| Test conversion in a separate system | The guide recommends a second development system, a copy of the original, to run and test every phase of the conversion and to collect the changes in transport requests. | Tax needs access and data in this system to validate the setup before the real cutover. |
| Data transition validation | The tool compares business data before and after the conversion, using reports or transactions as the comparison instrument. | Choose which tax and accounting reports serve as the comparison, with the audit in the conversation. |
| Obsolete data | After the conversion, data from simplified structures can remain in the system. The guide says cleanup comes after testing and validating the result. | Clean up only after the first close is checked. |
| Accounting conversion | For financial accounting, the guide points to a specific SAP conversion note. | Tax consumes this data, and the reconciliation depends on the ledger arriving intact. |
The guide is a general technical roadmap. It does not detail Brazilian bookkeeping or tax obligations, and that work belongs to whoever knows the rule and the environment.
Conversion Guide for SAP S/4HANA 2025, document version 3.0, dated 07/10/2026 (sections 2.2, 2.3, 3.6 to 3.8, 4.6). Read on 16/10/2026.
Six types of rule, one question for each decision
Every item in the assessment gets a recorded decision: replicate, reconfigure or retire. Without it, the item migrates by inertia.
Tax determination
Is the expected result the same in the new system? Who confirms it, and with what evidence?
Tax master data
Does the field keep its meaning and its owner? If the master data structure changes, where does it go?
Calculation extension
Is it still used? Does standard setup cover the rule, or does it still need code, with an owner and a test?
Custom tax report
Does the audit or the tax authority still ask for this report? Which source will it read from?
Interface with an external system
Who maintains it will support it in the new system? Does the format or the connection point change?
Automatic accounting entry
Are the account and the criterion still valid for accounting?
The decision for each line is recorded with an owner and a date. The tax decision behind the rule is the client's, and the record is what the audit reads later.
The tax events that the cutover window must respect
The IT schedule fixes a date. The tax calendar says whether that date fits.
Standard maintenance
The SAP announcement of 4 February 2020 sets standard maintenance for the core applications of SAP Business Suite 7 until the end of 2027.
Extended maintenance
The same announcement provides optional extended maintenance, from 2028 to the end of 2030.
No decision by the end of 2027
Whoever stays on the current system without choosing extended maintenance moves to the customer-specific maintenance model, which fixes already known problems, according to the announcement.
For S/4HANA, the announcement speaks of maintenance until the end of 2040. When to migrate is the company's decision, and the current conditions should be confirmed with SAP.
The tax calendar that the cutover date must respect
| Tax calendar event | Why it matters for the cutover | Question for the plan |
|---|---|---|
| Month-end close | Tax calculation, payment slips and reconciliation depend on the month closing with complete data. | Does the cutover fall before or after the close, and who closes what in each system? |
| Bookkeeping and obligations of the period | Each obligation covers one period and one data base. If the base changes midway, the file mixes two sources. | Which system produces the file for the period in which the cutover happens? |
| Payment slips and due dates | The due date does not wait for the cutover. | Is there a scheduled payment that crosses the window, and who releases it? |
| Electronic documents in transit | Authorized invoices, events and numbering remain valid in the new system. | Who carries the numbering sequence of each establishment and series to the new system? |
| Tax calculation balances | The balance of the previous period feeds the next one. | Was the opening balance checked against the calculation in the old system? |
| Year-end close and annual bookkeeping | A cutover in the middle of the fiscal year creates a year with two systems. | Who consolidates the two in the annual file? |
Keeping books and documents stays with the company, in any system (Decree 6.022/2007, art. 2, § 2). In the migration, the history of the old system must stay accessible to the tax authorities and to auditors.
The date of each obligation comes from its own rule, and the plan uses the calendar in force in the year of the cutover. The ancillary obligations page groups the obligations by frequency.
SAP announcement of 04/02/2020; Decree 6.022/2007, arts. 1 and 2. Read on 16/10/2026.
Numbering, authorization and events cross the cutover
The electronic invoice is not born again in the new system. Numbering and events follow the history that the old system started.
Sequence by establishment and series
Each establishment and each series has its own sequence (SINIEF Adjustment 7/05, clause 3, II). The new system continues where the old one stopped.
Repeated number
A duplicate number is a reason for rejection (clause 7, I, d). Two systems issuing in the same series, even for a few hours, open the way to this error.
Broken sequence
An unused number requires a request to void it by the tenth day of the following month (clause 14). The cutover can leave gaps, and the plan says who files the request.
Cancellation with a short deadline
A cancellation request is allowed within twenty-four hours of authorization, if the goods did not move (clause 12, wording read on 16/10/2026). Each state may accept a late request in an exceptional case.
Invoice in transit
An event requested after the cutover, for an invoice issued before it, must be able to find the invoice. Who keeps the access key and the file of each document?
The detail of each electronic document is in electronic tax documents in SAP. The rule for each type of document is different, and the cutover plan handles one type at a time.
SINIEF Adjustment 7/05, clauses 3, 7, 12 and 14. Read on 16/10/2026, in the wording published by Confaz on that date.
Eight patterns that leave the difference for the first close
None of them brings the system down. All of them show up in the month's figures.
Cutover in the middle of the close
The window falls on the worst day of the month. The first file after the migration mixes two systems, and nobody set aside time to check it.
Numbering that restarts
The new system starts from number one in a series that already existed. The duplicate rejection shows up on the first invoice.
Opening balance with no check
The balance was loaded and nobody compared it with the previous calculation. The difference appears at the close.
Testing only the happy path
The ordinary sale passes. Returns, transfers and operations with withholding are left out.
Forgotten extension
The report that tax opens every month depends on a program that nobody inventoried.
Key user with no time
The test depends on someone who also runs the daily work. It stays incomplete, and nobody records what was left out.
Open item released with no record
The cutover goes ahead with an open item, and the decision to go ahead is neither written down nor signed by a name.
Support with no owner
The integrator leaves, project support ends, and the first tax question has nobody to go to.
These are patterns that tend to appear in migration projects. Use the list for the conversation with the integrator.
Six questions about the first file from the new system
The first-period obligation is the first public test of the new system.
| Question | Why it matters |
|---|---|
| What is due? | Each company has its own set of obligations, by frequency and by establishment. The list comes from the company's tax team. |
| Where does the data come from? | An obligation with no defined source, in the old system and in the new one, is an obligation at risk. |
| Which system produces the file? | In the cutover period, the file mixes two sources, and someone must answer for it. |
| Does the file come out in testing? | Generating the file with the test data shows, before the cutover, the field that the new system does not fill. |
| Does the content match? | Passing the file validation does not prove that the content matches the tax calculation and the accounting. |
| Is the deadline in the calendar? | The date of each filing must be in the cutover schedule, with an owner and room for correction. |
The list of obligations belongs to the company, and the deadline for each one is in its own rule. DFSpro helps organize the proof that the first-period file comes out of the new system with the right content. The obligations by frequency are in SPED ancillary obligations in SAP.
Four questions decide whether tax is ready for the cutover
Each question asks for evidence, not an opinion.
Are there real scenarios with evidence?
- Do the scenarios cover the operations the company really runs?
- Does each scenario have an expected value written before the test?
- Does the evidence show the system result, and not only the word passed?
- Were the defects fixed and the scenario repeated?
- Who from tax signed the result?
Is there an open item that prevents issuing or posting?
- Is there a list of open items with an owner and a decision?
- Does any invoice depend on a manual adjustment to go out?
- Do the automatic accounting entries match the tax calculation?
- Who decided to release the cutover with an open item?
- Is the workaround plan written down?
Were the first-period obligations validated?
- Which obligations are due right after the cutover?
- Were the files for the period generated in the test environment?
- Does the file that mixes two systems have an owner?
- Was the content checked, beyond the file validation?
- Are the deadlines in the project calendar?
Was the tax and accounting reconciliation of the first period done?
- Does the same reconciliation report run in both systems?
- Were the opening balances checked?
- Does each difference have a cause and an owner?
- Who accepts the difference that remains?
- Was the result kept for the audit?
The questions work as a conversation guide. The company decides when tax is ready. On reconciliation: tax and accounting reconciliation in SAP.
The first close is the validation
The tax result only shows when the month closes. That is why the first close after go-live is the final proof of tax in the migration.
When
At the first complete close after go-live, with the volume, the deadline and the pressure of a real period.
What is compared
Tax calculation, books, payment slips and accounting postings, against the expected result that tax wrote down before the cutover.
What is kept
The reconciliation report, the differences with cause and owner and the decision of whoever accepted each one.
Preparing this proof is the definition of done for the cutover. The scenarios, the evidence and the repetition at each close are in tax tests in SAP.
Twenty-one questions, at three tables, before freezing the scope
Each table answers one part of the risk. The same question put to two tables usually gets two answers.
To your integrator
- Where does the scope name tax, and with which deliverables?
- Does the test conversion have data and access for tax to validate?
- Which extensions that touch tax are in the custom code inventory?
- Which relevant simplification items touch finance, sales or purchasing?
- Does the integrated test plan go all the way to the payment slip?
- How does the plan handle invoice numbering at the cutover?
- What support exists after go-live, and for how long?
To your tax and accounting team
- Which obligations are due in the first period?
- Who owns each tax master data item?
- Who can write the expected result of each scenario?
- Which key users are released for testing, and for how many weeks?
- Which report does the audit expect to see after the cutover?
- Where are the books and files of the old system kept?
- What difference does the team accept at the first close, and who signs?
To the board and the committee
- Who represents tax on the committee, and with what authority?
- Can the cutover be postponed because of an undecided tax issue?
- What is the tax calendar for the month of the cutover?
- What happens if the first close has a difference?
- Is tax's own time in the schedule?
- Who accepts the risk that remains?
- Was tax consulted before the scope was frozen?
Six roles, and none of them decides the tax position for the client
The tax cutover fails when two roles think the other one decides.
| Role | What it decides | What it delivers |
|---|---|---|
| Migration committee | Whether the cutover happens with an open tax item and who accepts the risk. | A cutover calendar that respects the tax calendar. |
| The company's tax and tax law team | The tax position, the classification and the data that counts when there is a difference. | The expected result of each scenario and acceptance of the result. |
| Accounting and controlling | What difference is acceptable in the reconciliation and which opening balances count. | Checking of the balances and of the first-period reconciliation. |
| Company IT | Access, environment, retention of the history and technical window. | Test environments, data copies and the extension inventory. |
| Integrator | The technical strategy of the migration and the project schedule. | Conversion, load and adaptation of custom code. |
| DFSpro | Design of the assessment and of the readiness criteria, and proof of the system behavior. | Assessment, readiness criteria, scenarios and follow-up of the first close. |
Who proves and who decides
The check shows what the system does. What to do about an open item is the decision of whoever answers for the company.
We step into the tax side of the migration: we design, configure and prove. Migration strategy and tax treatment belong to your company and your integrator.
DFSpro proves
- Where each tax issue starts and for what cause.
- That the adjustment made in the system produces the agreed result.
- That the report and the evidence repeat at each close.
The company decides
- The tax classification of each operation and the position behind it.
- Which data counts when two sources disagree.
- Whether the cutover happens with an open item and who accepts the risk.
- What difference is acceptable at the first close.
The full role of DFSpro in any tax work is in how we work with your team.
From assessment to the first close proven
Three fronts, all aimed at proving tax in the new system.
- 01
Assessment and readiness criteria
The tax side of the migration is mapped with your team, and the readiness questions get the evidence your company will demand.
- 02
Proof of behavior
The system behavior in the scenarios the company chose is proven with evidence, from the document to the payment slip.
- 03
First close
The first period in the new system is followed with the reconciliation report in use, until the difference falls to a level the company accepts.
The full offer for the migration is in ECC to S/4HANA migration. The standard for new units is in tax rollout in SAP.
Support after go-live is in AMS Fiscal Advisory: post-go-live stabilization. Whoever cannot yet see the risk starts with the SAP Tax Diagnostic.
Where the environment uses GUEPARDO Tax, the integration is part of the assessment. The product belongs to NTT DATA. DFSpro, an Authorized Channel, sells the license, implements it and handles governance.
Plan tax support before project support ends
Tax support starts in the migration plan, not after go-live.
Owner after go-live
Who follows tax after the integrator leaves? The name must exist before the cutover.
Project support deadline
Project support has an end. Tax support must start before it ends, so there is no gap.
Support boundary
What counts as an incident, a change and routine is written down, with an owner and a channel, before project support ends.
From project to routine
When the first close is proven, follow-up moves from project to routine, with the reconciliation report running every period.
The detail of this period is in AMS Fiscal Advisory: post-go-live stabilization.
Documents read on 16/10/2026
The maintenance dates and the conversion roadmap come from SAP. The invoice numbering rules and the retention of books come from the rules cited.
Frequently asked questions about tax in the S/4HANA cutover
Planning tax in the migration4 questions, 01 to 04
01Should tax have its own cutover window?+
Yes. Tax has steps that do not fit in the technical window: checking opening balances, the numbering sequence and the restart of invoicing. An own window lets you place the cutover away from the middle of a close and give each step an owner.
02Who owns tax master data during the migration?+
Someone inside the company, named before the design. The consultancy shows differences and proposes a load rule, but the decision on which data counts belongs to the client. Without that name, the load carries the error into the new system.
03What should be assessed in tax before designing the migration?+
Four things: the obligations that must run in the first period, the custom developments that touch tax, the owner of each tax master data item and the evidence the audit expects to see after the cutover.
04How do you decide what to replicate, reconfigure and retire?+
Each tax rule in use gets one of the three decisions, recorded with an owner and a reason. A rule with no owner and no recent use is a candidate to go. The tax position behind each rule remains the client's decision.
Being ready for the cutover4 questions, 05 to 08
05Which questions show whether tax is ready for the cutover?+
Are there real scenarios with evidence? Is there an open item that prevents issuing or posting? Were the first-period obligations validated? Was the tax and accounting reconciliation of the first period done? Each answer asks for a document, not an opinion.
06What happens to tax extensions in the migration?+
They do not migrate just because they are old. They need an inventory, an owner, expected behavior in writing and a test in the new system. SAP recommends removing unused code, and its check does not find every case.
07Does a phased migration change the tax test plan?+
Yes. Each phase that goes live needs its own scenarios and a check of the balances that pass from one system to the other. The plan says which scenarios repeat at each phase and which count only once.
08When should you start thinking about tax support after go-live?+
At the assessment. Project support has an end, and tax needs an owner, a channel and a deadline before it. Leaving the subject for after the cutover creates a gap right at the first close.
Who decides and who supports10 questions, 09 to 18
09Which questions should you ask the integrator about tax?+
Where the scope names tax and with which deliverables, whether the test conversion has data and access for tax, which extensions that touch tax are in the inventory, whether the integrated test goes all the way to the payment slip and what support exists after go-live.
10Who represents tax on the migration committee and with what authority?+
Someone inside the company, with the authority to say that the cutover cannot happen while a tax issue is undecided. The consultancy supports with evidence and questions, but the tax decision and the acceptance of risk belong to the client.
11What must tax have assessed before the scope is frozen?+
Which obligations run in the first period, which custom developments exist, who owns tax master data and what evidence the audit expects. Whoever freezes the scope without these answers usually reopens it later.
12How do you explain to the board why tax needs its own time in the schedule?+
By risk, not by deadline. The tax result only shows at the close, and an open item can become a late obligation or a wrong file. Asking for its own time is asking to prove before going live. Any estimate depends on the environment and is handled in a direct conversation.
13Does invoicing stop during the cutover?+
Usually there is a pause, and its length depends on the design of your project. What tax needs to know is when invoicing stops, who releases it again and what happens to the operation that cannot wait. This workaround plan is written before the window.
14What is the role of the audit in the tax cutover?+
The audit, internal or external, is usually the one that asks for the evidence afterwards. Calling it in early, to say which reports and which checks it accepts as proof, avoids redoing the work at the first close. The decision on what the company presents is the company's.
15Does the S/4HANA integrator already cover tax?+
It depends on what the contract says. In some scopes tax appears only as generic customization, and it is worth checking yours. The useful question is where the scope names tax setup and tax testing, and who answers for the result of the first close.
16Do I need GUEPARDO Tax to do this work?+
No. The work applies to any SAP environment. Where the environment uses GUEPARDO Tax, a product of NTT DATA, the integration is part of the assessment. DFSpro, an Authorized Channel, sells the license, implements the product and handles its governance.
17Who keeps the files and books of the old system?+
The company. Keeping books and documents remains its duty in any system. The migration plan must say where the history stays accessible, for how long and who looks it up in a tax audit or an audit.
18Does the migration change the first-period obligation?+
The obligation stays the same, but the file for that period can mix data from two systems. The plan defines which system produces the file and who checks the content against the tax calculation before sending.
Bring the cutover plan and the list of what tax still has no owner for
The conversation covers your plan, the tax calendar of the cutover month and who decides each point, with no price and no commitment on deadlines.
To go deeper first: ECC to S/4HANA migration e unstable tax close.