Who looks after your tax setup after go-live? The criteria that matter
After go-live, the tax environment is left without anyone who knows it end to end. To choose who supports it, three criteria weigh more than the length of the service list: the cause of each incident shown with evidence, knowledge handed over to your team, and a regular report of what happened in the environment.
The tax decision stays with the company. DFSpro's part is to support the environment: handle the incident, prove the cause and document it.
Start from the question your role needs to answer
Four entry points to the same choice: each role looks at tax support from a different angle.
01Board and CFO
What is at stake when nobody owns the tax setup after go-live, and what proof to ask for before signing.
See the section for this role02Tax and accounting
What each service case must record, and why the time it takes to find an error matters.
See the section for this role03IT and SAP
Where to look for the cause, when the case goes to the official channel, and what evidence to bring.
See the section for this role04Procurement and contracting
The questions for the selection meeting and the documents that show how the support team works.
See the section for this roleShortcuts for choosing tax support
Choose by proof, not by promise
Choose tax support by what it proves, not by what it promises: the cause of each incident with evidence, the knowledge that passes to your team, and a report that shows what changed in the environment.
Root cause with evidence
Each incident ends with an explanation of why it happened, the data or rule that shows it, and the test that proves the fix works.
Knowledge handover
What is learned in each case is documented in a place the company controls, so it does not depend on one person or one supplier.
Regular report
Volume, open items, recurring causes and changes applied, in a format that lets the company decide with data.
If you have just gone live, the right moment is post-go-live stabilization. If you have been running for some time, the routine is continuous governance.
The day after, who looks after the tax setup?
The project ends on a date. The tax calendar goes on every month, and the environment needs someone who knows it.
| What existed in the project | What happens after go-live | What this requires from the support team |
|---|---|---|
| A consultant who owns the design of each tax rule. | The consultant goes back to another project or the contract ends. The explanation of why the rule was designed that way leaves too. | Record the reason for each rule, so another person can understand the decision without relying on whoever made it. |
| A request queue from the project, with deadlines and priorities. | The queue closes with the project. New requests arrive by email, hallway chat or an uncategorized ticket. | A single point of entry, with a priority rule tied to the calendar of tax obligations. |
| A small group of people who understood the whole environment. | Some of these people change roles or companies. The knowledge stays in a few heads. | Living documentation, kept up to date with each case, in a place the company controls. |
| A calendar of tests and deliveries. | The calendar that now applies is the tax one: month-end tax close, ledger filing, payment slips, and the deadlines of each state and city. | Know the company's calendar of obligations and anticipate what falls close to a change. |
| A legal scope frozen at the project date. | Layouts, rules and regulations change. The environment keeps calculating with what was configured. | Follow the changes that affect the environment and assess the impact before they become incidents. |
| A documentation package delivered at the end. | The documentation gets old with every adjustment nobody records. | Update the record with each case, not only at the end of a cycle. |
Three signs the environment has no owner
Nobody can say who changed the rule
The environment calculates differently from one month to the next, and explaining it means rebuilding the history of adjustments.
The same type of incident comes back
Each occurrence is handled as a new case, with no record of the cause, and last month's fix is not documented.
The tax close depends on one person
When that person is away, the close runs late or goes out with a manual adjustment that nobody can explain afterwards.
These signs apply to any environment, with or without GUEPARDO Tax. When they appear, the question is no longer whether the system works. It becomes who answers for it every day.
Six steps that every case goes through
Supporting the tax environment includes investigating the cause and documenting each case. Each step below can be asked of any supplier.
- 01
Record the case
The case starts with what happened, where and with what impact: company, CNPJ (the Brazilian company tax ID), state, period, sample document, expected value and actual value. Without this record there is no way to reproduce it.
- 02
Reproduce
The incident is reproduced in the test environment or with the real document. A case that cannot be reproduced has no cause, and the talk becomes about hypotheses.
- 03
Find the cause
The cause is searched layer by layer: source data, process, configuration and, last, custom development. Each layer ruled out is noted.
- 04
Fix or work around
The fix goes to the cause. A workaround is accepted only with a deadline, an owner and a record of when it will be replaced by the fix.
- 05
Prove
The scenario is run again, with the expected value next to the actual value. The test is stored with the case for the next time the rule changes.
- 06
Document
The final record shows the cause, the fix, who approved it, where the test is kept and what changes in the routine. It is what lets another person pick up the case a year from now.
When the deadline is tight, steps 5 and 6 are the first to be lost. A case that ends at step 4 solves the day and leaves the next case just like this one. The tax tests are the way to keep step 5 repeatable at every change.
The same method in different cases
The method is recognized by what is recorded in each type of case.
| Situation | What the support team does | Evidence that remains | What the company decides |
|---|---|---|---|
| The tax on an invoice comes out different from what was expected | Reproduces it with the document, compares the expected value with the actual one and looks for the cause in data, process and configuration. Fixes it and runs the scenario again. | The sample document, the field or rule that explains the difference, and the test with expected and actual value. | Whether the expected value is the right one and what to do about invoices already issued. |
| A technical note changes the layout of the NF-e (Brazil's electronic invoice) | Identifies what changes, measures the impact on the environment, proposes the adjustment with its test and agrees the release date with the owner. | The comparison between the old and new layout, the list of affected fields and the result of the test in the test environment. | When to release to production and what risk to accept close to the deadline. |
| The month-end close does not match the ledger filing | Separates what is a data difference, a process difference and a configuration difference, and ties each one to a document. | A reconciliation report with the difference per document and the cause of each. | Whether to fix it in the system, adjust the filing or amend the period. |
| A state's legislation changes the rule for an item | Assesses whether the change affects the environment, shows the current rule next to the new one and proposes the adjustment with the correct effective date. | The text of the regulation, the rule configured today and the test scenario with the effective date. | The interpretation of the regulation and the classification of the item. |
| A custom development fails after an update | Finds the program in the inventory, identifies the owner, reproduces the failure and proposes the fix or a swap to a standard function. | The inventory, the affected piece of code and the test that shows the result before and after. | Whether to fix it now, replace it with a standard function, and by what date. |
In all of them, the support team delivers the same set: what happened, why it happened, what was done and the proof. A decision that depends on interpreting the law goes back to the company.
Source data, process and configuration
Before blaming the product, the support team looks for the cause where it usually is, in the order it usually is.
Source data
When the master record is wrong, the error repeats in every document. The usual candidates are NCM, CEST, CFOP, origin of the goods, tax regime and partner registration, the municipality of the service and the effective date of the benefit.
Process
When the order of the steps is wrong, correct data produces a wrong result. The usual candidates are cancellation after filing, returns, postings outside the period, layout release and period close.
Configuration
When the rule is out of date or incomplete, the document comes out with a value different from the expected one. The usual candidates are tax determination, the effective date of the rule, the tables per state and the exception for each benefit.
The order matters. Changing the configuration when the error is in the master record fixes one document and keeps the cause. Changing the master record when the error is in the process takes the same problem into next month. That is why the first step is always to find the layer, and only then to fix.
When all three layers are correct, the investigation moves on to the company's own custom development, which decides the result in many environments. The page on tax setup details the configuration, and the one on tax master data covers the master records.
What weighs more than the list of services
For each criterion, the questions that show whether the support team meets it, and the sign that it does not.
Criterion 1: root cause shown with evidence
Root cause is the explanation of why the incident happened, not only of how it was worked around. With evidence: the value, field, configuration or rule that shows where the problem began.
| What to ask | What a good answer shows | Weak sign |
|---|---|---|
| Show us the last incident you investigated. | A sample document, the path of the data to the error, the fix and the test that proves the result. | Only the outcome: adjusted, advised, resolved. |
| At what level do you look for the cause? | Source data, process, configuration and custom development, in that order, with a rule for deciding when to stop. | Reprocessing or manual correction without a diagnosis. |
| How do you prove the fix worked? | A repeated scenario, with expected and actual value, stored with the case. | We tested and it worked, with no record. |
| What happens when the cause is not found? | Ruled-out hypotheses listed, what is missing to decide, and who decides the next step. | Case closed by deadline, with no hypothesis recorded. |
Criterion 2: knowledge handover
The tax knowledge of an environment tends to live in a few people. The support team has to take it out of someone's head and put it in a place the company controls.
| What to ask | What a good answer shows | Weak sign |
|---|---|---|
| Where is the environment documentation kept? | In a company location, with company access, updated with each case. | In the supplier's repository or emails. |
| Who on our team learns from each case? | A person at the company follows the case and receives the explanation of the cause. | The case circulates only among the supplier's teams. |
| What happens if a person leaves, on your side or ours? | The record allows the work to resume without restarting the survey. | Dependence on one name. |
| What happens on the day the contract ends? | Documentation, change log and inventory delivered in an open format. | Delivery tied to a new contract. |
Criterion 3: regular report
The report shows, for a period, what came in, what was resolved, what is still open and what changed in the environment. It lets the company decide with data, not by impression.
| What to ask | What a good answer shows | Weak sign |
|---|---|---|
| What does the report show? | Volume by topic, open items with age and owner, recurring causes and changes applied. | Total number of tickets, with no topic or owner. |
| Does it point out causes that repeat? | Grouping by cause, with an improvement proposal and the company's decision recorded. | A chronological list of cases. |
| Who reads it and decides what comes out of it? | A meeting with the company's tax owner and minutes of the decisions. | Sent by email, with no follow-up. |
| Does the report cover legislation changes? | Changes that affect the environment, impact assessed and the decision that belongs to the company. | No link to the tax calendar. |
To assess the consultancy as a whole, not only the support, the article nine objective criteria for choosing an SAP tax consultancy has the full list.
Six documents that show how the support team works
A supplier's promise stays on paper. The document from a real case shows the method.
Case record
Date, who opened it, company and period, sample document, impact, priority, cause, fix, test and approver. It is used to rebuild a case months later, without relying on memory.
Cause report
The path of the data to the error, the layers investigated and ruled out, the evidence for each step and the final test. It is used to show the tax team, the audit or IT why the value changed.
Change log
Each adjustment to configuration or rules, with date, technical reason, approver and how to undo it. It is used to answer who changed what, when and why.
Regular report
Volume by topic, open items with age and owner, recurring causes, changes applied and open decisions. It is used to give the company the data it needs to set priorities.
Environment documentation
Companies, CNPJs, states, municipalities, main rules, close routines and the calendar of obligations. It is used so that a new person can take over without restarting the survey.
Inventory of custom developments
Each program or extension that touches tax, with owner, purpose and what tests it. It is used to know where a change in SAP or in the law can break something.
Minimum case record
- Who asked, when and with what declared urgency.
- Company, CNPJ, state, municipality and period affected.
- Sample document (key, number or posting) and the expected result.
- Layer where the cause was found: data, process, configuration or custom development.
- Evidence of the cause: the value, field, rule or screen that shows it.
- Fix applied or workaround agreed, with deadline and owner.
- Test that proves the result, with expected and actual value.
- Who at the company approved it and what changes in the routine.
Ask for a real example, without a company name, of each of these documents before signing. The quality of the example says more than the description of the service.
Seven indicators that tell the state of the environment
The report is worth what it lets you decide. These are the indicators that support that decision.
| Indicator | What it shows | How to interpret it | Decision it enables |
|---|---|---|---|
| Volume by topic | How many cases came in per tax subject in the period. | Concentration in one topic points to a common cause. | Prioritize an improvement. |
| Open items with age and owner | Open cases, for how long, and with whom. | An old item with no owner is a deadline risk. | Ask for a decision or reassign the case. |
| Recurring causes | Cases grouped by cause, not by date. | A cause that repeats calls for a fix at the root. | Approve the improvement. |
| Active workarounds | Temporary solutions, each with a deadline and an owner. | An expired workaround is a debt that grows with every close. | Set the replacement date. |
| Changes applied | Each adjustment to configuration or rules, with reason and approver. | Lets you rebuild the state of the environment at any date. | Answer the audit and the cross-check. |
| External changes under review | Regulations, technical notes and updates that affect the environment. | Shows what is coming before the obligation deadline. | Decide the release date. |
| Cases in the official channel | Tickets open with SAP or NTT DATA and the status of each. | Shows where the environment depends on an outside answer. | Follow the deadline and decide the workaround. |
Five questions the report has to let you answer
- What took the most work in this period, and why?
- Which cases are still open, and who decides each one?
- Which cause repeats, and what does it cost to leave it as it is?
- Which external change arrives before the next obligation?
- What changed in the environment, and who approved it?
If the report does not let you answer these questions, it describes activity, not the state of the environment. Reading it in a meeting, with minutes, is what turns the report into a decision.
Five moments when the support team shows up
Support is measured in the close cycle. The selection conversation should cover each moment.
- 01
Before the close
The support team checks open items, recent changes and what moves in the calendar of obligations, and warns the tax owner of what may affect the month.
- 02
During the close
Incoming cases are classified by impact on the obligation and by deadline, and the tax owner knows right away which case may delay the filing.
- 03
At filing
The support team follows the file validation, records the validator messages and prepares the evidence in case the result needs an explanation.
- 04
After filing
The differences found become cases, with cause and owner. What remained as a workaround gets a deadline to become a fix.
- 05
At the period review
The report is read with the tax owner, decisions go into minutes and the queue for the next period starts out with them.
A support team that describes its month in these terms shows that it knows the company's tax routine.
Six deliverables before the first case
Taking over an environment is different from answering a ticket. The first weeks are for learning what exists before touching it.
- 01
Environment survey
Companies, CNPJs, states, municipalities, installed products and versions. It is the map that shows where each tax rule lives.
- 02
Inventory of custom developments
Each program and extension that touches tax, with owner, purpose and what tests it.
- 03
Close map
Calendar of obligations, the person responsible for each step and the dependencies between them.
- 04
Initial queue
Open items and active workarounds, each with an owner and a deadline to become a fix.
- 05
Communication rules
Who opens the case, who classifies it, who approves and who is called on a close day.
- 06
First accompanied cycle
The first full period under the new routine, with the report in use and decisions recorded.
What the company provides at the start
Access
Test and production environments with defined profiles, and the list of who at the company approves each type of change.
Calendar and owners
The company's obligations by month, with the person responsible for each step of the close.
Existing documentation
What the project delivered, even if out of date, and the history of known adjustments.
Recent incidents
The cases from the last closes, with what was done, to show where the environment has already caused trouble.
When to start relative to go-live
Before go-live
The support team follows the tests and the cutover, and takes over an environment it already knows. It is the shortest way in.
Right after
The first period in production is the highest-risk window. The stabilization service exists for this moment.
In production for some time
Without a documented history, the survey comes first. The SAP Tax Diagnostic shows what needs to enter the routine.
The evidence goes with the ticket
Some cases have their explanation in the product. In those, the ticket goes out with all the evidence already gathered.
| Origin of the case | Official channel | What the support team brings |
|---|---|---|
| SAP function | The ticket is opened in SAP for Me, with the SAP knowledge base and notes as the first lookup. SAP also offers Expert Chat and a Q&A community. | The steps to reproduce, the version and component, and the note already consulted. |
| GUEPARDO Tax function | The ticket goes to NTT DATA, the product owner, through the product support channel. | The sample document, the setup involved, the product version and what was ruled out. |
| Custom development | The team responsible for the program, internal or contracted. | The inventory with the program owner and the scenario that fails. |
| Validator or authority portal | The layout and rules that the authority itself publishes, including the version in force in the period. | The layout version for the period and the full validator message. |
The evidence that goes with every ticket
Reproduction
The steps, with screen, transaction and data, so that whoever receives the ticket sees the same result.
Case data
Sample document, period, company, product version and expected value next to actual value.
What was already ruled out
Data, process, configuration and custom development checked, with the result of each.
Impact and deadline
What the incident affects and the date of the obligation it may delay, to set the ticket priority.
When the case belongs to the product, the support team opens the ticket with the evidence ready and follows the answer. A product improvement is the company's decision: it chooses whether to ask for it, adopt the workaround or change the process.
What the company keeps, what the support team takes over
Hiring support does not take tax out of the company. It defines who does each part.
Tax owner
Knows the operation and decides the tax treatment. Receives the report, reads the causes and approves what changes.
SAP owner
Answers for the technical environment, releases and access. Decides when a fix goes into production.
Improvement approver
Authorizes what moves from fix to improvement. May be the tax owner, within the company's authority.
The support team does
- Handles the incident and proves the cause.
- Proposes the improvement with the evidence that justifies it.
- Records each adjustment and each decision.
- Keeps the report and the documentation up to date.
The company decides
- The tax treatment of each operation.
- Whether an improvement requested by the tax team goes in or not.
- Whether to amend a period and how to handle the penalty.
- Who has access to what in the environment.
The company needs to keep someone in-house for tax, even with support. That person knows the business, approves what changes and answers for the decision. DFSpro's full role is in how we work with your team.
Why finding it early changes the cost
The regulations below set the deadline to correct without authorization, the penalty for incorrect information and how long to keep supporting documents.
| Regulation | What it says | What it asks of the support team |
|---|---|---|
| EFD-ICMS/IPI Practical Guide, amendment rule (version of 30/07/2026) | The EFD-ICMS/IPI (the digital tax ledger for ICMS and IPI) from January 2013 onward can be amended without authorization up to the last day of the third month after the close of the assessment month. After that, only with authorization, unless the state Finance Department waives it (from 03/09/2020). The amendment uses the layout in force in the period. | Detect the discrepancy inside the window. The review calendar needs to know this deadline, so the error shows up while it can still be corrected without asking for authorization. |
| Law 8.218/1991, art. 12 (wording of Law 13.670/2018) | Anyone who omits or gives incorrect information in records and files is subject to a fine of 5% of the value of the corresponding operation, capped at 1% of the legal entity's gross revenue in the period. In SPED (Brazil's digital tax reporting system), the fine is halved when the obligation is met after the deadline but before any ex officio procedure. | Find the error before an ex officio procedure. The regular report and the close review exist for this. |
| National Tax Code, art. 195, sole paragraph | The mandatory commercial and tax books and the supporting documents for the entries made in them are kept until the statute of limitations runs on the tax credits of the operations they refer to. | Keep the case record that explains an entry together with its supporting document, for the same period. |
The support team shows the discrepancy, the cause and the evidence. Deciding whether to amend, whether to ask for authorization or how to handle the penalty is the company's decision, with its accountants and lawyers.
Six signs to check before signing
What a proposal leaves unsaid usually weighs more than what it says.
Scope by list
A long list of services does not say how the service happens. Ask for the method for each case, not the catalog.
Service without cause
If the proposal talks about closing tickets and not about explaining causes, the same incident comes back with a different date.
Documentation at the supplier
Documentation that only the supplier can access leaves the company dependent on it the day it needs to change.
Workaround without deadline
A workaround is acceptable with a date, an owner and a plan to fix. Without them, it becomes the rule of the environment.
Volume report
Total tickets is not a report. Without topic, cause and open items, the number does not allow a decision.
Tax decision in the contract
The tax decision belongs to the company. A proposal that takes it on, or that does not separate it from the technical work, mixes responsibilities.
None of these points alone disqualifies a proposal. Together they show whether the supplier has a method for working your environment or only a service catalog.
Six answers your team needs to have beforehand
The choice gets more objective when the company knows what it expects from the supplier.
Who decides the tax treatment?
If the answer is vague, the decision ends up with whoever is in a hurry. Name the person before the first conversation with the supplier.
Which obligations fall due in the next closes?
The list shows where the service needs to be faster and which cases cannot wait for the monthly meeting.
Which custom developments touch tax?
Even an incomplete list helps. It shows where to look when SAP or the law changes.
Who approves a change in the environment?
Without a defined approver, each adjustment becomes a conversation. With an approver, it becomes a record.
Which recent incidents were left without a cause?
They show what is still missing from the records and which questions the support team has to answer.
What should stay inside the company?
Tax decisions, approval of improvements and knowledge of the business stay with the internal team.
Ten questions for the selection meeting
The answers show how the support works day to day, before the first invoice.
- 01
Who handles cases and who approves?
Listen for names and roles, and the substitution rule. Service with no defined approver pushes the decision to whoever is in a hurry.
- 02
How is a case classified?
A good answer ties priority to tax impact and to the obligation deadline, not only to the order of arrival.
- 03
How do you handle a change in legislation?
Ask for the latest example: how it was identified, how the impact was measured and who decided.
- 04
What does the first month look like?
Expect a survey plan, an inventory and an initial queue, not just an immediate start on cases.
- 05
Who accesses which data?
Listen for access profiles, usage logs and how access is removed when the contract ends.
- 06
How is service organized on close day?
A good answer shows a plan for the days of highest pressure, tied to the company's calendar.
- 07
How does knowledge come back to our team?
Ask for the format and frequency of the transfer and who at the company receives it.
- 08
How do you handle custom development?
Expect an inventory, an owner and a test. A program with no owner is the first place a change breaks something.
- 09
What does the exit look like?
Documentation, log and inventory should come out in an open format, with no condition of a new contract.
- 10
Who answers for the tax decision?
The right answer is the company. The support team records the decision and configures the system to apply it.
Use the same list with every supplier you assess. The comparison stays on each one's method, not on the service list.
A simple scorecard from zero to two
The same yardstick for every supplier keeps the comparison on method and takes weight off the sales pitch.
| What to score | 0 points: does not show it | 1 point: describes the method | 2 points: shows a real case |
|---|---|---|---|
| Cause shown with evidence | Talks about resolving tickets, with no example. | Explains the layers it investigates. | Presents a case without a company name, with the path of the data to the error. |
| Test that proves the fix | Does not mention testing. | Describes the test for each fix. | Shows the scenario with expected and actual value. |
| Documentation in a company location | Documentation stays with the supplier. | Promises to hand over the documentation at the end. | Shows the environment documented, with company access. |
| A company person on each case | Service only among the supplier's teams. | Plans for follow-up by the company. | Shows the record of who at the company followed a case. |
| Regular report | Reports only the total number of tickets. | Lists the indicators of the report. | Shows a report with topic, cause, open items and decision. |
| Change log | Does not keep its own record. | Describes how it records. | Shows adjustments with reason and approver. |
| Inventory of custom developments | Does not deal with custom development. | Plans the survey at the start. | Shows an inventory with owner and test. |
| Evidence taken to the official channel | Passes the ticket on without preparation. | Describes the evidence it gathers. | Shows a prepared ticket, with no customer data. |
Add up each supplier's points and look first at the first three items on the list, which are the core criteria. A high total without those three is a sign of a well-written proposal with little proof.
The three criteria applied to your environment
DFSpro is a consultancy specialized in tax on SAP and on GUEPARDO Tax. Support is one of the ways of working the environment.
Cause with evidence
For DFSpro, supporting the tax environment includes investigating the cause of the incident and documenting each case.
Knowledge that stays
The documentation of each case exists so that the company does not depend on one person or one supplier.
Report and record
A report for each period, with the seven indicators above, and a record of each change in the environment, with the reason and the approver.
Where each service fits
Where the environment uses GUEPARDO Tax, an NTT DATA product, the support starts from what the product covers and records what it does not cover. When the case requires the official channel, the ticket is opened with NTT DATA with the evidence already gathered.
Who proves and who decides
The support team shows what the system does. What to do with the result is the decision of whoever answers for the company.
We support the environment: we handle the incident, prove the cause and document it. What the company decides, including the tax treatment, stays with the company.
DFSpro proves
- Where the incident arises and from what cause.
- That the fix produces the agreed value.
- That the incident was handled and the cause documented.
The company decides
- The tax treatment of each operation and each benefit.
- Whether a difference is acceptable or must be corrected.
- Whether an improvement goes in, whether to amend a period and how to handle the penalty.
Regulations and reference pages
Each state's rule is in that state's own legislation.
Frequently asked questions about tax support in SAP
How to assess the support4 questions, 01 to 04
01What should you ask of tax support?+
Ask for the cause of each incident with evidence, a record that lets you resume the case, documentation that stays with the company and a regular report with volume, open items and changes. These items show the supplier's method better than the contract's service list.
02How do you know the cause of an incident was really investigated?+
Ask for the report of a real case, without a company name. It should show the sample document, the path of the data to the error, the layers ruled out and the final test. Whoever only says they adjusted something, without showing the path, worked around the problem without explaining it.
03What should you ask for in a regular report?+
Volume by topic, open items with age and owner, recurring causes, changes applied and open decisions. The report should be read in a meeting with the tax owner, with minutes of the decisions, not only sent by email.
04What separates tax support from a generic IT support contract?+
An IT contract measures whether the system is available. Tax support measures whether the configured rule matches the legislation and the real operation, with an owner and a record. An environment can be available and still calculate wrongly, and that difference is what the contract has to address.
Knowledge and continuity4 questions, 05 to 08
05How do you make sure the knowledge does not stay in one person's head?+
By requiring a record at each case, in a place the company controls, and a person at the company following each case. Also ask what happens when someone leaves, on the supplier's side or yours, and what will be delivered at the end of the contract.
06How does the support team take over an environment that already exists?+
In stages: a survey of companies, CNPJs and versions, an inventory of custom developments, a close map, an initial queue of open items, communication rules and a first accompanied cycle. What the environment already has is recorded before any adjustment.
07Does the company need to keep someone in-house for tax?+
Yes. Someone at the company knows the business, decides the tax treatment, approves improvements and answers for the decisions. The support team handles the incident, proves the cause and documents it, but the decision stays with the company.
08When should support start relative to go-live?+
Ideally it follows the tests and the cutover, to take over an environment it already knows. After go-live, the first period in production is the highest-risk window. In an environment that has been running for some time, the survey comes before any adjustment.
Decision and official channel4 questions, 09 to 12
09Who approves an improvement requested by the tax team?+
The company. The support team presents the improvement with the evidence that justifies it: the incident that repeats, the cause and the expected effect. The approver, who may be the tax owner or whoever the company names, decides whether it goes in, when and with what priority.
10When the case requires the official channel, what evidence does the support team gather?+
The steps to reproduce, the sample document, the product version, the expected value next to the actual one and what was already ruled out. With this the ticket reaches SAP or NTT DATA complete, depending on the origin of the case.
11How do you know the environment is being documented at each case?+
Ask for access to the case record and the change log. Each case should have cause, fix, test and approver. If the documentation is only updated at the end of a cycle, it is already behind the environment.
12Does DFSpro decide the tax treatment?+
No. The classification of each operation, the use of a benefit and any tax thesis are decisions of the company, with its accountants and lawyers. DFSpro configures the system to apply what the company decided and proves that the system behaves that way.
Scope and changes4 questions, 13 to 16
13Does support replace the project integrator?+
No. A project and support are different in nature. A project has a start and an end and delivers an environment. Support looks after it afterwards, every month. The integrator stays responsible for what the project contract covers, and support works with it on cases that touch both.
14Can I change support provider after signing?+
You can, and the effort of the switch depends on what was recorded. With documentation, inventory and change log in an open format and under the company's control, the new supplier starts from what exists. Without that material, the survey starts over from zero.
15How does support handle custom developments?+
It keeps an inventory with the owner, purpose and test of each program that touches tax. When SAP or the law changes, the inventory shows where to check. A program with no owner or no test is the first point of attention in the regular report.
16How does a legislation change enter the service?+
As a case of its own. The support team assesses whether the change affects the environment, shows the current rule next to the new one, proposes the adjustment with its test and records the impact. The company decides the interpretation of the regulation and the release date.
Bring the list of the latest incidents and what the current support team recorded for each one
Describe how your environment is served today. The conversation covers who decides each point and what the record of each case needs to show, with no price and no commitment on timing.
To go deeper first: unstable tax close and mismatch between tax and IT.