Your SAP tax rules need an owner and a review date?
SAP tax setup is the set of rules that tells SAP how to calculate, record and prove each tax: the calculation schema (TAXBRA), the conditions kept in J1BTAX, the CFOP determination (CFOP is the Brazilian code for the nature of each operation) and the tax categories of material, customer and vendor. When these rules collect exceptions without review, the problem does not show up as an error. It shows up as a slow close and a difference that comes back.
What DFSpro reviews, what is and is not tax setup, how the work is done and where it meets the tax reform and GUEPARDO Tax.
Pick your entry point by your role
Each area looks for its own answer about the tax setup. Go to yours.
01Tax and legal
What the law requires each parameter to represent.
Go to section02Accounting and tax calculation
The expected value, set outside SAP, for each scenario.
Go to section03IT and SAP architecture
When to configure and when to program an extension.
Go to section04Audit and internal control
Owner, validity, change and trail of each rule.
Go to sectionTax rule with no owner
How risk builds up
Most tax risk in SAP does not start with a dramatic failure. It starts with layers. An exception made for one state, a condition changed in a hurry at a close, a Z rule written for a customer who has since left. Each change made sense at the time, and nobody reviewed them together afterwards.
What is left for the team
The result is a set of rules that nobody can explain from end to end. The tax team trusts what the system calculates because it has always calculated that way. IT avoids touching it for fear of side effects. And when the auditor asks why a rate applies to a given operation, the answer depends on remembering who set it up and why.
Four signs that the setup has lost its owner:
- 01
Z rules or exceptions whose purpose is not documented.
- 02
The same tax, usually ICMS-ST (state tax collected in advance from the first seller), handled one way in one branch and another way in the next branch.
- 03
A manual adjustment at every close to fix the same calculation every month.
- 04
A setup change made directly in production, without going through a test environment.
Three layers of SAP tax setup
The review does not look at one isolated screen. It follows the path the tax takes inside SAP, from the master record to the invoice.
Calculation schema (TAXBRA)
The procedure that sets the order of conditions SAP uses to reach the value of each tax on the document. In systems that still use the older schema (TAXBRJ) or that just migrated, we check what came across, what changed in behavior and what was left duplicated.
Conditions and tax codes (J1BTAX)
The condition records that say which rate, base and rule apply to each mix of state, NCM (the Mercosur product code, the tax classification of the goods), operation type and tax category. This is where exceptions tend to hide, because each line looks small when it is created. A good part of this control depends on well-kept tax master data .
CFOP and tax categories
The choice of CFOP, document type and the tax categories of material, customer and vendor, which decides what rule enters each document. Wrong tax master data is processed efficiently, and the error only appears later, in SPED (Brazil's digital tax reporting system, the set of digital filings sent to the tax authority) or in the audit.
The review also covers ICMS (Brazil's state value-added tax), ICMS-ST and DIFAL (the ICMS rate difference between states), withholdings and the ancillary filings by CNPJ (the Brazilian company tax ID) and by branch. The starting point is always what must exist in SAP for the real operation, and only then what is configured.
Where tax setup starts and ends
Setting the scope helps anyone who has to explain internally what is being hired, whether in Tax, IT or Purchasing.
What it is
- List the rules in use, with origin, purpose and owner where there is one.
- Correct conditions, categories and determinations that do not reflect the real operation.
- Test in a test environment before any change reaches production.
- Document each rule, so the next person understands why it exists.
- Review again when the law changes, when a branch is opened or when the operation changes shape.
What it is not
- Deciding the company's tax position: how to use a credit or treat a specific operation is the client's decision, with legal and tax support.
- Issuing a legal tax opinion or a formal tax audit.
- Updating a rate in a table and closing the matter.
- Replacing the SAP implementation partner or the internal tax team.
- Promising a numeric result, such as a percentage of risk reduction.
The tax decision comes before the system setup. The setup can only be correct when the rule it represents has already been decided by the person who answers for it.
How we work
Four steps, always in the same order, changing only the starting point: a new implementation, or an environment already in production.
Survey
An inventory of the tax rules and setup in use, showing origin, purpose and owner where there is one. The internal team takes part, and daily operation does not stop.
Analysis
A comparison between what the system calculates and what the operation should report, by CNPJ and by branch. Each difference is tied to the rule that produces it.
Fix in the test environment
Rules are adjusted and tested in the test environment before any change in production. A technical test is not a tax test: the value must be right for the real scenario.
Documentation and review
Each rule gets its purpose, owner and review date recorded, with a new review each time the law changes in a relevant way.
Findings are rated with the same scale as the three phases of the DFSpro method: Critical, High, Medium and Monitor.
Tax matrix: error typesymptom and cause
Each setup error leaves a recognizable symptom. The table shows how we tie what appears at the close to the cause in the configuration, which is the reverse of the order teams usually follow when they fix things in a hurry.
| Error type | Symptom at the close | Likely cause in the setup |
|---|---|---|
| ICMS rate difference | The invoice value differs from the calculated one, usually in one state. | An outdated condition or a state exception that was never reviewed. |
| ICMS-ST different between branches | One branch's calculation does not match the next branch's. | Tax determination never standardized across units. |
| DIFAL missing or duplicated | Gap between tax and accounting in interstate sales to final consumers. | Incomplete customer tax category or determination rule. |
| Wrong CFOP | The ledger and SPED show a different nature of operation than the real one. | CFOP determination that does not cover the scenario, or wrong tax master data. |
| Credit taken improperly | The credit balance does not match the matching ledger account. | A credit rule set for a scenario that later changed. |
| Z rule with no owner | Behavior that nobody can explain, and that the team avoids touching. | Custom development built for one case and never reviewed again. |
The matrix is how we classify what we find. In real work, each line comes from the client's environment and gets a severity (Critical, High, Medium or Monitor).
A rule is only set up when it has its own record
Documenting the parameter is what lets you explain, months later, why the system calculates this way. The record below is the standard we apply. It is not a legal requirement.
- Source decision: Who at the client decided the position and on what date. The tax decision never starts in the configuration.
- Basis: The law behind the rule, with the provision and the date it was read.
- Key: The combination that finds the rule: state, NCM, CEST, operation type, and material, customer and vendor categories.
- Result: What the rule returns: rate, base, CFOP, CST, withholding code, account.
- Validity: Start and end. When the law changes, a new line is opened and the earlier one stays as history.
- Owner: The person or area that answers for the number and approves the change.
- Test that covers it: The scenario and expected value that prove the rule, with evidence from the last run.
- Dependencies: Master data, integration or extension the rule needs to work.
Three habits keep the record useful. Standardize before opening an exception: the second branch with the same treatment uses the same rule, not a copy. Every exception is born with a reason and, when it is temporary, an end date. And the rule's name says what it does, not who asked for it. The master data that feeds the key is in tax master data, and product classification is in NCM and tax classification.
Each tax makes the parameter represent a different rule
A tax parameter has four parts: the key that finds it (state, NCM, operation type, categories), the result it returns (rate, base, CFOP, code), the validity and the owner. The law says what the result must respect. What you check in SAP is in the third column.
| Tax | What the law sets | What to check in SAP |
|---|---|---|
| Own ICMS | Complementary Law 87/96 gives the general rules. Rate, base and benefits follow each state's law. | The key combines origin and destination state, operation type, and material and partner categories. Each line has a validity. |
| ICMS-ST | ICMS Agreement 142/18 lists the goods in Annexes II to XXVI, with NCM and CEST. The document carries the CEST even when the operation is not a substitution one (clause twenty). | The CEST is set up together with the NCM. An operation without substitution still carries the code. |
| DIFAL | ICMS Agreement 93/15 requires the total ICMS to be calculated at the destination's internal rate (clause two). LC 190/22 covers the charge on sales to final consumers who are not taxpayers. | Complete customer tax category and a determination rule for final consumers, without duplicating or omitting the share. |
| PIS and COFINS | Laws 10.637/02 and 10.833/03 set 1.65% and 7.6% in the non-cumulative regime and the credits in art. 3. Law 9.718/98 covers the cumulative one. | The regime is set by company and revenue. CST and revenue nature follow the NCM. |
| Withholdings | Law 8.212/91, art. 31, requires the contracting party to withhold 11% of the gross value on labor assignment. How the service is classified is the client's decision. | The service withholding code is tied to the tax code. The withholding base matches the invoice. |
| ISS | LC 116/03 and LC 157/16 define the service list and the 2% minimum rate. Rate and withholding follow the city. | City, service code and rate by city, with the withholding-at-source rule. |
| CBS and IBS | LC 214/25 sets, for 2026, CBS at 0.9% (art. 346) and state IBS at 0.1% (art. 343). In the next two years, 2027 and 2028, IBS adds 0.05% state and 0.05% city (art. 344). LC 227/26 creates the Management Committee and amends LC 214. | Test-phase parameters exist with a start and end date and run alongside the current regime. |
Official sources read on 15 and 16/10/2026 (full list at the end of the page). IPI, IRPJ and CSLL, and state tax benefits were not re-read in this round: the benefits topic is in state tax benefits and incentives. The calculation itself is in tax calculation in the Brazil localization, and the ICMS-ST and DIFAL rule is in ICMS-ST and DIFAL in SAP.
Versioning and changing the parameter without losing history
A parameter changes for three reasons: the law, the software update and the operation. What changes the risk is how the change comes in.
Change in law
A new rule needs a new validity. ICMS Agreement 142/18 shows why: the reclassification of an NCM code does not add or remove the good from substitution, and the document carries the current NCM (clause seven, paragraphs 2 and 3). The key changes, the treatment does not. Anyone who only swaps the NCM in the master record loses that distinction.
Change in release
Updating is not importing a package. First you list what the environment has of its own (extensions, user exits, transport orders after the fix cut-off date). Then you apply it in development, quality and production, in that order, and run regression on the affected filings. See GUEPARDO Tax release update.
Change in operation
A new branch, a new regime or a new product calls for a review of the key, not only the result. The question is whether the existing rule still represents the real operation, not whether it still calculates without error.
The reform is the most visible case. Each transition phase of LC 214/25 (arts. 343 to 347) changes the next year's rate. Each phase is a parameter with a start and end date, running alongside the current rule. SAP's correction packages for the topic are in SAP notes for the tax reform, and the design is in tax reform, CBS and IBS in SAP. How the rule will be applied to the operation is the client's decision.
Parameter proof: expected value set before the run
A document calculated without a system error does not prove the parameter is right. The proof comes from a series of scenarios, each with the expected value worked out outside SAP.
| Scenario | Expected value, set beforehand | Evidence kept |
|---|---|---|
| Ordinary internal ICMS | Base, rate and value checked in a separate spreadsheet, using the state's law. | The test document and the check calculation side by side. |
| Interstate operation | Rate and value of the operation, from the origin to each destination state tested. | A document for each state tested. |
| ICMS-ST with CEST | A listed good carries the CEST. A good outside the list also carries the code, with no withholding. | A document with the CEST and the withholding field checked. |
| DIFAL to a final consumer | Destination share calculated at the internal rate, without duplication. | The document and the amount owed to the destination. |
| PIS and COFINS with credit | Credit calculated according to the company's regime and the item's CST. | The line of the tax calculation record and the source account. |
| Service withholding | Withholding code and withholding base equal to those expected for the service. | The document and the accounting entry of the withholding. |
| ISS in the city | Rate and withholding of the city where the service is provided. | A service document for each city tested. |
| Operation without tax | The zero comes from an explicit rule (exemption, suspension), never from a missing parameter. | The rule that prevailed, identified in the result. |
| Reform test phase | 2026 CBS and IBS calculated at the LC 214/25 rates, alongside the current regime. | A document with both regimes and the check calculation. |
Two more checks complete the proof. The negative test, where the rule must not fire, catches excess. And regression after each change catches side effects. Accepting the value belongs to the area that owns the number, not to the consultancy. The test standard is detailed in tax testing in SAP, and what the tax calculation consumes is in tax calculation in SAP.
Set up or extend: the decision rule
Before programming, confirm that the standard does not cover the need. It is common for a need to look outside the standard without being so.
Set up when
The rule fits in the key that the standard already offers (state, NCM, operation type, categories).
The result is a value or a code that the standard knows how to return.
Whoever inherits the environment can read the rule in a table, without opening code.
A software update is unlikely to clash with it.
Extend when
The standard does not create a record that the filing requires.
The rule depends on information the standard does not have, such as an external table.
The extension point provided by the product is enough, without changing standard programs.
A functional specification, an owner and a test exist before coding.
The final question is practical: if the law changes tomorrow, who changes the rule and where? In our practice, an extension without an owner and built over a standard program is what usually breaks in an update. In a migration, each extension is analyzed so the logic is migrated, not copied. The topic has its own pages: ABAP and tax customization and tax clean core in S/4HANA.
Who answers for the rule, and how it changes
Governance, here, is a small set of habits that fit inside the tax close. It is not one more committee.
Inventory and owner
A single list of the tax rules, each with its full record and a person responsible. A rule with no owner is the first one to review.
Change with trail
Request, client decision, test in the test environment, transport and evidence. Whoever configures is not the one who approves the value. Nothing goes to production without a test and an approval.
Review cadence
A review each time the law changes in a relevant way and on a fixed date, even without a change. The date of the last review is kept on the record itself.
Three counts show whether governance works: how many rules have no owner, how many manual adjustments repeat at each close, and how many changes reached production without a test. A fourth signal is the gap between the last relevant change in the law and the last review of the record: if the second is earlier than the first, the rule may be out of date without anyone noticing. Reading these signals belongs to the tax close, once per period, with the result recorded. The support contract that handles this day to day is in AMS Fiscal governance.
Six setup mistakes that repeat in different environments
The matrix above ties the symptom to the type of error. These six are about method, and they appear even when each rule, on its own, is right.
| Method mistake | What happens next |
|---|---|
| Editing the current line instead of opening a new validity | History is lost, and recalculating earlier periods has no basis. |
| Fixing in the partner record an exception that belongs to the rule | The error goes away for one customer and stays for the others. |
| Copying another branch's rule without checking the key | The copy inherits the state, category and validity of its source. |
| Treating zero as absence | The operation without tax has no explicit rule, and the result stops being intentional. |
| Testing only the common path | The exceptional scenario shows up in validation by the area that owns the number, late and with a short deadline. |
| Changing the NCM and forgetting the CEST, or the other way round | The two go together in ICMS-ST, and the difference tends to show up in the tax calculation. |
Tax setup before the reform and alongside GUEPARDO Tax
This front does not stand alone. It is the base on which two others work.
CBS and IBS side by side
The move to CBS (the new federal tax of the tax reform) and IBS (the new state and city tax) requires two regimes to coexist in the same environment. A current setup with no owner is the riskiest starting point for that coexistence, because the new rule will be built on the old rule. Reviewing now reduces what will have to be fixed under legal deadline pressure.
Bridge to GUEPARDO Tax
In an environment with GUEPARDO Taxthe review also checks the bridge between what SAP determines and what GUEPARDO Tax calculates and reports, and whether the setup produces the right records for SPED. DFSpro is an Authorized Channel of NTT DATA for GUEPARDO Tax, and separating what is a setup adjustment from what is product behavior decides, in a ticket, whether the path goes to DFSpro or to NTT DATA.
Migration from ECC to S/4HANA
The same applies to the migration from ECC (SAP ERP Central Component, the earlier SAP ERP version) to S/4HANA (SAP's current ERP generation): a tax rule with no owner and no documentation is exactly what travels to the new environment without anyone noticing. Setup reviewed before the project reduces what will be found at the first close in production.
Official sources read for this page
Planalto
Complementary Law 87/96, LC 116/03, LC 157/16, LC 190/22, LC 214/25 (arts. 343, 344 and 346) and LC 227/26, compiled texts, read on 15 and 16/10/2026
Planalto
Laws 10.637/02, 10.833/03, 9.718/98 and 8.212/91 (art. 31), compiled texts, read on 15 and 16/10/2026
Blog articles on rule setup
What DFSpro takes on and what stays with the client
- 01
Designs and documents the rule, with key, result, validity and owner.
- 02
Configures the parameter in the test environment, with a test and evidence.
- 03
Proves each scenario against an expected value set beforehand.
- 04
Maps what a change in the law or in a release touches.
Outside our role
Deciding the tax position, such as credit, classification and treatment of the operation. That is the client's.
Issuing a legal tax opinion.
Replacing the SAP integrator or the internal tax team.
Promising a numeric result or compliance.
Common questions about SAP tax setup
01How is the review done, step by step?+
In four steps: first a map of the rules in use and who answers for each one; then a comparison between what SAP calculates and what the operation should report, by CNPJ and branch; then the fix in the test environment, with a tax value test; finally the documentation and the periodic review.
02What does DFSpro deliver at the end?+
Each reviewed rule gets a purpose, an owner and a test that covers it, with the differences tied to the rule that produces them. The result serves the tax close, the migration and the answer to the auditor when they ask why a rate applies.
03What is TAXBRA and how does it relate to TAXBRJ?+
TAXBRA and TAXBRJ are names of tax calculation procedures used in the SAP Brazil localization. Older environments use TAXBRJ, and the move to TAXBRA is a recurring topic in upgrade projects. The review checks which procedure is in use, what was migrated and what was left behind.
04What does J1BTAX do, in practice?+
It is the Brazil localization transaction where tax condition records are kept. It is where much of the exceptions by state, NCM and operation type live, so it is one of the first places we review.
05Do I need to be on S/4HANA already for the review?+
No. The review assesses the real setup, in ECC or in S/4HANA. Before a migration, it prevents carrying rules with no owner into the new environment, which usually goes unnoticed.
06Does the review interrupt the tax close?+
That is not the design. The survey runs in parallel with operation, with the internal team, and no change goes to production without a test in the test environment.
07How much does a review cost and how long does it take?+
It depends on how many CNPJs and branches exist, the SAP version and the number of Z rules. Because the effort varies with these factors, the scope comes from an initial conversation and the timeline is only confirmed when work starts, never promised in advance on a page.
08Does this apply to those who do not use GUEPARDO Tax?+
DFSpro's focus is the SAP environment integrated with GUEPARDO Tax, active or under evaluation. Standard SAP setup is part of the review because it is the base on which GUEPARDO Tax operates.
09Does every Z rule need to be removed?+
No. A Z rule with a documented purpose, a named owner and a test that covers it is a governed rule and can stay. What the review looks for are orphan rules: they exist, they affect the calculation and nobody can justify them.
10We already have an SAP integrator and a tax team. Does DFSpro take their place?+
No. DFSpro does not replace the SAP implementation partner or the internal tax team. It works at the tax rule layer, with the team taking part in the survey, and the tax decision stays with the client and their legal and tax support.
11Who needs to take part on the client side?+
Usually whoever is responsible for the tax close and whoever supports SAP, with Accounting at the points where the tax calculation has to match the ledger. Having the knowledge concentrated in a single person is, in itself, one of the findings the review records.
12What happens if we do not review the setup?+
The risk does not show up as an error, it shows up as a slow close, a recurring manual adjustment and a difference that returns every month. Over time, the rules collect exceptions that nobody explains from end to end, and the cost shows up in the migration and in the audit.
13How do I know if the setup is already out of date?+
Three questions help: is there a list of tax rules with an owner for each, is the last review later than the last relevant change in the law, and does a setup change go through a test environment. One negative answer is already a reason to look closely.
14How do we start?+
Through the SAP Tax Diagnostic, which shows where the setup lost its owner and what to review first. The request can be made through the contact page.
15Why do you not edit the current line of a parameter?+
Because the edited line erases history: an old document, reprocessed or audited, no longer has the rule that applied on its date. The way is to end the line's validity and open another, with the basis and the test of the change recorded.
16When should an exception become a general rule?+
When the same treatment appears in more than one branch, state or customer, with no different justification. If the exception is temporary, it carries an end date on the record. The decision to keep the different treatment is the client's.
17The product's NCM changed. Does ICMS-ST change too?+
Not necessarily. ICMS Agreement 142/18 says that reclassification, grouping or splitting of an NCM code does not add or remove the good from substitution, and the document carries the current NCM (clause seven, paragraphs 2 and 3). The CEST does not change because of it (paragraph 4).
18How does the 2026 reform test phase come in?+
LC 214/25 sets CBS at 0.9% (art. 346) and IBS at 0.1% (art. 343) for 2026 taxable events. In SAP it becomes a parameter with a start and end date, alongside the current regime. How to apply it to the operation is the client's decision.
19How do I decide between configuring and programming an extension?+
First confirm that the standard does not cover it. If the rule fits in the key and result the standard offers, configure it. If the product does not create a required record or information is missing that it does not have, extend it, with a specification, an owner and a test.
20Who approves a parameter change?+
The client decides the tax rule. The area that owns the number validates the value in the test environment. DFSpro designs and configures the behavior, proves it works and keeps the evidence. Whoever configures does not approve their own value.
Start with what your SAP already calculates
The first step is a SAP Tax Diagnostic: a structured assessment that shows where the setup collected exceptions without review, before any project proposal. If you are still unsure about the right time, the conversation helps you understand the situation with no commitment.