State tax benefits and incentives: from the granting act to the calculation and the proof in SAP
Presumed credit, deferral, suspension, exemption and base reduction have one thing in common: they only hold when they come from an act, meet a condition, appear on the tax document with the right code and can be proven later. SAP has to carry that whole chain, not just the final rate.
A state benefit in four numbers
Types, deadlines and the chain SAP has to carry.
types of benefit
Listed in ICMS Agreement 190/17.
deadline
Use of four categories of benefit.
reduction of benefits
In proportion to the rates (EC 132/2023).
from the act to the control
That SAP has to carry.
Choose the entry point by your role
01Management and decisions
What are state benefits and why does SAP need to know each one?
Go to the section02Tax and compliance
What forms can a benefit take, who can grant them and for how long are they valid?
Go to the section03IT and SAP
How is the benefit born in the SAP calculation, in six steps?
Go to the section04Audit and proof
What must be kept to prove use of the benefit, and who keeps it?
Go to the sectionThe list of benefits of each state depends on the rule of each state, and this text does not reproduce it. The text is for information only. It is not a legal opinion and does not replace an opinion on your case.
What are state tax benefits and why SAP needs to know about them
A tax benefit on ICMS (Brazil's state value-added tax, formally the tax on the circulation of goods and on interstate and intermunicipal transport and communication services) is any rule that reduces or removes the tax due on an operation.
The list in the law
Complementary Law (LC) 24/1975, in the sole paragraph of art. 1, lists as a benefit the reduction of the tax base, the refund of the tax, presumed credits and any other tax or financial-tax favors that reduce or remove the burden (LC 24/1975).
Three sides for those who run SAP
Calculation: the reduced, deferred or exempt tax has to come out right from the tax engine, in tax calculation in the Brazil localization, with no manual adjustment. Document: the NF-e carries the code the state requires. Proof: the company shows the act, the condition met and the amount relieved.
A calendar of its own
LC 160/2017 and ICMS Agreement 190/17 dealt with old benefits that never had approval from Confaz (the national council of state tax authorities), and Constitutional Amendment 132/2023 set, for 2029 to 2032, the reduction of benefits in proportion to the rates (EC 132/2023, art. 128 of the ADCT).
The chain that each state's page rarely shows
- The benefit is born from an act (law, decree, ordinance, special regime, agreement term).
- It is limited by a condition.
- It is valid for a term.
- It appears on the tax document through a code, the cBenef.
It has to be proven when someone asks. If one of these steps is missing from the ERP, the benefit stops being a right and becomes an assumption. So the useful question is not whether a benefit exists, but which ones the company uses, until when each one is valid and where that data lives in the system.
Seven ways to relieve tax, and what each one asks of the ERP
ICMS Agreement 190/17 lists, in clause one, paragraph 4, seventeen types of benefit, from exemption to “any other benefit or incentive, in any form, condition or name” (ICMS Agreement 190/17). The table groups the forms that appear most in the daily work of an SAP operation and shows what each one asks of the master data and the calculation.
| Type | What it does | Where it appears in SAP and on the invoice | What is usually the condition |
|---|---|---|---|
| Exemption | The outbound sale or the service creates no tax to pay. | Tax status code for exemption and a tax code with no debit; often requires cBenef. | Condition on the classification of the product or of the recipient. |
| Reduction of the tax base | The tax applies to part of the value, not to the total. | Reduced base in the calculation, and an “other” or “exempt” base for the part relieved. | Percentage from the act, which must be in a table with a validity period. |
| Presumed or granted credit | The taxpayer takes a credit set by rule, instead of the real credit or on top of it. | Entry in the ledger and assessment; on the invoice, a dedicated presumed credit field in some states. | Compliance with the grant act and, sometimes, an investment in return. |
| Deferral | Payment is postponed to a later stage. | Deferral tax status; tax set to zero at the stage and control of the deferred balance. | Proof that the next stage happened and who pays. |
| Suspension | The tax stays suspended until the event the act defines. | Control of the shipment and the return, or of the conversion into a final sale. | Return deadline and the document that ends the suspension. |
| Credit maintenance | The credit from the inbound purchase is kept even when the outbound sale is relieved. | No-reversal rule in the engine and in the assessment ledger. | List of inputs and products to which the maintenance applies. |
| Payment extension and financing | Payment of the tax due is postponed or financed. | More common in the assessment and in finance than on the invoice. | Agreement term or special regime with conditions. |
The official list is longer: it includes refund of the tax, deduction of assessed tax, waiver of payment, earlier timing to take a credit, credit for investment, remission, amnesty, moratorium, settlement and installments over a longer period than the agreements allow.
Deferral and suspension are not named in the list of 17 types in paragraph 4 of clause one of ICMS Agreement 190/17, whose last type is “any other benefit or incentive, in any form, condition or name”. The SAP and condition fields describe project logic, not the rule of one specific state.
State programs have names of their own, and the names change from one state to another. The name of the program does not change the analysis: what you need to know is which type on the list it is, which act created it, which condition supports it and until when it is valid. When the name comes without those four answers, the ERP master data is not ready yet.
Who can grant an ICMS benefit and what the law requires
Three laws and agreements form the legal frame. The rest is detail for each state.
Granting an ICMS benefit is not a decision each state takes alone: the constitutional rule is regulated by a complementary law, and without an agreement the benefit is irregular.
LC 24/1975
Exemptions and other benefits only through agreements signed and ratified by the states and the Federal District (DF) (art. 1). A grant needs a unanimous decision of the states represented (art. 2, paragraph 2). Each executive branch ratifies by decree within fifteen days, and silence counts as tacit ratification (art. 4). Failure to comply makes the act void, makes the credit of the receiving establishment ineffective and makes the tax payable (art. 8). LC 214/2025 (art. 543) repeals arts. 1 to 12, 14 and 15 of LC 24/1975 from 01/01/2033.
LC 160/2017
Allowed the states to decide by agreement on the remission of credits from benefits created without an agreement and on the re-creation of those still in force (art. 1). Quorum of two thirds of the federal units and one third of each of the five regions (art. 2). Makes the agreement depend on the publication of the list of acts and on the filing and deposit of the documents with Confaz, published on the National Tax Transparency Portal (art. 3).
ICMS Agreement 190/17
Regulated LC 160. Defines normative acts (published up to 08/08/2017) and grant acts, lists the types of benefit, requires publication of the list in the official gazette and the filing and deposit with Confaz (clause two) and creates the National Tax Transparency Portal (clause seven).
Specific agreements
Each benefit authorized by Confaz has its own agreement, which defines who uses it, in which operation and under which condition. ICM Agreement 65/88, on outbound sales to the Manaus Free Trade Zone, is the example detailed below.
Three questions should have a documented answer before any setup: does the benefit have an agreement or was it re-created under LC 160; did the federal unit meet the publication, filing and deposit requirements; and does the taxpayer have a grant act or a direct fit in the rule. When the answer to one of them is “I don't know”, the ERP will inherit the doubt.
Deadlines of use and the tax reform: what the sources say
A benefit has an end.
Two sources, two calculations
Paragraph 5 of clause ten of Agreement 190 sets 20% a year from 2029 for three groups of benefits, while paragraph 2 of art. 128 of the ADCT says that, for the LC 160 benefits, the reduction in art. 128 itself applies and not the one in paragraph 2-A of art. 3 of LC 160. The conclusion for each case must be drawn from the rule that applies to your benefit, with legal support.
Source 1: ICMS Agreement 190/17 and LC 160/2017
31/12/2032Deadline for using the categories in the table below: art. 3, paragraph 2, of LC 160/2017 sets deadlines by category, and clause ten of Agreement 190, as worded by Agreement 68/22, sets 31/12/2032 (LC 160/2017 and Agreement 190/17).
From 01/01/2029, clause ten, paragraph 5, sets a reduction of 20% a year on the grant and the extension of commercial benefits, of interstate shipments of farm and plant-extraction products in natura, and of port and airport activity tied to international trade. LC 160, art. 3, paragraph 2-A (added by LC 186/2021), has a similar rule from the twelfth year after the agreement takes effect.
Source 2: Constitutional Amendment 132/2023
2029 to 2032Art. 128 of the ADCT (the transitional provisions of the Constitution) reduces the ICMS and ISS rates from 2029 to 2032: nine tenths in 2029, eight tenths in 2030, seven tenths in 2031 and six tenths in 2032. Benefits and incentives on these taxes are reduced in the same proportion (paragraph 1), and the benefits in art. 3 of LC 160 follow art. 128, without the reduction in paragraph 2-A (paragraph 2) (EC 132/2023).
The amendment also created the Compensation Fund for ICMS Tax or Financial-Tax Benefits, to compensate, between 01/01/2029 and 31/12/2032, those who have benefits granted for a fixed term and under condition (art. 12). It applies to holders of onerous benefits that were granted regularly, and reading art. 12 in full is essential before any cash forecast.
The two clocks of the ICMS benefit, 2026 to 2033
A state ICMS benefit runs on two deadlines at the same time. The first comes from LC 160/2017 and ICMS Agreement 190/2017, which limit use to 31/12/2032. The second comes from the reform: from 2029 to 2032 the ICMS rate and the benefits fall together and, in 2033, the tax is abolished. Enter the benefit and the deadline of the grant act and pick a year to see the two clocks.
One card per year. The light band shows the agreement clock (inside or outside the term). The blue band shows the reform clock (level of the benefit). Arrow keys move the choice.
The two clocks in a table, with a benefit of BRL 1,000,000.00 per year and an act valid to 2032
| Year | Agreement clock | Reform clock | Benefit in the year |
|---|---|---|---|
| 2026 | inside the term (until 31/12/2032) | 100% (ADCT, art. 128) | BRL 1,000,000.00 |
| 2027 | inside the term (until 31/12/2032) | 100% (ADCT, art. 128) | BRL 1,000,000.00 |
| 2028 | inside the term (until 31/12/2032) | 100% (ADCT, art. 128) | BRL 1,000,000.00 |
| 2029 | inside the term (until 31/12/2032) | 90% (ADCT, art. 128) | BRL 900,000.00 |
| 2030 | inside the term (until 31/12/2032) | 80% (ADCT, art. 128) | BRL 800,000.00 |
| 2031 | inside the term (until 31/12/2032) | 70% (ADCT, art. 128) | BRL 700,000.00 |
| 2032 | inside the term (until 31/12/2032) | 60% (ADCT, art. 128) | BRL 600,000.00 |
| 2033 | outside (the 31/12/2032 cap has passed) | ICMS abolished (ADCT, art. 129) | BRL 0.00 |
What this example does not model
- The amount of the compensation: it depends on the economic impact, on the deductions in art. 385 and on the limits of the Fund (LC 214, arts. 385 and 391). The example only shows how much of the benefit falls down the art. 128 ladder.
- Benefits outside items I to IV of clause ten, which have their own deadline, and the case of each state, with its act and its conditions.
- Art. 128, paragraph 3, of the ADCT (percentages kept until 31/12/2032) and the registration of each holder with the federal tax authority (RFB).
Illustrative example, with no assessment value. How the benefit is classified, whether it qualifies for compensation and any position on the deadline or the level are decisions for the company with its state. Federal Constitution (ADCT) and EC 132/2023, LC 160/2017 and LC 214/2025 on the Planalto site, and ICMS Agreement 190/17 on the Confaz site.
Categories with a deadline of 31/12/2032 (Agreement 190, clause ten)
Promotion of farming and industrial activity and transport infrastructure (with temples and charities)
Port and airport activity tied to international trade
Commercial activity, when the beneficiary is the real sender
Interstate operations with farm and plant-extraction products in natura
For the ERP, the consequence is plain
The term of each benefit must be stored as a date, and the date must change the calculation by itself: after the validity ends, the rule stops being applied without anyone remembering to switch it off. For the years of reduction, the percentage for each year must be in a table with a validity period, not inside ABAP code.
The tax benefit code on the NF-e: what it checks
The cBenef is the field of the NF-e (Brazil's electronic invoice, model 55) and of the NFC-e (model 65) that reports the code of the tax benefit used in the operation. The state defines the code and publishes it in its own table; Technical Note 2019.001 on the NF-e Portal holds the validation rules that use it. Circular SEF/DIAT 09/2025 of the Santa Catarina state tax authority is an official, clear and checkable description of how these rules work, and it serves as an example of the kind of check a state can turn on (Circular SEF/DIAT 09/2025).
| Rule | What it checks | Practical effect |
|---|---|---|
| N12-85 | Whether the CST reported requires a benefit code and the cBenef field was not filled in. | Invoice rejected when the item has a tax status that depends on a benefit and comes without a code. |
| N12-94 | Whether the cBenef reported matches the CST reported, according to the state's table. | An invalid combination of code and tax status is rejected. |
| N12-98 | Whether the code exists and is in force. | An expired or non-existent code is rejected; the literal text “SEM CBENEF” (Portuguese for “no benefit code”) is not accepted. |
| N12-86 | Whether the CST reported has no benefit code and a code was reported. | A code reported where the table provides none. |
| I05h-10 | Whether, once the presumed credit code (cCredPresumido) is reported, it exists, is in force and is a presumed credit code. | Presumed credit has its own field and code. |
| N14a-10 and N14a-20 | For CST 51 (deferral): if there is a base reduction (pRedBC) greater than zero, the cBenefRBC field is mandatory and the code must match. | Deferral with a base reduction needs the specific code. |
Notes from the circular
Two notes from the circular apply to any project. The first is that the rules were turned on in a test environment before going into production, and the production dates were postponed more than once: the calendar belongs to the state, not to the issuer.
The second is that the cBenef for a presumed credit must not be reported in the cBenef field, because there is a dedicated field. The state tax authority says the codes are in the table of additional assessment information (Table 5.2), available on the authority's own portal.
At issuance
The care needed at issuance is detailed in electronic tax documents in SAP, and the blog article Presumed ICMS credit with no code of its own cannot be proven in 2029 shows what happens to a presumed credit with no code of its own when someone has to prove it years later.
The dates and the states that require the cBenef change often. This analysis therefore does not list who requires it and when, and refers to the table and the notice of the state of the issuing establishment. What does not change is the logic: without the right code, the invoice can be rejected; with the wrong code, the invoice goes through and the benefit has no proof.
How the benefit is born in the SAP calculation: six steps that must exist
A well-set-up benefit comes out of the tax engine without anyone typing anything. The sequence below is a way to think about that path, from the master data to the proof.
The six steps
- 01
Benefit master data
One record per benefit, with the act of origin, type, state, start and end of validity, condition, cBenef, owner and proof document. This is what is missing when the benefit lives only in a spreadsheet.
- 02
Determination in the calculation
State of origin and destination, type of operation, product (NCM), customer or supplier, plant and validity. In SAP, it goes through tax determination and the tax code of the Brazil localization, through condition tables or an external tax engine.
- 03
Calculation and bases
Effective rate, reduced base, exempt or “other” base, deferred tax and proportional reversal. The result must match the rule of the act.
- 04
Document and code
CST, cBenef and dedicated fields (presumed credit, base reduction with deferral) saved on the item, with no manual editing.
- 05
Bookkeeping and assessment
Assessment ledger, SPED and adjustments with the state's adjustment code. The data on the document must reach the ancillary obligation in full.
- 06
Control and proof
Report of use by period, amount relieved, return obligation met and supporting documents kept.
When the tax engine is SAP's own, the benefit lives in determination tables and tax codes; when the engine is external, such as GUEPARDO Tax, it lives in the rules of the engine and SAP receives the result. The exact design depends on the SAP version and on how the company organizes its master data; the description is project logic, not a menu or field of a specific version.
Three traps that show up in almost every environment
Benefit buried in code
An exception programmed for one product and one customer that nobody remembers creating and that stays in force after the act ends.
Benefit with no date
The rule is created and never expires, or it expires in the system while the business keeps selling under the old rule.
Benefit mixed with correction
The tax is wrong, someone adjusts the invoice by hand and the adjustment becomes routine.
All three are governance problems before they are code problems, and SAP tax governance is the place where the owner of each rule is decided: a single owner, with a start date, an end date and an act of origin. Anyone migrating to S/4HANA has an opportunity (to clean up the collection of exceptions) and a risk (to carry everything over unchanged for lack of an inventory).
The inventory is the first serious deliverable. Before designing anything new, the company needs a list of every benefit it uses today, with the act, the state, the products, the period and the amount relieved in the last year.
Read also
Tax Clean CoreTax master dataTax setup in SAPInput with deferred taxThe agribusiness presumed credit fell 10%
Control and proof of use of the benefit: what to keep and who keeps it
For practical purposes, the benefit only exists while the company can prove it. A state audit, an inspection by the destination state, due diligence and the year-end close all ask for the same thing: the act, the condition met, the amount used and the supporting documents.
1. Condition
What the taxpayer has to do or be to qualify: fit the activity, sell a product on the list, have a recipient in a given place, deduct the amount from the price, show the benefit on the invoice. It is the part of the act that the system should check by itself.
2. Return obligation
An obligation taken on in exchange for the benefit: investment, jobs, payment to a fund, keeping an activity going. Agreement 190, clause seven, asks for the fit and the benefit to be specified; the content of the return obligation is in each state's grant act and cannot be assumed.
3. Proof
A document or data that shows the condition was met: an invoice with the required indication, proof that the goods arrived at the recipient, an agreement term, a usage report, a fund payment slip, an expert report.
4. Retention
Proof that exists but cannot be found does not count. The retention period and place must be defined together with the benefit master data, by owner and by period.
Why proof matters for the buyer too
Art. 8 of LC 24/1975 sets out that the tax credit given to the establishment receiving the goods is ineffective. In interstate operations, whoever takes a credit from an origin tax with a questioned benefit also needs to know whether the sender's benefit is regular. Agreement 190, clause fourteen, sets out mutual and unrestricted access by the federal units to electronic tax documents and to the digital tax bookkeeping: matching data between states is part of the picture.
Three simple reports that good control has
Use by period
Lists, by period, the number of invoices and the amount relieved for each benefit.
Invoices with no match
Lists the invoices issued with a benefit but without the matching code, or with a code but without a benefit on record.
Validity about to end
Lists the benefits whose validity ends in the next few months.
All three come out of the ERP itself once the master data is in place.
On another type of credit, the article The CIAP does not stop when the plant stops shows that the calculation keeps running after the operation changes.
ICM Agreement 65/88: condition, proof and loss of the benefit
The text is short and carries, in the same rule, the condition, the proof and the loss of the benefit. Clause one exempts from the tax the outbound sales of domestically made industrial products for trade or industrial use in the Manaus Free Trade Zone, as long as the recipient is based in the municipality of Manaus, excluding weapons and ammunition, perfumes, tobacco, alcoholic drinks and passenger cars (ICM Agreement 65/88).
| Element | What the rule says (clause) | What the ERP needs to have |
|---|---|---|
| Condition | The sender must deduct from the price the amount equal to the tax that would be due, shown expressly on the invoice (one, paragraph 2). | Calculation of the amount relieved and its indication on the document, with no manual editing. |
| Proof | The exemption depends on proof of the actual entry of the products at the recipient's establishment (two). | Control of entry confirmations by invoice, with a status (proven or pending). |
| Exclusions | List of excluded products (one, paragraph 1). | Check by product at the time of determination. |
| Presumed credit | The state of Amazonas is authorized to grant a presumed credit on operations destined for the Free Trade Zone (four). | Treatment different from that of the exemption, with its own field and code. |
| Loss of the benefit | If the goods leave the municipality of Manaus and the other areas covered, the exemption is lost, unless they are processed in the zone (five). | Alert and rule for the later outbound sale. |
The rule in force is confirmed at the current source
The Confaz portal shows that the rule was changed and had clauses repealed with effects suspended by an injunction of the Supreme Federal Court. A spreadsheet copy is not proof that a rule is in force.
What stays outside Agreement 190
Agreement 190 leaves out of its scope the benefits created under art. 15 of LC 24/1975 and art. 4 of Decree-Law 288/1967, based on art. 40 of the ADCT (clause one, paragraph 3), and paragraph 5, added by Agreement 131/22, states the same legal validity for these benefits.
What holds for the Free Trade Zone holds for any benefit: the ERP only delivers what the taxpayer can read on the document and save in a master record.
Ten errors that show up in SAP environments and how to avoid each one
Each item is a failure of master data or of governance, not of one line of code.
Benefit set up as one customer's exception
The benefit should be a rule by product, operation and validity, and it becomes a deviation for one specific customer. When the customer leaves or the act changes, the rule stays.
cBenef typed on the invoice
The code is filled in by hand at billing. The invoice may go through, but the code is not in the master data, and the proof of use does not exist.
Presumed credit code in the wrong field
The Santa Catarina circular separates cBenef and cCredPresumido. Mixing the two causes a rejection or loses the trail of the credit.
Forgotten validity
The benefit ends by act or by deadline (2032 in several categories of clause ten of Agreement 190), but the system keeps applying it.
Percentage inside ABAP code
Changing a percentage depends on a transport and a developer, and the history is lost. The percentage should sit in a table with a validity period.
Benefit with no act
The company uses a benefit out of habit. Nobody knows which law or term supports it, and there is no proof.
Deferral with no closing
The tax was not charged at purchase and the next stage is not controlled. The deferred balance is never closed.
Credit reversal ignored
For benefits that require a proportional reversal or forbid keeping the credit, the tax engine has to handle the reversal, or the credit ends up too high.
Federal benefit mistaken for a state one
Benefits on PIS, Cofins and IPI follow another logic and another legal basis. This analysis covers the state ICMS.
cBenef table with no owner
The state updates the table, and nobody is responsible for updating the ERP master data.
How to run the topic: from inventory to control
Six stages, in this order. Skipping one turns a survey into a new problem.
- 01
Inventory.
List every benefit used in the last year: act, state, type, products, validity, amount relieved and owner.
- 02
Check of the legal basis.
Confirm the act at the official source and check whether there is an agreement or a re-creation under LC 160. Items with no clear answer go to legal review.
- 03
Determination design.
Define the decision key (state, operation, product, recipient, validity) and where each piece of data will be kept.
- 04
Setup and development.
Register the benefit, adjust the calculation and, when the standard does not cover it, develop in ABAP what is missing, with the percentage in a table and the validity in a field.
- 05
Test with real documents.
Issue test invoices for each benefit, compare the amount with the calculation in the act and validate the XML against the state's rules.
- 06
Ongoing control.
Reports of use, of benefits with no code and of validity about to end, and an alert for a change of rule.
In the setup, correct master data is half of the work, and the other half is preventing the data from changing without notice. This takes an owner, a routine and a report, and ancillary obligations and SPED depends on the same data to post without rework.
Official sources and where to find the rule of each state
The path is always the same: from the national rule to the act of the state of the establishment. LC 160 and Agreement 190 set out that each state publishes the list of acts and deposits the documents with Confaz (National Tax Transparency Portal). The granting act, the cBenef table and the notices are published by the state of the issuing establishment, and the Santa Catarina circular is one example. All the legal facts in the analysis come from these sources.
Legislation
- Constitutional Amendment no. 132, of 20/12/2023art. 128 of the ADCT and art. 12 of EC 132/2023 itself (Compensation Fund for Tax or Financial-Tax Benefits). Planalto.
- Complementary Law no. 24, of 07/01/1975arts. 1, 2, 4 and 8. Planalto.
- Complementary Law no. 160, of 07/08/2017arts. 1 to 3 (with the changes by LC 170/2019 and LC 186/2021 noted in the text). Planalto.
Confaz
Read also on the DFSpro blog
Benefit master data with no term fieldICMS compensation fundPresumed credit with no code of its ownElectronic tax documents in SAP
Blog articles on state incentives and credits
Frequently asked questions about state tax benefits and incentives
01What is the cBenef and where does it appear?+
It is the tax benefit code reported on the NF-e (model 55) and the NFC-e (model 65), field cBenef (ID I05f). The 2025 circular of the Santa Catarina state tax authority shows how it works in practice: the validation rules check whether the CST requires a code, and whether the code exists, is in force and matches the CST reported. Each state publishes the table of codes.
02Can the NF-e be rejected because of the cBenef?+
It can. In the Santa Catarina circular, not filling in the field according to the rules leads, among other effects, to rejection of the submission. The same circular states that the literal text “SEM CBENEF” (Portuguese for “no benefit code”) is not accepted and causes a rejection when rule N12-98 is on. The requirement and the dates vary by state, so the rule of the state of the issuing establishment applies.
03Does a presumed credit go in the cBenef?+
Under the rule described by the Santa Catarina tax authority, no: the presumed credit code has its own field (cCredPresumido) and the cBenef for a presumed credit must not be reported in the cBenef field. Each state publishes its table, and the ERP design should follow the table of the state of each establishment.
04Is a tax benefit the same thing as a reduced rate?+
Not necessarily. A rate is a parameter of the operation set by law or agreement for the general case. A benefit is an exceptional treatment that depends on a granting act, on a condition and, often, on the taxpayer or the product fitting a category. The difference matters because a benefit has a term, a return obligation and proof; the general rate, as a rule, does not.
05Does the tax reform end the ICMS benefit?+
Constitutional Amendment 132/2023 sets, in art. 128 of the ADCT, that from 2029 to 2032 the ICMS and ISS rates are reduced by proportions (9/10 in 2029, 8/10 in 2030, 7/10 in 2031 and 6/10 in 2032) and that benefits or incentives on these taxes not covered by that rule are reduced in the same proportion. The compensation fund in art. 12 covers the period from 01/01/2029 to 31/12/2032 for benefits granted for a fixed term and under condition. The design of each case must be read in the rule.
06What happens if I use a benefit with no backing from Confaz?+
Art. 8 of LC 24/1975 sets out, together, the nullity of the act and the ineffectiveness of the tax credit given to the establishment receiving the goods, plus the tax unpaid becoming payable. LC 160 and Agreement 190 created a remission path for old acts that met the publication, filing and deposit requirements.
07Why does the benefit need to be set up in SAP and not only on the invoice?+
Because the invoice is the result of a calculation. If the benefit rule is not born in the calculation (condition, tax code, base, CST, cBenef), the tax amount comes out wrong or the field comes out empty, and manual correction becomes the rule. Besides, the bookkeeping, the assessment and the proof depend on the data already being saved on the document at the time of issuance.
08How do I track the validity and the end of a benefit in the ERP?+
By treating the benefit as master data with a start, an end, an act of origin, a condition and an owner, not as a loose code in a table. End dates come from the granting act and from the limits in LC 160 and Agreement 190; when the act changes, the master data changes within the same deadline. The same care applies to NCM and classification in the tax master data.
09Can the state change the benefit along the way?+
ICMS Agreement 190/17, clause ten, paragraph 2, allows the granting unit to revoke or change the act or reduce its reach before the end date, and paragraph 3 forbids this from producing a bigger benefit than before or removing conditions set in the act in force on 08/08/2017. LC 160, art. 3, paragraphs 4 and 5, has a similar rule.
10Does DFSpro grant or guarantee a tax benefit?+
No. A benefit is a matter of state law and of the taxpayer's fit in the rule. DFSpro works on the tax layer of SAP: a survey of what the company uses, the design of how the benefit is born in the calculation, setup and, when the design calls for it, ABAP development and tax customization.
11Does this article remove the need for a legal opinion?+
No. The content is for information and does not replace an opinion from a lawyer or accountant on your case.
Start with the inventory of your benefits
If your company uses presumed credit, deferral, exemption or base reduction and has no list with the act, the validity and the proof, the conversation starts with that list.
The limit of our role
On this topic, DFSpro surveys the benefits, confirms the backing at the official source, sets them up in SAP and, when the design calls for it, develops in ABAP.
DFSpro does not grant, does not guarantee and does not interpret, in place of legal counsel, the validity of a benefit for your case. The conclusion on the right to the benefit belongs to the taxpayer and its lawyers and accountants.