Updating the GUEPARDO Tax release: when to decide and what to prove
Changing the product version is a decision about the tax calendar and about risk, not only an infrastructure task. Here are the questions that set the window, the evidence to keep beforehand and the comparison that proves the result afterward.
NTT DATA owns the product. DFSpro, as an Authorized Channel, sells the license, implements and does the governance. Your company decides what to install, and when.
Enter through the question your role needs to answer
Four entries for the same decision: each role sees a different part of the decision to update the release.
01Tax and accounting
The calendar of obligations, the window that is possible and what the company accepts as a difference.
See the part for this role02Accounting and audit
The evidence from closed periods and the comparison the audit will ask for.
See the part for this role03IT and infrastructure
The sequence of environments, the rollback plan and what changes in the production environment.
See the part for this role04GUEPARDO Tax governance
Who decides, who validates and how the decision and the accepted open item are recorded.
See the part for this roleDecision shortcuts
A decision about the calendar and about proof
Updating the release means choosing a window outside the close and proving the result by comparing periods that are already closed, before and after, with every difference explained.
When
After the month's obligations have been generated and delivered, and with room before the next deadline. The window comes from the tax calendar, not from the infrastructure schedule.
What to prove
The same scenarios from closed periods, before and after. What changed needs an explanation, and what has no explanation is investigated.
Who decides
Your company: the date, the risk of waiting, the risk of changing and any accepted open item. DFSpro designs the window and the proof and delivers the comparison.
The comparison runs on the method of tax testing in SAP, after the decision is made.
Six questions that decide whether and when to change
The decision to update a release fits in six questions, in the order they need to be answered.
- 01
What is the calendar?
Which obligations are due in the coming weeks and which window is left between one delivery and the next.
- 02
What is the risk of waiting?
What the company carries by not changing now: a requirement with a date, debt that grows and dependence on a few people.
- 03
What is the risk of changing?
What can break in the production environment and what the company cannot undo by itself.
- 04
What evidence exists beforehand?
Closed periods, delivered filings and checked balances, kept with a date and an owner.
- 05
How to compare afterward?
The same scenarios run again, with the expected difference written down before looking at the result.
- 06
Who decides and who validates?
The person who takes the risk and the person who signs that the result is acceptable, named before the window.
The six questions apply to any change in the tax environment: product version, SAP package, custom extension or integration. The tax decision stays with the company.
Six reasons for tax to sit at the same table as IT
Treating the update as an infrastructure task leaves out the calendar and the evidence. These are the points that weigh most.
Tax depends on the result
The change alters the environment that produces the calculation and the filings. Whoever answers for the tax result needs to be in the decision from the start.
The calendar does not wait
Obligations have official dates. A badly chosen window collides with a delivery, and the company finds the problem with the deadline running.
The proof is tax proof
A server that is up and open transactions show that the environment works. Only comparing results shows that the value is right.
The risk belongs to the company
If something differs, the company answers to the tax authority. So the risk and the accepted open item are its decisions, on record.
The audit asks afterward
Months later someone wants to know why the result changed. Without a record of the decision and the comparison, the answer becomes the memory of whoever was in the room.
The change has an owner on both sides
IT runs the window and tax validates the result. Without both named, each side assumes the other checked.
Before choosing the date, the dates the change must not touch
Each obligation has an official deadline. The window only exists in the gaps between them.
| Obligation | Official deadline | Source |
|---|---|---|
| ECD | Delivery is due on the last business day of June of the following year, under the wording of IN RFB 2.142/2023. An authenticated ECD is replaced only in the cases listed in art. 8. | IN RFB 2.003/2021, arts. 5 and 8 |
| ECF | Annual delivery, due on the last business day of July of the following year. To correct, you deliver a new ECF, and a replacement ECD that changes accounts or recovered balances requires a corrected ECF (arts. 7 and 8). | IN RFB 2.004/2021, arts. 3, 7 and 8 |
| EFD-Contribuições | Regular delivery by the 10th business day of the second month after the calculation period, in a monthly file centralized at the head office. | EFD-Contribuições guide, v. 1.35 |
| EFD ICMS IPI | Each state sets the delivery deadline. Correcting without asking for authorization is possible until the end of the third month after the calculated month, and a correction that affects the IPI calculation of a period still inside the five-year limitation period requires a formal request to the Receita. | EFD ICMS/IPI guide, v. 3.2.2 |
| DCTFWeb | Monthly declaration, due at 23:59:59 on the last business day of the month after the taxable events. | DCTFWeb manual, January 2025 update |
The list does not cover every obligation in your scenario. Reinf, state and city obligations and the declarations of each sector go into the same count, and the window calendar is that of your establishment.
Six criteria for a window that tax accepts
The window criterion is a tax one: the environment only changes when nothing it produces is in progress.
- 01
After the month's delivery
The month's filings and declarations have been generated, transmitted and accepted. Nothing the change touches is in progress.
- 02
Outside the close
The accounting and tax close of the month is over. The team that validates the result is available, not consumed by routine.
- 03
Away from an annual deadline
No annual filing is being prepared or corrected. A difference found there may force a correction of what was already delivered.
- 04
With room to go back
There is time left to repeat the proof, fix and, if needed, return to the earlier state before the next deadline.
- 05
No rule change in the same week
If a new rule takes effect in the period, you need to separate what changed because of the rule from what changed because of the update.
- 06
With the team named
Whoever runs, whoever validates and whoever decides are present and informed, including on a local holiday and in vacation periods.
A window that meets all six criteria is usually rare. When no perfect one exists, the decision is to choose the least risky one and record which criteria were left out.
The criteria are the same, the emphasis changes
Product version, SAP package, extension, integration, setup and master data follow the same six questions, with different weights.
| Type of change | What weighs in the decision | What to prove afterward |
|---|---|---|
| Tax product version | The calendar of obligations, the distance to the current version and the window that is left. | Results from closed periods equal to the ones from before, or with the expected difference explained. |
| SAP package or version | The sequence with the other platform changes and what the tax environment depends on from it. | The scenarios that pass through the integration points between SAP and tax. |
| Custom extension | Who maintains it, what it changes and whether anyone can still explain it. | That the extension produces the same result and that no new deviation was created. |
| External integration | What depends on it at the close and what happens if it fails in the window. | That what comes in and what goes out still matches, document by document. |
| Setup | The reason for each rule and the owner who approved it. | That the new rule applies in the right period and the old one still applies to closed periods. |
| Master data | The quality of the records before the change and who fixes what the comparison finds. | That the corrected record produces the expected result and does not change periods already delivered. |
When the rule and the version change in the same period
An update rarely happens in a period with no rule change at all. Separating the causes is what keeps the proof clean.
Separate what changed because of the rule
When a new rule takes effect, part of the difference in results comes from it, not from the update. Record the difference expected because of the rule.
Compare with the rule of the period
Closed periods follow the rule that applied in them. The comparison must use the same rule on both sides, or explain the switch.
Avoid two changes in the same window
Whenever possible, one window per change. If that is not possible, the proof needs one more column: what changed because of which cause.
Leave the interpretation to the company
If the new rule allows more than one reading, the choice is the client's. The system records the chosen reading, and the comparison shows the effect.
Both sides carry risk, and both need an owner
An honest comparison lists the risk of waiting and the risk of changing, on the same sheet, with the name of who accepts each one.
Risks of waiting
- A requirement with a date asks for an adjustment the current environment cannot support, and the window gets shorter.
- The distance between the installed version and the current one grows, and the future change becomes bigger than it would be today.
- The environment depends on the knowledge of a few people, and team turnover raises the risk over time.
- Custom extensions stay unreviewed, and each new rule adds to code that nobody has inventoried.
Risks of changing
- A result changes with nobody having written down the expected difference, and the divergence shows up only at the close.
- A custom extension depends on a behavior that stops existing, and breaks without warning.
- The window collides with a delivery, and the proof has to be done with the deadline running.
- There is no rollback plan, and the only way out is to fix forward with the production environment already changed.
Waiting is also a decision, with risk and with an owner. The useful question is not which side has risk, but which risk the company accepts to take on this date, with the evidence it has.
Six situations in which postponing the change is the safest
Waiting with a criterion is as valid a decision as changing. These situations usually justify it.
When there is no base to prove
- The calendar is tight, with heavy deliveries and no safe window: changing now swaps a known risk for another that nobody measured.
- The evidence from before does not exist: without reference periods kept, the comparison proves nothing.
- The inventory is incomplete: if nobody knows which extensions and integrations exist, the proof has holes.
When there is nobody to decide and validate
- The validation team is absent: acceptance with no owner is the worst possible result of a window.
- There is a rule change in the same period: two changes together make it impossible to know which one caused each difference.
- There is no rollback plan: changing without knowing how to go back means accepting a risk with no limit.
Eight situations that put the update on the agenda
Each situation changes the weight of the risk of waiting. None forces a change on the spot: each forces a conscious decision.
| Situation | What changes in the decision |
|---|---|
| A requirement with a date | There is a rule with a deadline that asks for an adjustment in the environment. The decision gets a cut-off date, and the window calendar shrinks. |
| A platform change | A migration, a new SAP package or an infrastructure switch is scheduled. The update needs to go into the same sequence. |
| A recurring problem | The same symptom returns at every close and the cause is in the environment. The decision stops being optional and becomes a correction. |
| An audit ahead | An audit job is coming and the environment has open items. Changing before or after it is a choice tax has to make. |
| An incident in production | An error in the current environment calls for a fix that depends on a change. The decision leaves the plan and becomes an incident response, with the same care in proof. |
| A business need | A new operation, branch or document type asks for something the current environment does not offer. The change stops being technical and becomes a business one. |
| A third-party requirement | A commercial agreement imposes a tax or traceability requirement. The deadline comes from the agreement, and the company weighs the risk. |
| A team change | Whoever knows the environment is leaving. Recording and proving the current state before any change becomes more urgent. |
What exists in the environment before changing
The comparison only works if the starting state is described. These eight items make up the snapshot.
Installed version
The product and SAP version in production, with the date of the last change and who is responsible for it.
Setup
The configured rules, with owner, reason and date. The undocumented part is the one that surprises most in a comparison.
Custom extensions
The programs and adjustments made in the tax environment, with what each one changes. The full inventory is in custom Z extensions in tax.
Integrations
What comes in and what goes out: electronic documents, banks, obligations, external systems. Each contact point is a test point.
Master data
Records of material, partner and tax classification. Bad data shows up after the change as if it were a defect of the change.
Profiles and access
Who can change, approve and transport. The change is a good moment to check that access matches the role.
Periodic routines
Jobs, loads and reconciliations that run on their own. A forgotten routine that fails in silence is a classic cause of difference.
Existing documentation
What is written about the environment and what lives only in the team's head. What is not written needs to be surveyed first.
What to keep before changing, and where to keep it
The evidence from before is what gives the comparison its meaning. Without it, the "after" has nothing to be compared with.
- Results from closed and delivered periods: calculation by tax, balances and values by document.
- Filings transmitted and accepted, with receipt and date, for each obligation in the window calendar.
- Tax and accounting reconciliations for at least one full period, with the differences already explained.
- The chosen scenarios, with the expected value of each one and the source of that value.
- The description of the environment state: version, setup, extensions and integrations.
- The record of the decision: date, who decided, which risks were weighed and which open item was accepted.
Keep everything in a place with a date and an owner, outside the environment that is going to change. The earlier evidence loses its value if it exists only inside the system that was changed.
How much to keep depends on the risk accepted. One period, three periods or a full year are choices for tax, together with the audit, and DFSpro helps to size it.
Six steps to prove the result after the change
The proof is the comparison. The steps below apply to a product version, an SAP package or any change in the environment.
- 01
Choose the scenarios
Closed periods that cover the real cases: ordinary operations, exceptions, returns, adjustments and the cases that already caused trouble.
- 02
Write the expected difference
Before running, record what should be equal and what may change, with the reason. An expectation written afterward is rationalization.
- 03
Run before and after
The same scenarios in the current environment and in the updated environment, with the same data set and the same reference dates.
- 04
Compare line by line
Value by value, document by document, tax by tax. Checking by total hides differences that offset each other.
- 05
Classify each difference
Expected and explained, expected and not explained, not expected. Only the first class closes with no further questions.
- 06
Sign the acceptance
Tax records what it accepts and what remains open. IT only treats the change as complete after this signature.
The design of the scenarios and the exit criteria follows the method of tax testing in SAP.
A difference with no explanation is a point to investigate
Every difference has an origin. Looking in the right order avoids blaming the change for a problem that already existed.
Source data
The data came in different: a changed record, a document posted in another way or a different test data set. The cause is before the calculation.
Process
The routine changed: order of execution, who posts, when it closes. The system did what it was asked, and the request was a different one.
Configuration
A rule was changed, or stopped applying, or started applying at another moment. Comparing the setups usually finds the cause.
Every difference with no explanation is a point to investigate from these three origins, in that order.
- Do not accept a difference because it is small. A small value repeated across many documents becomes a large value in the month.
- Do not explain a difference by assumption. The explanation must be reproduced, not just plausible.
- Do not close an item with no owner. A difference with nobody responsible becomes a forgotten open item.
- Record each difference and its class, so the next change starts from a history.
Eight types of period the comparison needs to cover
Using periods that are already closed gives a reference value that nobody needs to recalculate on the spot.
- A period of ordinary operation, with the company's most frequent documents.
- A period with a return, a cancellation and a document supplement.
- A period with an interstate operation and with an export or import operation, if they exist.
- A period with a service and with withholding at source, if they exist.
- A period with a manual calculation adjustment and with a value that does not come from a document.
- A period with a change in tax rule in the middle of the month.
- A period of annual close, with the tax and accounting reconciliation.
- A case that already caused trouble, with the fix already applied.
Eight is a reference, not a minimum. The right number is the one that covers the cases that cause differences in your environment, and the team that closes the month knows what they are.
Five steps between the test environment and production
The order of the steps matters more than the name of each one, and each step answers a different question.
- 01
Development environment
Where the change is prepared and the custom extensions are adjusted. Nothing here proves a tax result at real volume.
- 02
Quality environment
Where the proof runs, with data similar to production. The difference between this environment and production needs to be written down.
- 03
Rehearsal with a copy of production
When it exists, it is the best place for the comparison. Data about real people and documents requires care with access and disposal.
- 04
Window in production
The change is applied on the approved date, with the team present and the rollback plan reviewed the day before.
- 05
Check right afterward
The minimum scenarios run again in production before use is released. The result goes into the record, with date and time.
The role of each environment also appears in tax rollout in SAP and in migration to S/4HANA.
How to go back, when to go back and who decides
The decision to change is only complete when the decision to go back is also written down.
| Element of the plan | What to write before the window |
|---|---|
| What triggers the rollback | A criterion written beforehand: type of difference, value or number of documents affected. Without the criterion, the decision to go back becomes an argument under pressure. |
| Until when going back is valid | A limit: the window in which rollback is still possible without losing data posted after the change. Past the limit, you can only fix forward. |
| Who decides to go back | One person with authority, not a group. At the last minute, a group decision takes time and the deadline keeps running. |
| What to do with what was posted | Documents created after the change and before the rollback need a defined treatment, agreed with tax, before the window. |
Four roles, named before the window
Decision and validation on the company side have a name and a function. DFSpro supports, and does not take either role.
Tax and accounting
Decides the window and the accepted risk, validates the result and signs the acceptance. The tax position behind each difference is theirs.
Accounting
Checks that the tax and accounting reconciliation still closes and that the opening balances are intact.
IT and infrastructure
Runs the change, keeps the rollback plan and ensures the sequence of environments. Does not decide whether the result is acceptable.
Environment governance
Keeps the inventory, the record of the decision and the history of differences. It is the memory that survives a change of team.
A role named before the window avoids the deadlock in which each area thinks the other checked.
Four questions each area needs to answer
The decision gets faster when each area comes to the table with its answers. These are the ones that most often block the window.
Tax and accounting
- Which obligations are due between the planned date and the next one?
- Which difference does tax accept and which requires a fix before use?
- Who signs the acceptance?
- Which tax decision is open and may appear in the comparison?
Accounting and audit
- Are the opening balances checked and kept?
- Does the tax and accounting reconciliation close today, for a full period?
- What evidence will the audit ask for months later?
- Where are the record of the decision and the record of the open item kept?
IT and infrastructure
- What is the sequence of environments and how much does each one look like production?
- What are the criterion and the limit for the rollback?
- Who is on call in the window and who decides to go back?
- Which periodic routines need to be paused and resumed?
Environment governance
- Are the inventory of extensions, integrations and setup up to date?
- Who answers for each configured rule?
- What history of differences will the next change inherit?
- Who looks after the evidence after the window closes?
Six fields to record the decision to go ahead with an open item
Recording the accepted open item turns an omission into a decision, with an owner and a deadline.
- What is open, described so that an outsider understands.
- Why the company accepts to go ahead with the open item, and what a change of date would force it to do.
- Who accepted, with name and date.
- Until when the open item is valid and what happens if the deadline passes.
- Who follows it and how the next close will show whether it was resolved.
- The expected impact on the obligations of the period, with what the tax authority could see.
Going ahead with an open item is a legitimate decision, as long as it is conscious and recorded. The problem is not accepting, it is accepting without anyone knowing they accepted.
Nine fields that turn a window into a documented decision
A short record, made before the window and completed afterward, answers most of what the audit asks.
| Record field | What to write |
|---|---|
| Change | What will be changed, in business words, and the reason to change now. |
| Calendar considered | The obligations of the period and the gap chosen for the window. |
| Risk of waiting | What the company carries if it does not change, with the name of who accepts it. |
| Risk of changing | What can go wrong and what was done to reduce it. |
| Evidence from before | Where it is kept and who owns it. |
| Expected difference | What should change and what should stay equal, written before running. |
| Rollback plan | Criterion, limit and the person responsible for the decision to go back. |
| Who decided and who validated | Names, roles and date. |
| Accepted open item | What stayed open, until when and who follows it. |
What the first close after the change should show
Tests show that the environment behaves as expected. The real close shows that the tax result is right.
- Obligations come out with no rework, pass the validator and match the calculation. A new manual fix needs an explanation.
- The tax and accounting reconciliation still closes. A balance that fails to close for the first time is a clue that something changed.
- The opening balances are still equal to those in the evidence from before.
- The team does not need extra work. If the close got heavier, the environment changed behavior or someone is offsetting a problem.
The first close after the change is the strongest proof. The method is in tax testing in SAP.
Six questions that arrive months after the change
Whoever audits does not see the window. They see the record. If the record answers the six questions, the change stands on its own.
- 01
Why did the result change?
The answer is the expected difference, written beforehand, and the comparison that shows the real difference.
- 02
Who decided to change on this date?
The answer is the record of the decision: who, when, with which risk weighed and with which calendar in hand.
- 03
What was proved before release?
The answer is the evidence package from before and after, with the scenarios and the results.
- 04
What stayed open and who accepted it?
The answer is the record of the accepted open item, with name, date, deadline and follow-up.
- 05
Were the period's deliveries affected?
The answer is the check of the period's obligations, with receipt and comparison with what was expected.
- 06
Will this repeat in the next change?
The answer is the history of differences and the updated inventory, which the next window inherits.
Six mistakes that leave the problem for the close
These mistakes appear in any change to a tax environment and are costly because they are found late.
Preparation mistakes
- Choosing the window by the IT schedule: the tax calendar finds the collision too late.
- Writing the expectation afterward: with the result in hand, any difference seems explainable.
- Changing with no rollback plan: the only way out becomes fixing forward, with the deadline running.
Proof mistakes
- Comparing only totals: the differences offset each other and the total matches.
- Proving only in the test environment: different data and volume give a different result.
- Leaving the decision without an owner: the change happens because nobody blocked it.
Ten questions to ask before deciding
A no on any line does not stop the change. It shows what to resolve first, or the risk to take on consciously.
| Question for your team | If the answer is no |
|---|---|
| Is the calendar of obligations for the next weeks on the decision table? | The window may collide with a delivery. Survey the calendar before fixing the date. |
| Are there closed periods chosen as reference? | Without a reference, the comparison has no starting value. Choose and keep the periods. |
| Is the expected difference written before the change? | The result will be explained afterward, which weakens the proof. |
| Is the inventory of extensions and integrations up to date? | There is a risk that an extension breaks with nobody knowing it existed. |
| Were tax and IT named to decide and validate? | The change can happen with nobody signing the acceptance. |
| Does the rollback plan have a criterion, a limit and an owner? | The decision to go back will be made under pressure, with no rule. |
| Is the evidence from before kept outside the environment that will change? | The evidence may be lost in the very change it was meant to prove. |
| Does the quality environment look like production? | The proof in test may not hold in production. Record the known differences. |
| Will the validation team be available in the window? | The result will go unchecked for lack of people, not for lack of method. |
| Is there a place where the decision and the accepted open item are recorded? | The memory of the decision will depend on who was present. |
From the calendar map to the first close proved
Six deliverables, in order. The comparison is the center, and the others support it.
- 01
Calendar map
A survey of the establishment's obligations and the gaps where the window can exist.
- 02
Environment inventory
Description of the current state: version, setup, extensions, integrations and master data.
- 03
Design of the proof
Choice of periods, writing of the expected difference and definition of the acceptance criterion with tax.
- 04
Rehearsal and comparison
Running the scenarios before and after, with each difference classified.
- 05
Window and check
Follow-up of the change, rollback plan reviewed and a check right afterward.
- 06
First close
Follow-up of the next close until the difference falls to the level the company accepts.
The work can start with an SAP tax diagnostic or enter the continuous governance routine of AMS Fiscal.
NTT DATA owns GUEPARDO Tax. As an Authorized Channel, DFSpro also sells the license and implements the product, and does the GUEPARDO Tax governance. What the product is can be found in what GUEPARDO Tax is.
Eight deliverables, each with a recipient
Each deliverable has a use and a recipient. None depends on a tax decision by DFSpro.
| Deliverable | What it is for | Who receives it |
|---|---|---|
| Calendar and window map | Shows the obligations of the period and the gaps where the change can happen. | Tax |
| Environment inventory | Describes the starting state, with an owner for each item. | IT and governance |
| Scenario book | Lists the chosen periods, the expected difference and the acceptance criterion. | Tax and accounting |
| Evidence package from before | Gathers the reference results and filings, with date and owner. | Audit and controllership |
| Comparison report | Compares before and after, with the class and cause of each difference. | Tax and audit |
| Rollback plan | Records the criterion, the limit and the person responsible for the decision to go back. | IT and tax |
| Record of decision and open item | Keeps who decided, what weighed and what was accepted. | Governance and audit |
| First close script | Organizes the follow-up of the first period after the change. | Tax and IT |
Who proves and who decides
The proof shows what the system does. What to do with each result is the decision of whoever answers for the company.
We help to decide the window, to keep the evidence and to compare the result. The decision to change, the accepted risk and the tax position belong to your company.
DFSpro proves
- That the environment inventory describes the starting state.
- That the agreed scenarios run before and after, with the same data set.
- That each difference has a class, a cause and an owner.
- That the evidence is kept with a date, for the audit.
The company decides
- The date of the change and the risk it accepts in it.
- What is an acceptable difference and when to return to the earlier state.
- The accepted open item and the handling of any tax point.
- The signature on the acceptance of the result.
The role of DFSpro in any tax work is in how we work with your team.
Laws and manuals of reference
The official laws and manuals where each deadline cited is written.
Frequently asked questions about the GUEPARDO Tax release update
01Is updating the GUEPARDO Tax release a job for IT or for tax?+
For both areas. IT runs the window and keeps the rollback plan. Tax decides the date, takes the risk and validates the result. Without both named beforehand, each side assumes the other checked.
02What time of the month is safest to update?+
After the month's obligations have been generated and delivered, and outside the close. It is also wise to stay away from an annual deadline, such as ECD and ECF, because a difference found there may force a correction of what was already delivered.
03How do we know whether it is worth waiting for the next window?+
Compare the risk of waiting with the risk of changing, on the same sheet. If there is no requirement with a date and no recurring problem, waiting usually costs little. If the current window collides with a delivery, waiting tends to be the safest choice.
04What evidence should we keep before changing?+
Results from closed periods, accepted filings with receipt, the tax and accounting reconciliation, scenarios with the expected value and the record of the decision. Keep everything outside the environment that is going to change, with a date and an owner.
05How do we compare before and after with closed periods?+
Choose periods that cover the real cases, write the expected difference before running and compare document by document, not only the totals. Each difference gets a class, a cause and an owner, and tax signs the acceptance.
06What should we do with a difference nobody can explain?+
Treat it as a point to investigate, in this order: source data, process and configuration. Do not accept it because it is small or explain it by assumption. Without a reproduced explanation, the difference stays as an open item with an owner and a deadline.
07Who validates the result on the company side?+
Whoever answers for the tax result, usually the tax area, with support from accounting on the reconciliation. IT confirms that the environment works, but does not decide whether the result is acceptable.
08What should change in the plan when there is a legal requirement with a date?+
The cut-off date takes charge. The window shrinks, the proof concentrates on the scenarios the requirement touches and the rollback plan needs to be even clearer. The interpretation of the rule stays with the company.
09How do we record the decision to go ahead with an accepted open item?+
Describe the open item, the reason to go ahead, who accepted it and when, until when it applies and who follows it. Also record the expected impact on the obligations. That way the open item stops being an omission and becomes a decision.
10What should the first close after the change show?+
Obligations generated with no rework, the reconciliation closing, opening balances intact and a team with no extra work. It is the strongest proof, because it uses real data. The comparison method is in tax testing.
11What should we do when the update falls in the same period as a rule change?+
Separate the causes. Write the difference expected because of the rule and the one expected because of the update, and use the same rule on both sides of the comparison. If possible, prefer two windows, one for each change.
12What questions does the audit usually ask after the change?+
Why the result changed, who decided and with which calendar, what was proved before release, what stayed open and who accepted it. A short record of the decision, made before and completed afterward, answers most of them.
13Does DFSpro decide when to update our environment?+
No. DFSpro helps to design the window, to keep the evidence and to compare the result. The date, the accepted risk, the open item and any tax-position point are decisions of your company.
14Do I need to have implemented GUEPARDO Tax with DFSpro to hire this follow-up?+
No. DFSpro also serves those who already have the product, and the scope is defined in a conversation about your environment. NTT DATA owns the product, and DFSpro can also sell the license and implement it, as an Authorized Channel.
Tell us which change is on the table and which obligations are due in the next weeks
The conversation covers the calendar, the state of the environment and who decides and validates, with no price and no commitment to a deadline.
To go deeper first: tax readiness checklist and custom Z extensions in tax.