Simulating tax filings with AI before you transmit

Inove Labsapplied research: built and measured before we recommend it

Statutory tax filings are submitted in the dark. The company closes the period, generates the file, transmits it — and finds out whether it was right weeks or months later, when tax audit screening, a formal notice or a request for amendment arrives. The distance between the error and the news of the error is what makes an ordinarily small problem expensive.

The question that matters is not “how do we automate the submission”. It is how do we know, before transmitting, what the tax authority will reject — and what it will accept but later cross-check against other information of yours.

In one sentence — AI does not interpret the law for you; it turns written rules into executable tests, generates the edge cases nobody remembers and explains the rejection — so that filing stops being a bet and becomes a rehearsal with a known outcome.

Why simulate rather than merely validate

Layout validators already exist and are useful: they check that the file has the fields, the types and the totals the layout requires. But most of what causes trouble passes through them without complaint.

The file can be formally perfect and still carry the wrong tax treatment, a sequence inconsistent with the previous period, or a total that does not match another filing the same company has already submitted. The tax authority cross-checks — and it is in the cross-check that the bill appears.

To simulate is to run the filing against the entire set of checks before transmitting: those of the layout, those of the tax rules and those of consistency with the history and with the other filings. The goal is not to pass the validator. It is to have no surprises later.

The five layers of simulation

Layout. Mandatory field, type, length, totaliser. It is the cheap layer and the only one most companies run today. It should remain code, not a model.

Tax rules. Does the treatment applied to each item match what the operation requires? This is where CFOP (the Brazilian tax operation code), CST (the tax status code), base, rate, tax relief and the effective date of each come in — and effective dates are where most errors happen.

Consistency with the history. Does this month’s filing resemble those of previous months? A sudden drop in one tax, an item that vanished, a branch that stopped appearing: none of that is an error by definition, but all of it is a question someone should answer before transmitting.

Cross-checks between filings. What you declare in one submission has to reconcile with what you declared in another. The tax authority runs that cross-check; running it first simply means getting there first.

Evidence. What was tested, with what result, who approved the transmission. Without this layer, the rehearsal helps once and protects you no further.

Where AI changes the economics

The simulation itself is made of deterministic checks — and it should stay that way. What was ever expensive was not running the checks: it was writing and maintaining them. That is exactly where AI changes the arithmetic.

From legal text to executable test. Every rule change arrives as text: a technical note, a ruling, a new layout manual. An assistant reads the change and returns a proposed check — which field it touches, which condition to test, from which date it applies. The specialist reviews and approves in minutes, instead of translating everything from scratch.

Edge cases nobody remembers. Partial returns, supplementary invoices, an operation with tax relief that expired mid-period, an item with two codes over the course of the year, a cancellation outside the deadline. The AI generates the list of scenarios worth testing — and the list is always longer than the one you draw up from memory.

Explaining the rejection. The tax authority’s response is usually a code and a short sentence. With the rejected record in hand and the history of similar rejections, the assistant points to what probably caused it and where to look.

Comparing period against period. That consistency layer is, in practice, anomaly detection — and it is work AI does well: describing in plain text what changed relative to previous months and why it stands out.

Watch out — AI does not decide tax treatment, and no assistant signs a statutory filing. Four limits worth writing into the procedure: every proposed rule is reviewed by whoever answers for tax before it becomes a test; the simulation never transmits — it produces a report; the effective date of each rule is treated as mandatory data, because the right rule on the wrong date fails just the same; and the AI is not a source of legislation — the source is the official text, and the AI helps you read it. A language model describes regulation with convincing fluency, including when its description is wrong.

2026 is the year this stops being optional

The Brazilian Tax Reform brings a period in which two regimes coexist: the old one remains in force while the new one comes in. In practice, that means calculating twice, declaring in different formats and reconciling both — with a team that is already stretched to the limit closing the month.

Dual coexistence is precisely the scenario in which simulation stops being a refinement and becomes a necessity. There is no shortcut: those who only discover errors through the tax authority’s response will discover them twice over.

There is also the platform change. Anyone still issuing through GRC NFE (the legacy SAP add-on for Brazilian electronic invoicing) needs to migrate to SAP DRC before configuring the Reform — maintenance of the old platform has ended, and the adaptations to the new legislation arrive through the new one. Configuring the platform on its way out is work you do twice.

How we build this in practice

Inventory the filings. Which ones, at what frequency, who prepares them, who transmits them, what has been amended in the past year. The list of amendments is usually the best map of where the problems are.
Pick one. The one that causes the most rework, not the easiest one. A single well-covered filing teaches the pattern for the rest.
Turn rules into tests. With AI support for the drafting and mandatory human review. Every test is born with an effective date.
Run it against the past. Simulate periods already submitted. If the simulation does not find the errors you know occurred, it is not ready yet.
Move it into the close. The simulation now runs before transmission, and the report becomes an item on the closing checklist — with an owner and a deadline.

What changes for the tax team

The error appears while it is still cheap. Correcting before transmitting costs an afternoon; correcting afterwards costs an amended filing, and sometimes a fine.

The discussion moves up a level. The team stops checking the file line by line and starts analysing the exceptions the simulation flagged.

The knowledge stays. A tax rule that lived in the head of whoever runs the close becomes a test with a name, a date and a justification — and it keeps working after that person moves to another area.

Audits get shorter. Showing that a verification process exists, with evidence from every cycle, changes the nature of the conversation with the tax authority and with the auditor.

The honest limit: simulation does not fix data that was wrong at source. If the invoice came in with the wrong treatment, the filing will reflect that — the simulation merely warns you first. That is why this workstream runs alongside incoming invoice validation: one looks after the data coming in, the other after the data going out.

To go deeper, the Inove Academy has the e-book on Brazilian Tax Reform and SAP, with the calendar and what to prepare at each phase, plus the quick guide to coexistence — which deals precisely with the period in which both regimes run at the same time.