contato@taxup.com.br   São Paulo · Rio de Janeiro · Brasília
PT EN
NF-e · LAYOUT 4.00 · TECHNICAL NOTES · NF-e · ERP · SAP · IBS · CBS

NF-e keeps layout 4.00.
Reform arrives through Technical Notes.

Brazilian NF-e keeps layout 4.00, updated through current Technical Notes. Article 116, II, of CGIBS Resolution 6/2026 requires issuers to follow the technical documentation for each fiscal document. HQ should distinguish tax requirements, XML versions and evidence of ERP testing.

Published · Updated · 8 min read

An authorized Brazilian invoice can still carry an incorrect tax classification. Layout 4.00 and its Technical Notes define the document structure; the local tax team must substantiate its content. CGIBS Resolution 6/2026 requires adherence to technical documentation in Article 116, II, and distinguishes authorization from validation of the information in Article 132, I. Headquarters needs evidence of both system delivery and the expected tax outcome.

01

What changes within the same layout

Document version and field updatesLayout 4.00 receives field and validation changes through Technical Notes. The Technical Note version is a separate identifier.NF-e layout: 4.00NT 2025.002 v1.51IBS/CBS/IS fields and rulesDifferent identifiers serve different purposes.
The Technical Note number does not itself change the layout version.

The MOC 7.00, Annex I, field A02 identifies layout version 4.00. The number 7.00 belongs to the taxpayer guidance manual. NT 2025.002 v1.51, introduction and layout section addresses changes for IBS, CBS and the Selective Tax. Keep these identifiers separate in the delivery inventory.

Tax groups and classification fields, including CST and cClassTrib, must be connected to the actual transaction. A field being available does not establish that the tax applies to a particular sale. Ask the Brazilian team to connect the business facts, the approved tax position, the expected calculation and the transmitted fields, with the relevant conditions and exceptions.

This guide concerns adaptation and acceptance. Detailed tags and rules belong to the NF-e layout and NT 2025.002 guide in Portuguese; code selection and maintenance are addressed in the cClassTrib classification guide in Portuguese. These technical references can support the local team without duplicating their scope in the HQ project brief.

02

Separate three calendars in the programme

A deadline becomes actionable when its source, object and owner are identified.
LayerReferenceManagement decision
Constitutional transitionADCT, Articles 125–129Which tax scenarios need to coexist in each period?
Fiscal documentAct and Technical Note for that documentWhich rule, version and environment apply?
ERP and interfacesInstalled release and vendor documentationWhat must be configured, tested and demonstrated?

The ADCT, Articles 125–129, introduced by Constitutional Amendment 132/2023, provides the transition: a 2026 stage; CBS and Selective Tax from 2027; ICMS/ISS reductions during 2029–2032; and abolition of those two taxes in 2033. These are not a single XML rejection or ERP delivery deadline. Article 125, paragraph 4, links possible relief from collection to ancillary obligations and complementary legislation.

For each flow, record the document type, taxpayer regime, transaction, validation rule, test or production environment, published version and application date. NF-e, NFC-e, NFS-e and CT-e should not automatically inherit the same milestone. The wider business transition belongs to the Brazilian Tax Reform guide.

At the review date, 14/09/2026, the official SVRS catalogue listed NT 2025.002 v1.51 and subsequent changes, including NT 2026.009 v1.00. Before deployment, the project must check the current package applicable to its transactions. A version cited in an executive guide cannot replace that release check.

03

Why authorization does not close the tax review

Two kinds of evidence for one transactionThe authorization protocol records permission to use the document. Comparing facts, rules and calculations checks its tax content. Both forms of evidence matter.Transmitted documentProtocol: authorization of useScenario: rule and calculationComplementary checks.
Article 132, I, of CGIBS Resolution 6/2026 separates authorization and validation of information.

In their 6 August 2026 clarification, RFB and CGIBS explained that postponing validation and rejection rules did not suspend the duty to report CBS/IBS information. The measure aimed to preserve billing continuity. Read its scope alongside the acts and rules for the relevant document; it does not establish that every field is optional throughout the year.

A hypothetical example: a sale produces an accepted XML, but the master data used in the calculation corresponds to a different transaction. The protocol demonstrates authorization; it does not determine whether the tax classification was appropriate. The useful test compares documented business facts, the approved tax position and the values actually transmitted and posted.

Articles 132, I, and 147 of CGIBS Resolution 6/2026 preserve that distinction and the responsibility of the issuer for accuracy. The example does not presume an automatic penalty, credit loss or correction procedure: those consequences depend on the facts and applicable rules.

04

Allocate deliverables between HQ and local teams

Recommended contracting structure; actual responsibilities depend on the agreed scope.
OwnerDeliverableExpected evidence
Brazilian Tax and advisersTax position and expected resultTransaction, legal basis, assumptions and exceptions
Integrator and ITConfiguration and integrationReproducible version, change, XML and response
Accounting and business ownersActual process verificationDocument reconciled to posting and business event
Local management and HQ sponsorProduction decisionKnown issues, assigned owners and recorded acceptance

