In 2026 Brazil’s tax reform enters its test phase: the two new consumption taxes appear on fiscal documents, at symbolic rates, and are not collected. The year is informative.

That sounds like slack, and it is the opposite. What a company declares without paying is exactly what gets recorded without the filter of someone checking an amount due. It is the material that will be read later — when the discussion is no longer a test.

And “later” is not a figure of speech. A dispute over a 2026 document can be judged in 2031, with the case running for years. The question that arrives on that date is not what the rule is today. It is: what did your system apply on that day, and why?

Proof requires three things, and nobody keeps all three together

To demonstrate how a number came out, you need, at the same time:

The document. Everybody keeps this one. It is the easy part, and it is the part that gives a false sense of coverage.

The rule in force on that date. This lives outside the system — in legislation, in technical notes, in the tax team’s interpretation. There is rarely a link between “this document” and “the version of the rule that applied when it was issued”.

The version of the parameter that produced the number. This is the one that gets lost. Rate tables, decision rules, custom code, an external tax engine — all of it changes over the years, and much of it changes in place, leaving no previous state.

Keeping the document without the other two lets you show the result. It does not let you show the derivation — and the derivation is what a dispute is about.

The overwritten-parameter trap

Tax systems usually have validity dates on rate tables — and that creates the impression that history is taken care of. It is not, because the calculation rarely comes only from them.

It also goes through decision rules, through custom code written to handle a business exception, through master data — the product classification, the customer’s regime, the nature of the operation — and, in many companies, through an external tax engine with its own knowledge base, updated by the vendor.

None of those layers keeps versions by default. The practical result is familiar: you can reproduce today’s calculation, and not the one from two years ago. When somebody asks why that item was taxed that way in 2026, the honest answer tends to be “because the system was configured like that” — and that is not an answer.

It is worth remembering that at volume, the origin of the number is almost never the calculation: it is the master data. A classification error repeats on every document for that product, silently, until tax determination — the mechanism described in wrong tax classification in the product record.

Coexistence doubles everything, for years

Until the old system is fully extinguished, both regimes coexist. In practice, for IT, that means three things that accumulate:

Every document carries both calculations. What was already complex now exists in two simultaneous versions, with rules evolving at different speeds.

Every change needs a date. Changing is not enough: you have to know from when it applied, and what applied before. A change with no date is history lost.

The retention window outlives the system. The environment that did the maths may have been upgraded, migrated or replaced before the discussion arrives. That is why archiving with a retention rule stops being a disk-space subject and becomes a defence requirement — we cover that in SAP archiving.

What goes wrong, by name

Decommissioning the legacy too early. It is the temptation after a successful migration: the old environment is expensive and nobody uses it. It has stopped being a system and become evidence — and its deadline is not the project’s.

Migrating without bringing over the calculable history. Bringing the documents is the minimum. If the new platform cannot reconstruct how the number came out on the old one, the history has become readable dead storage, not evidence.

Treating a screenshot as proof. A screen image shows the result and supports no question at all about derivation.

Assuming the document file is enough. It records what was declared, not how it was reached. It is the result, not the path.

Leaving custom code unversioned. It is the most frequently forgotten layer and the one that most decides the number in companies with specific operations.

What this is not

Worth being explicit: none of this is tax advice. Reading the rule, the classification and the defence strategy belong to the tax and legal teams, and that is where this conversation starts.

The IT work is different, and complementary: making sure the system can demonstrate what it did. When the tax team needs to sustain an interpretation, they will need the evidence — and it either exists from the moment of issue, or it is not manufactured afterwards.

The honest limit

Being able to prove the calculation does not win the dispute. It wins the possibility of having the dispute with data instead of memory — which is different, and rather less than we would like to promise.

It is not free either. Versioning parameters, dating changes and retaining environments with a rule costs disk, licences and discipline, and that cost lands before the benefit — which may never be claimed, if the dispute never comes. It is an insurance policy, and a policy is judged by the size of the risk, not by the premium.

And there is a limit of scope: this deals with what the company can show. It does not correct what was calculated wrong. If the master data was wrong, keeping the evidence well only documents the error better — which is why the order is find first, keep second.

If the starting point is understanding what the environment does today before changing anything in it, begin with the IT diagnostic. For the overview of what the reform demands from IT, see Brazilian tax reform and SAP. And if issuing still depends on the old platform, the path is the SAP NFE to DRC migration.

Frequently asked questions