Thirteen people decide on tax in SAP. Each one feels the failure in a different place.
The end user feels it in the invoice rejected at 18:00. The key user, in the spreadsheet that holds the rule. The CFO, in the tax that only shows up after the close. IT, in the ticket nobody knows who owns.
The cause is often in the same place: the setup and design of the tax environment. DFSpro, a specialist in tax on SAP and GUEPARDO Tax, shows where the environment has drifted from the company's decision.
Who takes part in the decision on tax in SAP
Thirteen roles take part in the decision, in three rings: decision and sponsorship, technical evaluation, control and final stage.
Decision committee
Where it hurts
Thirteen roles take part in the tax decision in SAP, and each one feels the failure at a different point.
What changes
An environment that shows how it calculates and proves what it runs, for every role at the table.
See the roleWho feels the pain
- 01End userAt 18:00, the invoice was rejected and the truck stayed in the yard
- 02Coordinators and key usersYou are the only person who knows the rule, and the system does not know it yet
- 03Tax managerYou close the month twice: once in the system, once in the spreadsheet
Who signs off
- 04CFOWhen the tax only shows up after the month has closed
- 05ControllerThe tax balance on the balance sheet that you cannot explain
- 06Tax directorThe tax position is decided. Do you know if the system runs it?
Technology
- 07CIOThe “urgent” tax ticket that jumps the queue on your roadmap
- 08SAP IT managerThe P1 ticket arrives at 19:00 and you do not know if it is tax or IT
- 09Technical influencerThe rule is there, it works, and you do not know why
Control
- 10ProcurementThe invoice got stuck in MIRO and the supplier called you
- 11Legal and complianceThe legal opinion is signed. What is missing is proof of what the system did on the date of the event
- 12Internal auditThe tax control is on paper. In the system, nobody knows where it runs
Who brings it to the committee
The tax calendar already has dates
Three dates apply to everyone in the room. What changes is who feels it first. The reform transition runs until 2033, when ICMS (Brazil's state value-added tax) and ISS (the municipal services tax) cease to exist (EC 132/2023, ADCT art. 129).
2026
CBS and IBS are already on the invoice
The 2026 invoice already shows CBS (federal consumption tax created by the tax reform) at 0.9% and IBS (state and city consumption tax created by the tax reform) at 0.1%, as a test. What SAP calculates now becomes history.
EC 132/2023, ADCT art. 1252027
CBS gets a reference rate
The setup error that is only a test today becomes tax overpaid or underpaid.
EC 132/2023, ADCT art. 127LC 214/2025, art. 1831/12/2027
SAP ECC leaves standard maintenance
After that date, the extension is optional and covers ECC until 31/12/2030. The reform and the migration start to share the same calendar.
SAP Support, Business Suite 7 maintenance strategyAt 18:00, the invoice was rejected and the truck stayed in the yard
Illustrative situation
18:00
You loaded the truck, issued the invoice, and the reply came back with a code nobody in the room can explain. The carrier calls. The manager asks who posted it. You open the spreadsheet, check the tax again and open a ticket with IT, which will only answer tomorrow. The error was in the master data and in the rule the invoice uses, which were not configured for your case.
What weighs on the day
Manual posting
- You post invoice by invoice, all day, because the master data and the rule do not bring the complete document.
- You calculate the service withholding by hand before posting.
- You fix the same master data error by hand the following week.
Spreadsheets and checks outside the system
- You keep a parallel spreadsheet because your case is not configured.
- You keep screenshots of accepted invoices in case someone asks later.
- You find out at the close that the invoice number does not match what was reported.
Rejection and deadline
- The invoice is rejected at 18:00 and the code does not say what to do.
- You miss the cancellation deadline or find out that the correction letter does not cover the error.
- The ticket to IT waits in the queue while the carrier waits for you.
A rule nobody wrote down
- For every new operation you ask about CFOP, CST and NCM and hear different answers.
- The field accepts the wrong value without warning, and every posting goes out with the doubt of whether it is right.
What changes in your routine
You post less and check the exception, not everything. The invoice comes in with tax and withholding calculated. The rejection comes with an explanation and a playbook. Every new operation has a written, tested rule, instead of a question in the group chat. When something gets stuck, you know who to ask and what changed.
From rejection to rule
- DiagnosticShows where posting is manual and where each spreadsheet and each rejection comes from.
- ConfigurationMaster data, tax rules, withholdings and XML intake in SAP and GUEPARDO Tax.
- ProofTest cases with the expected result and the system result, side by side.
- PlaybookRejection, cancellation, correction letter and contingency, with the deadline set by the rule in force in your state.
- AMS FiscalEvery change is recorded with a justification and reaches you.
Every rejection that repeats is traced to the master data or the rule that causes it.
Talk to DFSproYou are the only person who knows the rule, and the system does not know it yet
Illustrative situation
Day 2, 10:00
Yesterday's invoice was rejected and only you know why. You open the spreadsheet, check the calculation, post the correction by hand and write the ticket for the third time so IT can understand it. In the afternoon, you retrain whoever made the mistake. Nobody sees this work, because it only shows when you are away.
What only you know
What lives outside the system
- You post invoice by invoice what the correct setup would generate on its own.
- The parallel spreadsheet holds a rule that is not set up in SAP and GUEPARDO Tax.
- You redo the system's calculation outside it because you cannot prove it is right.
Master data that arrives wrong
- The material's NCM arrives wrong, and whoever created it is no longer at the company.
- The supplier's invoice arrives and their master record does not have the right tax regime or registration.
- CFOP and CST arrive swapped on the invoice, and you are the one who fixes them.
Testing without a script
- You write the tax rule three times until IT understands the ticket.
- You approve the fix without a test script, and the month-end close becomes the test.
- Every SAP note or release calls for a regression test nobody planned.
The rule lives in you
- The manual adjustment at month end makes the number close, and nobody but you can say why.
- You train the end user and the same error comes back the next month.
- If you go on vacation, the close stops.
What leaves your head
Everything you do outside the system becomes a configured rule and a test that shows it works. The case you post by hand today goes through the normal flow. The spreadsheet stops being the source of truth and becomes a spot check. The ticket goes out with a template, a sample invoice and the expected result. The regression test has a script. And the rule no longer lives only in your head: someone else can explain it, and you can go on vacation.
From manual adjustment to test
- SurveyThe cases posted by hand and the recurring adjustments are listed with you, and it becomes clear what is missing in the setup of SAP and GUEPARDO Tax.
- ConfigurationEvery rule that lived in a spreadsheet becomes a configuration, a test or a company decision.
- Master dataNCM, CFOP, CST and supplier data are blocked at master data entry, before they stop the invoice.
- ProofA ready, reusable tax regression test for every SAP note, release or reform change, with a test invoice and the result stored.
Every manual adjustment surveyed and turned into a configured rule and a test.
Talk to DFSproYou close the month twice: once in the system, once in the spreadsheet
Illustrative situation
Day 4, 18:40
The SPED (Brazil's digital tax reporting) file came back from the validator with an error in a field nobody touched. Accounting asks why tax does not match the ledger. Management wants to know if the month will close. You open the reconciliation spreadsheet, the same one as every month, because the system's number does not yet deserve your signature.
What changes at the close
The close stops depending on who remembers. The rule is documented, the invoice calculation and the tax assessment start from the same master data, and the manual adjustment becomes an exception with an owner. The environment shows how it calculates, and the reconciliation spreadsheet is no longer the only check.
Where the close slips
Checks outside the system
- You check in a spreadsheet what the system already calculated, because you cannot see where the number came from.
- The tax on the invoice differs from what goes into the assessment, and the difference always has the same shape.
- The adjustment that makes the month close has no owner and no recorded reason.
A calendar that does not wait
- EFD-Reinf and EFD Contribuições have their own calendars, and the same team feeds both.
- Rectification became part of the calendar, not an exception.
- ICMS-ST and DIFAL call for manual adjustment: each state, one rule and one reconciliation spreadsheet.
Rules stuck in people
- Only one person knows why the invoice calculates that way.
- A ticket to IT takes days, because nobody knows if it is master data, a rule or development.
- The state incentive exists in the law, but the system rule does not fully reflect it.
The management question
- The CBS and IBS reform arrives and there is no time, or environment, to test.
- When management asks if everything is fine, you answer “more or less”.
Steps to a number with an origin
- OriginEvery difference between invoice, assessment and bookkeeping gets an origin and is fixed in the master data, the rule or the interface.
- ProofReal cases of ST, DIFAL, returns, PIS and Cofins run before the close.
- DocumentationEvery rule with its origin and reason, so the knowledge leaves one person's head.
- ReformCBS and IBS tested in the environment before a rejected invoice teaches the lesson.
- ReportA score for each dimension and a severity level for each finding, with the origin of the number.
The difference between invoice, tax calculation and tax filing, traced back to the source.
Talk to DFSproWhen the tax only shows up after the month has closed
Illustrative situation
Tuesday, 17:00
The board wants to know how much tax goes out this month and how much credit comes back. You ask the tax team. The answer arrives at 19:00, in a spreadsheet, with a caveat: “we haven't closed yet.” The board will see that number tomorrow.
What changes in what reaches the board
Tax data starts coming out of the system under the same rule as the invoice and the accounting. You open a view by CNPJ, tax and month, and it is compared with the ledger. A document issue shows up the week it starts. Credit is broken down and cash can see it. Every parameter change carries its reason. The tax position stays the company's; the system now follows it and leaves proof of that.
From finding to cash
- SAP Tax DiagnosticShows where the system configuration produces the number you don't accept, with a score from 1 to 100 and a severity for each finding.
- ConfigurationIn SAP and GUEPARDO Tax, it aligns invoice rules, tax calculation and accounting, and brings into the system the case that today lives in a spreadsheet.
- ProofThe rules that move cash run in test scenarios, and what came out is kept next to what should have come out.
- Reform and split paymentBefore 2027, incoming invoices and receipt reconciliation go through testing with CBS and IBS (the new consumption taxes from the tax reform).
- AMS FiscalThe change log and the periodic report keep the number stable after delivery.
What is missing in the number
No full view
- You ask for the group's tax figures and get one spreadsheet per branch, never a single view.
- The total by CNPJ does not match the total by tax, and nobody can explain the gap without opening invoices.
- The number that goes to the board comes from a spreadsheet someone else built.
No real-time control
- You only know the tax after the calculation, and you set prices and cash plans mid-month without it.
- A pending or rejected invoice shows up on closing day, when it has already delayed the balance sheet.
- Forecast cash changes when the close reopens, and the board has already decided based on the first number.
No trust in the number
- The tax on the invoice is one figure, the tax in the calculation is another, and someone redoes the math outside the system.
- The tax balance and the accounting balance differ at close, with no explanation ready.
- The provision arrives from legal without a basis you can open.
Cash stuck
- The accumulated credit is on the balance sheet, and nobody knows when or how it turns into cash.
- A benefit that applies to your case is not set up, and the company pays the standard rate.
- Split payment and CBS and IBS reimbursement still have no place in the cash forecast.
Tax by CNPJ, tax type and month, with a score and a severity for each finding.
Request the SAP Tax DiagnosticThe tax balance on the balance sheet that you cannot explain
Illustrative situation
Monday, 9:30
The auditor asks why the tax recoverable account shows one balance and the tax calculation shows another. You know the March adjustment explains part of it. The rest, only by opening invoices. The close is already past due and the tax team has not yet released the calculation.
Where the balance does not close
Ledger and tax calculation that do not talk
- The credit in the calculation is not the same as the one in the balance sheet account, and the bridge between the two is built by hand.
- You look at the tax entry and cannot get back to the invoice that created it.
- The tax from one transaction lands in an account you did not choose.
Reconciliation in a spreadsheet
- The PIS and Cofins (federal revenue taxes) reconciliation lives in a spreadsheet that only one person understands.
- The tax clearing account keeps growing, and nobody explains the old balance.
- There are manual closing adjustments with no owner and no written reason.
A close that waits for the tax team
- The tax team's calculation sets the closing day, and the balance sheet waits.
- The SPED (Brazil's digital tax reporting) file comes back with an error and the accounting adjustment lands outside the period.
- The mapping of accounts to the reference chart sits outside the master data.
A number you cannot test
- The provision comes from a number you cannot test against the system.
- The tax burden report is a spreadsheet built from three sources.
- CBS and IBS still have no account or reconciliation designed.
What changes on the balance sheet
The invoice, the tax calculation and the ledger now follow the same rule. Every tax entry carries the invoice reference, and the adjustment that remains has an owner and a reason. The clearing account zeroes out by rule. The tax burden report comes out of the system and is compared with the ledger. The tax filing is simulated before the close, and the reform enters the chart of accounts before it weighs on the result.
From ledger to tax calculation
- DiagnosticShows where account determination and the tax code separate the ledger from the tax calculation, with a severity for each finding.
- ConfigurationLinks invoice, tax calculation and ledger account, from SAP to GUEPARDO Tax, and puts into the system the adjustment that is manual today.
- ProofEach posting case runs in testing, and the resulting entry is archived next to the expected one.
- ReformCBS and IBS accounts, codes and reconciliation are designed and tested before the volume arrives.
- AMS FiscalThe change log with justification keeps the balance explainable after delivery.
Every tax balance on the balance sheet linked to the invoice and the tax calculation that created it.
Talk to DFSproThe tax position is decided. Do you know if the system carries it out?
Illustrative situation
Wednesday, 8:00
The tax notice arrived with a short deadline: it asks for the ledger, the file and the justification for a transaction from three years ago. The team knows what the company decided about its position. Nobody can say whether the system did the same, in every branch, in that period.
What the signature does not see
Signing without seeing
- You sign the tax position without seeing which rules the system applies today, by state, transaction and CNPJ.
- The position is decided and documented, but nobody proves that invoices go out the way it was decided.
- The same transaction calculates differently in two branches.
- The state benefit exists on paper, but nobody proves on which invoices the rule applies.
Change without a trace
- The rule changed and nobody can say when the system changed with it.
- The consultant who set it up left and took the reason for each rule with them.
- The tax notice asks for proof that only an extraction requested from IT can provide.
Risk management
- To see the group's tax picture, the team stitches together spreadsheets from each unit.
- The exposure report for the board is built by hand, every month.
- Your team spends the month fixing invoices and has no time left to look at risk.
- The reform transition runs until 2033 (ADCT, EC 132) and has no owner, scope or defined budget.
What changes in the tax position
The environment starts explaining itself. You open the list of what the system applies, by state, transaction and CNPJ, and compare it with the position the company decided. Every rule change gets a date and a justification. The reply to a tax notice can start from a ready-made report. The reform gets a scope defined from what the system contains. The position is the company's; the system now applies it in every state, transaction and CNPJ, with proof of application.
From position to proof
- DiagnosticCompares the position with what the environment executes and ranks each difference by severity.
- ConfigurationAligns branches and states in SAP and GUEPARDO Tax, and loads benefits and special regimes as rules.
- ProofEach position that weighs on the signature becomes an executed scenario, with the expected and calculated values side by side.
- ReformThe environment is inventoried, and incoming and outgoing invoices with CBS and IBS go through testing.
- AMS FiscalThe position stays stable after delivery: every rule change has a date, an author and a justification.
The company's position compared with what the environment executes, by state, transaction and CNPJ.
Talk to DFSproThe “urgent” tax ticket that cuts the line in your roadmap
Illustrative situation
Thursday, 18:00
The tax director calls: the invoice is not being authorized and the branch's billing has stopped. The team that was about to close the quarter's delivery changes course. On Friday, the committee asks why the project is late. You know the cause, but you have no way to show how much tax work weighs on the queue.
What changes in the roadmap
Tax gets an owner, a scale and a script. Every ticket comes in with a class and a severity, and a recurring cause is fixed in the configuration. What is custom (Z) in tax is listed, with its function and destination. The tax scope of the ECC conversion and of the reform enters your plan with effort and a test window. Every change reaches production with proof.
From ticket to script
- DiagnosticThe cause of repeated tickets is mapped by severity, and tax stops fighting for the queue.
- InventoryWhat is custom in tax, with owner and function, before converting or upgrading.
- ProofTax test script by document and by technical note version, with the result recorded.
- ResponsibilityA matrix across IT, tax, the integrator and the software provider, with the rule documented and delivered.
- ContingencyAlert and script for the stalled document, and the tax change window agreed with finance.
What the queue hides
A queue with no scale
- Every tax ticket arrives as urgent, and you have no scale to say which one really is.
- Each provider sends the problem back to the other, and you are stuck in the middle.
- The tax change window competes with finance's, and the month-end close decides who gives way.
A cost nobody adds up
- Tax was delivered as a project and came back as an emergency project two months later.
- Nobody adds up the monthly cost of sustaining tax across the team, the integrator and the consultancy.
- A billing stop is your risk, and it is not in your risk register.
A stalled roadmap
- The custom Z code in tax blocks the upgrade, and nobody knows what each object does.
- The ECC date is on the calendar; the tax scope of the conversion is not.
- The reform landed on top of a roadmap that was already full.
- The configuration change has the transport, but not the why.
The tax scope of the conversion and the reform, with effort and test window.
Talk to DFSproThe P1 ticket arrives at 19:00 and you don't know if it belongs to tax or to IT
Illustrative situation
Monday, 19:00
The invoice was rejected, shipping stopped and the ticket arrives marked P1. The tax team says the system got it wrong. You pushed a transport yesterday, but you don't know if that was the cause. Nobody has the expected result of the rule.
What the ticket does not say
A ticket with no owner
- The ticket is born unclassified, and you spend the night finding out whether it is master data, a rule, an interface or code.
- At close everything is P1, and what is critical waits behind what is loud.
- The interface goes down and the meeting starts with “is this mine or is it tax's?”.
- The recurring NF-e (Brazil's electronic invoice) rejection has become your incident queue.
Change without testing
- Tax asks for a change in one sentence and you have no way to validate whether the rule is right.
- The tax transport goes up without a regression test, and the close is the test.
- The reform note and the GUEPARDO Tax release go in with no script and no inventory of what was applied.
- The quality system has no tax test data and lets through what production rejects.
Access and people
- The custom tax ABAP has a single owner, and he or she may leave.
- The same profile changes the tax code and releases the filing.
- The configuration has no documentation, and you explain it to the auditor by opening the screen.
What changes in the transport
The tax ticket arrives with the document key, the error and the owner. The change arrives with a case and an expected result, and you validate against that. Every tax transport goes up with the regression cases executed. The quality system reproduces production. The rule stops living in one person's head. IT implements what tax decided and shows that it worked.
From ticket to regression
- DiagnosticSeparates what is rule, data, interface and code, with a severity for each finding.
- ProofA minimal regression suite for transports, the reform note and the GUEPARDO Tax release, with expected and obtained results kept.
- ConfigurationTest data in the quality system, an interface mapped by document, and documented profiles and configuration.
- ReformAn incoming test document processed in the cockpit without errors before going to production.
Tax tickets classified by cause, and a regression for every transport.
Talk to DFSproThe rule is there, it works, and you don't know why
Illustrative situation
Friday, 14:00
The manager stops by your desk: “Why did this tax come out different on this invoice?” The rule was already in the environment when you arrived, and no document says who created it or why. You open the screen, test two similar invoices and the result changes from one state to another. The answer is due by Monday.
What changes in the investigation
Every rule gets a record with the reason, the company's decision and the test that proves it. The question “is it master data, a rule or code?” now has an answer with a scenario, an expected result and an obtained result. The diagnostic brings a score by dimension and a severity for each finding, and the reform arrives with a map of your environment.
What the environment does not document
Inheritance with no manual
- You inherited an undocumented configuration and you answer for it.
- Every investigation starts by trial and error, because the environment does not say which rules are active.
- You cannot tell what is standard from what someone customized.
Active rule and proof
- The question “which rule is active in each state?” takes days, because nobody has the list.
- When someone asks whether the cause is master data, a rule or code, the scenario that proves it is missing.
- Every change is tested differently, by whoever is available.
The committee's translator
- You translate tax for IT and IT for tax, and the analysis is left for later.
- Everyone asks you, and the knowledge leaves you without becoming documentation.
- Custom Z tax programs that only one developer can read hold back the next change in the law.
The reform at the door
- Leadership will ask what it costs before you finish reading the technical note.
- The incoming invoice with CBS and IBS fails because the purchase order has the condition and the XML does not.
From scenario to record
- DiagnosticA senior team, rule by rule: a score by dimension and a severity for each finding, with a scenario for each critical rule.
- ProofEach critical scenario executed, with expected and obtained results kept.
- ConfigurationWhat lives in code or in a spreadsheet moves to a documented rule in SAP and GUEPARDO Tax, when the company decides so.
- ReformEnvironment inventory and testing of incoming and outgoing invoices with CBS and IBS before the question arrives.
- AMS FiscalEvery new rule enters with an owner and a reason, and the periodic report shows what changed in the environment.
One record per rule in the environment, with the scenario that proves what the system does.
Talk to DFSproThe invoice got stuck in MIRO and the supplier called you
Illustrative situation
9:30
The supplier calls: the invoice is blocked and the payment deadline has passed. You open the screen and see “tax difference”. Was it the purchase order, the XML or the master data? Nobody on the floor can answer quickly. Tax says it is the order, you say it is the master data. The supplier keeps waiting.
Where the order goes wrong
The order is born without a rule
- The tax code on the order is picked from memory or copied from the last one.
- A purchase for own use and consumption, resale or industrialization is posted one way on the order and another in the tax calculation.
- Service withholding is calculated by a service type that someone chose without criteria.
The error shows up late
- The error only appears in MIRO, when the supplier has already delivered.
- The XML carries an NCM, CST or ST different from the order, and the item stays stuck.
- The supplier charges you, not tax, for a withholding that is not about price.
- The DIFAL (ICMS rate difference) on own use and consumption is posted by hand at month end.
Master data and credit
- The supplier is registered with no tax regime, no ICMS taxpayer status, or the wrong CNAE.
- ICMS, PIS and Cofins credit is lost on misclassified purchase orders.
- The supplier you pick changes the ICMS, PIS and Cofins credit, and the effect only shows up in the tax assessment.
- An invoice arrives with CBS and IBS that the purchase order does not have yet, or the other way around.
What changes in the purchase order
The purchase order is created with the tax determined by the rule in your environment. The supplier master is complete only when it holds the fields the tax uses. When the invoice differs from the order, the reason and the owner already show up, and the invoice does not wait for a conversation between departments.
From order to invoice
- MapHow the order tax is determined today and what the supplier master provides.
- ConfigurationRule by material category, operation and service withholding.
- ProofReal purchase orders and inbound invoices tested, including the reform fields.
- RecordThe rule, who decides it and the test results are all recorded.
Scope, exclusions and deliverables in three pages.
Download the procurement checklist (PDF, in Portuguese)The legal opinion is signed. What the system did is still unproven on the date of the event
Illustrative situation
Thursday, 16:00
The law firm asked for the rule as it stood on the date of the event. The appeal deadline is running, the opinion is signed, and the tax team replies by email that they will "see what can be reconstructed." You know the company's position. You do not know what the system was doing that day.
What cannot be proven later
A position with no proof in the system
- The opinion is signed, but no one can prove the month's invoices were calculated as it requires.
- The position applies to a class of transactions, while the system rule applies to a list of master records.
- The court decision entered as an adjustment by email, with no case number, no date and no exit condition.
- The interpretation changed in March, and no one knows from which invoice the system started applying the new criterion.
Proof that does not exist for that date
- The lawyer asks for the file, the log and the rule in force on the date of the event, and only today's rule exists.
- IT wants to free up space, the tax team wants to keep everything, and no one set the retention period by record type.
- The error was found after the audit began, and there is no record of when it started.
Contract and policy
- The contract with the consultancy says "tax setup" and does not separate configuration, proof and tax decision.
- The configuration ticket has no owner: the partner waits for a formal request and the contract does not provide for one.
- The compliance policy cites controls that the environment cannot show.
What changes in the proof
The proof is now created together with the rule. Each company position has, in the system, a rule with a start date, an owner and an exit condition, plus a sample of invoices showing the result. The file and the rule in force on each date are kept from now on. The error shows up in testing, before anyone outside finds it. The tax decision stays with your company, and each invoice carries proof that the system executed it.
From opinion to evidence file
- DiagnosticLinks each position reported by the company to the rule in the environment and ranks what does not reconcile by severity.
- ProofRules with legal effect run in testing, including the one that comes from a court decision, with the date it enters and leaves the environment.
- Evidence fileThe path of the number, from document to posting, with origin, date and owner, and the retention policy agreed with Legal.
- AMS FiscalEach adjustment noted with its reason and a report at the frequency set in the contract, so the contract has a deliverable you can hold the provider to.
What the company decides and what the configuration executes, separated in writing.
Download the decision boundary (PDF, in Portuguese)The tax control exists on paper. In the system, no one knows where it runs
Illustrative situation
Wednesday, 15:00
You ask for the evidence for the March tax assessment adjustment. You get a spreadsheet with the right total and a question with no answer: who approved it, and why? The committee meets next week and the external auditor already has the same point in the preliminary report. It is the third year.
What changes in the control
Each control now exists in the environment, not in someone's memory. The adjustment requires a reason and an origin. A setup change has an owner, a test and a justification. The evidence comes out of the system, with a date, and you can re-perform what the tax team did. The committee receives scores and severities that can be compared from one quarter to the next. The auditor tests the system's behavior, not the company's position.
Where the control does not reach
Control that depends on memory
- The control is in the risk matrix, and in the system it depends on someone remembering.
- The manual tax assessment adjustment happens every month and has no reason or approver recorded.
- The compensating control is in the meeting minutes and does not produce a report.
Change and access with no trail
- The tax setup changes, and no one says who changed it, when and why.
- The person who sets up the tax also posts and releases the payment slip, and the access matrix does not show it.
Weak evidence
- The small sample passes, and the month has thousands of invoices.
- The evidence arrives as a spreadsheet and a screenshot, with the time cut off.
- Between the invoice, the tax assessment, the ledger and the general ledger, each step has a person and an Excel file.
The committee and the external auditor
- The same tax finding reappears in the external auditor's report, year after year.
- The committee asks for a metric of tax risk and of the CBS and IBS reform and receives a narrative.
From control to report
- DiagnosticCrosses each declared control with what is configured and gives each gap a score and severity.
- ConfigurationAdjustments, rule changes and critical access now leave a trail by design.
- ProofTax tests show the expected behavior against the observed one, including for CBS and IBS.
- AMS FiscalChange log with justification and a periodic exceptions report, repeated quarter after quarter.
Each change with date, justification and approver, in a cycle report.
Download the sample report (PDF, in Portuguese)You know the problem exists. What is missing is a number the committee accepts
Illustrative situation
Tuesday, 11:00
Ten minutes into the committee agenda. The CFO asks about the cash effect, IT asks what will be touched, and Legal asks what will be proven. There is the story from every month and a spreadsheet the team put together. Someone asks where the number comes from.
What reaches the committee
The number is missing
- The problem shows up every month and there is no number that proves it.
- The number that reaches the committee comes from a spreadsheet, and the first question is about its origin.
- After approval, there is no starting point to show what changed.
Three departments, one failure
- The CFO asks about cash, IT about what changes in the environment, and Legal about what will be proven.
- The tax pain reaches the board as "the tax team's problem," and the cause in the configuration does not show.
- Tax and IT describe the same error in different ways.
- There is no list of what the reform will change in the environment.
Project and tax close
- The topic returns to the agenda at every close, without knowing its size or effect.
- A previous project ended in a document, and nothing changed in the system.
- The close does not stop, and following a project competes with it.
What the committee receives
The committee receives a snapshot of the environment: a score per dimension, severity per finding, the priority of each area and what depends on a company decision. Tax and IT start looking at the same evidence. After delivery, the score from before and the score from now sit side by side.
What the diagnostic delivers
- SAP Tax DiagnosticMapping, analysis, prioritization and final presentation, with a senior team and short interviews that fit around the close. The reference duration is 5 to 8 weeks, confirmed at the start based on CNPJs (the Brazilian company tax ID), SAP version and obligations.
- Score and severityA score from 1 to 100 in three dimensions and four severity levels: Critical, High, Medium and Monitor.
- ProofEach finding has a scenario that tax and IT can both see.
- ReformWith the environment inventory in hand, the answer to "are we ready?" becomes a list.
- AMS FiscalWhat was fixed stays fixed, and the report for each cycle shows the current score.
One-page executive summary: a snapshot of the environment and the score for the three dimensions.
Download the executive summary (PDF, in Portuguese)Seven documents ready for each person on the committee
Seven PDF documents and the basic guide, each one for a question the committee has.
Basic Guide to Tax Governance (PDF, in Portuguese)
Eleven domains of the tax environment in SAP and GUEPARDO Tax, each with the points the diagnostic examines and the roles most interested in it.
Roles
The whole committee.
One-page executive summary
One page for those with five minutes: the snapshot of the environment, the three dimensions and the first decision asked of the committee.
Roles
CFO, Controller, Tax director.
Technical sheet for SAP IT and GUEPARDO Tax
What the diagnostic reads in SAP and GUEPARDO Tax, with which access and in which environments, without writing anything to the system.
Roles
CIO, Tax manager, SAP IT manager, Technical influencer.
Procurement checklist
Scope, exclusions, deliverables, what the client provides, confidentiality, LGPD (Brazil's data protection law) and timeline per the contract, for comparing proposals.
Roles
CFO, Procurement, Legal and compliance.
Tax decision boundary
In two columns, what the company decides and what falls within the contract scope. It answers who decides what.
Roles
Internal audit, CFO, Tax director, SAP IT manager, Legal and compliance.
Cycle and tax close calendar
The diagnostic weeks laid over the tax close calendar and the governance cycle steps, with frequency set in the contract.
Roles
CIO, Controller, Coordinators and key users, Tax manager, SAP IT manager, End user.
Sample cycle report
The structure of the AMS Fiscal cycle report: state of the environment, changes with justification and approver, and open items.
Roles
Internal audit, CFO, Controller, Tax director, Tax manager.
Internal sponsor: what to bring to the committee
The fact that motivates the request, the effort asked of the company, what the diagnostic delivers and what stays with the company's decision.
Roles
Controller, Tax manager, SAP IT manager, Internal sponsor.
Questions about the SAP Tax Diagnostic
01Who needs to take part in the decision to hire an SAP Tax Diagnostic?+
In general, thirteen roles, from the CFO to the end user who runs the day-to-day work, plus the internal sponsor who brings the topic. Not all of them sign off, but all of them have influence. The company decides who decides.
02What does the internal sponsor bring to the CFO?+
The request is to analyze the environment before deciding on any project. The company's effort is one point of contact in the tax team, read-only access to SAP and short interviews. The reference duration is 5 to 8 weeks, confirmed at the start based on CNPJs, SAP version and obligations, and the executive summary fits on one page.
03What does each department need to provide during the diagnostic?+
One reference person in the tax team, one read-only access to SAP, and quick conversations with those who run billing, receiving and close. IT points out who knows each interface. No one needs to set up a dedicated team.
04What does the committee receive at the end of the work?+
The one-page executive summary, the heat map by area, the score by dimension, the findings matrix with evidence and the proof plan. Each finding comes with a suggested owner, and the committee chooses between fixing, accepting or monitoring.
05Does IT need to release write access to SAP?+
No. The diagnostic asks for read access, and no fix is applied without a company decision. When there is a fix, it follows IT's own transport routine, with a documented tax test.
06Can Procurement compare the DFSpro proposal with others?+
Yes, and the procurement checklist exists for that: scope, exclusions, deliverables, what the client provides, confidentiality and timeline per the contract.
07Is the report a legal opinion?+
No. A legal opinion, a decision on a tax position and a formal tax audit are outside the scope. The report flags the points that depend on interpretation and hands them back to Legal and to the board.
08Is the diagnostic worth doing if we already have GUEPARDO Tax?+
Yes. The diagnostic covers SAP and GUEPARDO Tax together and shows whether the rules in use still reflect the operation. The setup ages with the law and with the business, and that matters to those who already have the product.
09We already have an SAP integrator. Where does DFSpro fit in?+
In the tax rule, on top of what already exists. The scope is split in writing: the platform stays with the integrator, and the tax rule and the tax acceptance criterion for each delivery stay with DFSpro. Nothing is reimplemented, and the diagnostic uses read access.
10What if the committee decides to do nothing after the diagnostic?+
That is a possible answer. The final recommendation can be just to monitor, and any fix is contracted separately. The accepted risk is recorded, with the trigger that reopens it.
11How does Internal Audit follow the environment after the diagnostic?+
Through AMS Fiscal, when the company decides to keep it. Each adjustment is recorded with a justification and an approver, and a report per cycle summarizes the state, the changes and the open items, at the frequency set in the contract.
12Can we start with a smaller scope than the whole environment?+
Yes. The diagnostic can be by tax, by process, master data, pre-migration, pre-reform, post-go-live, credit and cash, or M&A. The scope is defined in the first conversation, based on what weighs most for the committee.
13Does the team that runs the routine need to change what it does during the diagnostic?+
No. The work installs no tool and does not change the routine. Coordinators and key users spend a few hours on interviews. Any change comes later, by committee decision, with the impact explained beforehand.
14How do I hire the SAP Tax Diagnostic?+
Through the contact form. For a preliminary read of the environment, there is the online readiness assessment . The scope of the diagnostic is defined in the first conversation.
SAP Tax Diagnostic for the whole committee
A score from 1 to 100 in three dimensions, severity in four levels per finding and the priority of each area, with the evidence behind each conclusion. The tax decision is always the company's.
The scope takes into account
- The SAP version
- How many CNPJs operate in it
- Whether GUEPARDO Tax is in place
- The obligations for the period