The budget should follow the inventory: establishments, document types, transactions, tax regimes, interfaces and custom code. A reviewable statement of work identifies these assumptions, the environments to be used and the owner of each type of discrepancy. Price and duration should follow that assessment, rather than the commercial name of the ERP.

The TaxUp team can translate tax positions into verifiable requirements and assess the evidence produced. The integrator executes the contracted technical changes. This is a governance recommendation, not a legal requirement to buy independent validation or a certification of compliance. HQ should agree how unresolved interpretations and technical defects reach the decision maker.

For an English-language SAP decision path, begin with the Brazil Tax Reform and SAP executive guide, continue with the GRC NFe-to-DRC transition, and use the independent SAP tax validation service page to frame scope, evidence and acceptance.

For SAP environments, the next decision is covered in the SAP architecture and sequencing guide in Portuguese. The detailed scenario workbook remains with the ERP and SaaS tax testing guide in Portuguese. Platform choices should be assessed against demonstrated capabilities and business requirements.

05

Connect configuration to documented acceptance

Recommended test traceabilityStart with the transaction and expected tax result, check XML and response, reconcile the posting, then record acceptance or an outstanding issue.Transaction and expected resultXML and authorization responsePosting and reconciliationAcceptance or recorded issueTaxUp governance recommendation.
Each stage should refer to the same transaction and the version actually tested.

Begin with the flows that affect issuance, incoming documents and accounting records. For each scenario, retain the input data, selected rule, expected result, XML, response and postings. Include relevant exceptions, such as returns or cancellations, where they occur in the business. Explain coverage in terms of risk and operations.

After fixing a defect, reproduce the scenario and check affected processes. Distinguish a technical failure, inappropriate master data and a disputed tax interpretation. Counting completed tests does not demonstrate coverage. An unresolved issue affecting billing needs an owner and an explicit decision before the change.

Bookkeeping and reporting require their own inventory of obligations, acts, manuals and versions. A new fiscal document is not a sufficient basis for removing an existing reporting obligation from the project. Tax compliance work connects issuance, records, reconciliation and review of the rules relevant to the company. Ask for a clear account of what has and has not been tested.

06

Prepare a reviewable scope before commissioning work

Assessment inputs and the decisions they support.
InputPurpose
ERP, issuer and interface inventoryIdentify dependencies and technical owners
Transaction and tax-regime matrixDefine rules and exceptions requiring tests
Sanitized XML and test resultsCompare expected and actual outputs
Version and issue registerAgree scope, remediation order and acceptance evidence

The expected review output is a requirements and scenario matrix, explained discrepancies and acceptance criteria. The proposal should identify covered documents, exclusions, dependencies on the integrator and decisions retained by the client. Share only necessary information through the agreed protected channel.

This factual review has a cutoff of 14/09/2026. A new Technical Note, act, tax regime or issuer release may require scenarios to be reopened. The technical starting point is the official NF-e/SVRS catalogue; legal conclusions require the applicable provisions. A company-specific review closes the questions an executive guide cannot settle for its actual operations.

07

References and official sources

Define the tax review scope for your ERP

The TaxUp team assesses transactions, requirements and evidence to scope a tax review alongside the contracted technical provider.

Discuss the review scope
08

Frequently asked questions

Must layout 4.00 be abandoned because of the Reform?
MOC 7.00, Annex I, field A02, identifies layout 4.00. Reform adaptation follows applicable Technical Notes, such as NT 2025.002. Check the current schema package, fields and rules for the transaction, keeping manual, layout and Technical Note versions separate.
Does postponing rejection allow us to stop adaptation?
The RFB/CGIBS clarification of 6 August 2026 explains that postponing rejection did not suspend the duty to report IBS/CBS. Check the rule for the relevant document and continue the required adjustments. Relaxing particular validations is not a general reporting exemption.
How should HQ estimate adaptation cost and duration?
Start with document types, transactions, establishments, interfaces, custom code and data issues. Separate integrator delivery from tax review. Require assumptions, deliverables and acceptance criteria in the proposal; the ERP brand alone does not determine price or duration.
Does an authorized XML prove that the tax is correct?
Not by itself. Article 132, I, of CGIBS Resolution 6/2026 distinguishes authorization from validation of information; Article 147 retains the responsibility of the issuer for accuracy. Classification, calculation and reconciliation need their own evidence.
TECHNICAL AUTHORSHIP

TaxUp Tax Practice

Brazilian Tax Law

Content produced by the TaxUp technical team and reviewed by a senior consultant before publication. Meet the firm →

Bring this analysis to your company’s case

30 minutes with a senior consultant. We map your specific tax scenario and point out the technical path forward — no obligation.

Book a diagnostic
Book a diagnostic