Learn how Brazil's NF-e system works from an AP perspective. Covers the DANFE vs XML distinction, key tax codes, three-way matching, and automation strategies.
Brazil's Nota Fiscal Eletrônica (NF-e) is the country's mandatory electronic invoice system, and it operates on a principle that catches many foreign AP teams off guard: every tax document must be pre-authorized by the state tax authority (SEFAZ) as a structured XML file before goods can legally ship. The printed document that accompanies most deliveries, known as the DANFE (Documento Auxiliar da Nota Fiscal Eletrônica), is exactly what its name suggests: an auxiliary document. It contains less than 10% of the data embedded in the NF-e XML. AP teams that process only the DANFE are manually transcribing information that already exists in machine-readable format.
That distinction between the DANFE and the underlying XML is the single most important concept for any accounts payable department handling Brazilian vendor invoices. The NF-e XML carries over 500 structured tags governed by more than 400 validation rules, a level of granularity that far exceeds European e-invoicing standards such as Peppol BIS, which uses approximately 100 elements. Every NF-e also carries a unique 44-digit access key (chave de acesso) that allows anyone to verify the document's authenticity directly against SEFAZ records.
Brazil's electronic invoicing program has been operational since 2006-2008, making it one of the longest-running mandatory e-invoicing systems in the world, built on decades of institutional investment including the World Bank and IDB-backed PROFISCO program that modernized state-level tax administration. The results speak for the model's effectiveness. According to the Inter-American Development Bank, the digitization program contributed to a 9.8% increase in tax revenue in participating states and generated public procurement savings of almost one billion reais (over US $177 million) over eight years by enabling reference pricing based on digitized transaction data. The system processes billions of documents annually across every sector of the Brazilian economy.
Yet most English-language content about NF-e is written for companies that need to issue invoices in Brazil. If you are an AP manager at a multinational receiving NF-e from Brazilian vendors, an ERP consultant rolling out a Brazil localization in SAP, Oracle, or Dynamics, or a finance controller evaluating how to automate Brazilian invoice processing, the issuer-side guides leave critical questions unanswered. How do you validate an NF-e you receive? Which XML fields map to your three-way match? What happens when a vendor cancels or corrects an NF-e after you have already booked it?
This guide covers the NF-e system from the receiving side. It walks through the pre-clearance model, breaks down the XML structure and tax codes AP teams encounter most frequently, and addresses the practical challenges of processing, validating, and reconciling Brazilian electronic invoices at scale.
How the NF-e Pre-Clearance Model Works
Brazil's nota fiscal eletrônica operates on a pre-clearance model, meaning every invoice must be validated and authorized by the tax authority before goods can legally leave the warehouse. If you come from a tax system where invoices are filed after the fact, this is the single most important distinction to internalize: in Brazil, the tax authority sits in the middle of every transaction in real time.
The Authorization Workflow
The process starts on the seller's side. Their ERP or invoicing system generates an NF-e as a structured XML document conforming to the current standard (version 4.0). Before transmission, the issuer digitally signs this XML using an ICP-Brasil digital certificate tied to their CNPJ (corporate tax ID), a certificate type known as e-CNPJ. ICP-Brasil is Brazil's national public key infrastructure, and the digital signature serves dual purposes: it authenticates the issuer and guarantees the XML has not been tampered with after signing.
The signed XML is then transmitted electronically to SEFAZ, the state tax authority (Secretaria da Fazenda) in the issuer's registered state. SEFAZ runs the document through more than 400 automated validation checks. These cover everything from structural XML compliance and tax calculation accuracy to cross-references against the issuer's registration status and fiscal standing. The checks happen in seconds.
If validation passes, SEFAZ returns an authorization protocol (protocolo de autorização) containing a unique authorization number and timestamp. This protocol is appended to the NF-e XML, and only at this point does the document become a legally valid fiscal record. If validation fails, SEFAZ returns a rejection code, and the issuer must correct the errors and resubmit. No goods ship, no services are rendered against a rejected NF-e.
For AP teams on the receiving end, this means every NF-e XML you process has already survived rigorous tax authority validation. The authorization protocol embedded in the XML is your proof of that.
Digital Certificate Types
Two certificate formats exist under ICP-Brasil for NF-e signing:
- A1 certificates are software-based files stored on the issuer's server or workstation. They have a one-year validity period and are easier to integrate with automated ERP workflows because no physical device is involved.
- A3 certificates are stored on a hardware token (USB) or smart card and require a physical reader for each signing operation. They carry a longer validity period of three to five years and are considered more secure because the private key never leaves the hardware device.
Both certificate types produce legally equivalent digital signatures. The choice between them is the issuer's, but it has no impact on the XML you receive as a buyer. What matters for AP processing is that the signature is valid and issued under ICP-Brasil, which the SEFAZ authorization already confirms.
Federal and State Coordination
The NF-e system is a joint initiative between Receita Federal (Brazil's federal tax authority, comparable to the IRS) and the individual state SEFAZ offices. Receita Federal defines the national technical standards, XML schema, and validation rules. Each state's SEFAZ operates the infrastructure that receives, validates, and authorizes NF-e documents for issuers registered in that state.
In practice, this means the NF-e your AP team receives from a São Paulo vendor was authorized by São Paulo's SEFAZ, while one from a Minas Gerais vendor was authorized by that state's SEFAZ. The XML format is nationally standardized, but the authorizing authority varies by the seller's state registration. Receita Federal receives a copy of every authorized NF-e for federal tax oversight, creating a unified national database of all electronic invoice transactions.
What This Means for AP
The authorized NF-e XML is the legal tax document. It is not a representation of an invoice or a digital copy of a paper form. The XML itself, bearing the SEFAZ authorization protocol and the issuer's digital signature, is the original fiscal record with full legal standing. The printed document you may receive alongside a shipment (the DANFE) is an auxiliary companion to this XML, not a substitute for it.
DANFE vs NF-e XML: The Data Extraction Gap
Every NF-e generates two artifacts: the XML file and the DANFE. Understanding the difference between them is the key to unlocking efficient Brazilian invoice processing.
The DANFE (Documento Auxiliar da Nota Fiscal Eletrônica) is a simplified printed representation of the NF-e. It exists for one practical reason: to accompany physical goods during transport so that fiscal authorities can verify shipments at checkpoints. The DANFE carries a 44-digit access key, a barcode encoding that key, and a condensed summary of the transaction. It was never designed to be a complete invoice document.
The NF-e XML is the actual fiscal document. It is the legally authoritative record of the transaction, digitally signed and validated by SEFAZ before goods ship.
Here is the problem: the DANFE contains less than 10% of the data in the NF-e XML. Many multinational AP departments receive a printed or scanned DANFE from their Brazilian vendors and process it through OCR or manual key entry, treating it like any other paper invoice. They are manually retyping a fraction of data that already exists in a complete, structured, machine-readable format.
| DANFE | NF-e XML | |
|---|---|---|
| Legal status | Auxiliary document | Authoritative fiscal record |
| Data completeness | Less than 10% of full invoice data | 100% — 500+ structured tags |
| Format | Printed page or scanned PDF | Structured, machine-readable XML |
| Primary purpose | Accompanies goods during transport | Official tax document validated by SEFAZ |
| Machine-readable | No — requires OCR or manual entry | Yes — fields map directly to ERP systems |
| Retention requirement | Must be stored alongside the XML | Must be stored as the authoritative record |
What the XML Contains That the DANFE Does Not
The full NF-e XML delivers a depth of detail that the DANFE simply cannot represent on a single page:
- Complete entity identification — Full legal names, CNPJ numbers, state registration (Inscrição Estadual), and detailed addresses for both the issuer and recipient
- Granular line-item data — Every product or service line includes NCM (Nomenclatura Comum do Mercosul) classification codes and CFOP (Código Fiscal de Operações e Prestações) operation codes that determine the tax treatment of each item
- Unit-level pricing — Exact quantities, unit prices, and discount amounts per line item
- Complete tax breakdowns at the line level — Individual calculations for ICMS, PIS, COFINS, and IPI on every line item, including tax base amounts, rates, and calculated values. The DANFE shows only totals.
- Payment terms and conditions — Installment schedules, due dates, and payment method codes
- Transport details — Carrier information, vehicle plates, freight costs, and shipping modality
- Additional fiscal data — Referenced documents, export declarations, fuel-specific fields (CIDE, ANP codes), and free-text additional information (informações complementares) that often contain contractual references
Why This Matters for Your AP Process
Both the XML file and the DANFE must be stored for the legally mandated retention period (typically five years, though tax disputes can extend this). But the XML is the authoritative record. The DANFE is its companion document for physical logistics — nothing more.
Organizations that collect and process the NF-e XML directly bypass the entire invoice scanning and data capture workflow that plagues DANFE-based processing. There is no scanning step. No OCR interpretation errors on Portuguese tax abbreviations. No manual rekeying of CFOP codes or NCM classifications. The structured XML fields map directly to ERP fields, enabling automated three-way matching, tax validation, and posting without the accuracy loss inherent in converting a printed summary back into data.
If your AP team is currently processing DANFEs, you are running an analog workflow on top of a digital system that Brazil built specifically to eliminate paper-based processing.
Key Fields and Tax Codes Inside the NF-e XML
The NF-e XML is one of the most data-rich tax documents in the world. Every invoice carries structured, machine-readable fields for product classification, transaction type, and tax calculation at the line-item level. For AP teams processing Brazilian invoices, understanding these fields is the difference between automated straight-through posting and manual rework.
CFOP: Transaction Nature Codes
The Código Fiscal de Operações e Prestações (CFOP) is a 4-digit code assigned to every line item on an NF-e. It identifies the nature of the transaction and determines its tax treatment, accounting classification, and whether the goods movement triggers specific tax obligations.
There are over 500 CFOP codes defined by Brazilian tax authorities. The first digit tells you the direction and geography of the transaction:
| First Digit | Meaning |
|---|---|
| 1 | Intrastate purchases (buyer and seller in the same state) |
| 2 | Interstate purchases (buyer and seller in different states) |
| 3 | International imports |
| 5 | Intrastate sales |
| 6 | Interstate sales |
| 7 | Exports |
Within each group, the remaining three digits specify the exact operation. For example, CFOP 1102 indicates an intrastate purchase of goods for resale, while CFOP 2556 indicates an interstate purchase of materials for consumption. AP teams need the CFOP to determine how a transaction should be recorded in the general ledger and which tax rules apply. Getting this mapping wrong means incorrect tax credits and potential audit exposure.
NCM: Product Classification Codes
Every line item on an NF-e carries an 8-digit Nomenclatura Comum do Mercosul (NCM) code. Built on the international Harmonized System (HS), NCM codes classify products down to a granular level. The first six digits follow the HS convention used globally; the last two are Mercosul-specific subdivisions.
NCM codes matter to AP teams for three reasons. First, they drive IPI (federal excise) rates, which vary by product category. Second, customs authorities use NCM codes to validate import declarations against the goods described on the NF-e. Third, NCM data enables spend analysis and product category reporting across suppliers without relying on inconsistent vendor descriptions.
CST: Tax Situation Codes
Código de Situação Tributária (CST) codes appear at the line-item level for each major tax type. They indicate the tax situation of the item: whether it is fully taxable, exempt, zero-rated, subject to tax substitution, or eligible for a reduced base.
There are separate CST code sets for each tax:
- ICMS CST — A 3-digit code (origin digit + 2-digit situation code). For example, CST 00 means fully taxable at the standard rate, CST 20 means taxable with a reduced base, and CST 40 means exempt.
- PIS CST and COFINS CST — 2-digit codes ranging from 01 (taxable at the basic rate) through codes for zero-rated, exempt, suspended, and other special situations.
CST codes are critical for accurate accounting because they determine whether your organization can claim tax credits on a given line item. A system that ignores CST values and applies a blanket tax rate will either overstate liabilities or claim credits it is not entitled to.
Major Tax Types in the NF-e XML
Four taxes appear on virtually every goods-related NF-e. The XML contains the base amount, rate, and calculated tax value for each at the individual line-item level.
| Tax | Full Name | Scope | What AP Teams Should Know |
|---|---|---|---|
| ICMS | Imposto sobre Circulação de Mercadorias e Serviços | State-level tax on goods and certain services | Rates vary by state, product, and transaction type (intrastate vs. interstate). Interstate rates are 4%, 7%, or 12% depending on origin/destination states and product origin. Intrastate rates range from 7% to 35%. |
| PIS | Programa de Integração Social | Federal social contribution | Standard cumulative rate of 0.65% or non-cumulative rate of 1.65%, applied to revenue. PIS credits on purchases are available under the non-cumulative regime. |
| COFINS | Contribuição para o Financiamento da Seguridade Social | Federal social contribution | Standard cumulative rate of 3% or non-cumulative rate of 7.6%. Follows the same cumulative/non-cumulative regime logic as PIS. |
| IPI | Imposto sobre Produtos Industrializados | Federal excise tax on manufactured goods | Rates vary widely by NCM code, from 0% to over 300% for certain products (tobacco, beverages). Applies when goods leave the manufacturer or at import. |
Each line item in the XML nests these tax calculations inside dedicated element groups, with separate fields for the taxable base (vBC), the applied rate (pICMS, pPIS, etc.), and the resulting tax amount (vICMS, vPIS, etc.). Document-level totals aggregate these values across all line items.
Every code, rate, and calculated value described above exists as a named, structured field in the NF-e XML. Systems capable of NF-e data extraction can parse CFOP classifications, NCM product codes, CST tax situations, and fully itemized tax calculations directly, validating them against expected values and posting to ERP tax accounts without manual interpretation.
Processing NF-e on the Receiving Side
Brazilian tax law places a clear obligation on the buyer: you must collect, validate, and archive the NF-e XML for every inbound transaction. This is not a best practice or an optional enhancement to your AP workflow. It is a legal requirement enforced by SEFAZ, and failure to comply exposes your organization to fines and audit risk. What makes this obligation strategically interesting for AP teams is that it simultaneously creates one of the strongest data extraction opportunities in global invoice processing.
Because the NF-e XML arrives with fully structured line items, quantities, unit prices, ICMS/IPI/PIS/COFINS tax calculations, and vendor identification (CNPJ), it enables automated three-way matching in high-volume environments that would be impossible with unstructured invoice formats. The matching logic is straightforward: your system compares the purchase order against the NF-e XML line items, then confirms quantities against the goods receipt. Since the XML fields are machine-readable and standardized across all Brazilian vendors, this matching can happen programmatically — and critically, it can begin before physical delivery occurs, because the NF-e is authorized by SEFAZ before the goods ship. Your AP team can identify PO mismatches, pricing discrepancies, or missing line items before goods arrive at the dock, turning what is typically a post-delivery reconciliation into a pre-delivery validation.
Straight-through processing becomes achievable for routine, matching transactions. The sequence runs from NF-e XML receipt through schema validation, PO matching, goods receipt confirmation, GL posting, and payment scheduling without manual intervention at any step. Industry benchmarks suggest that end-to-end NF-e automation can reduce Brazilian invoice processing costs by 70% or more. For transactions where the NF-e XML matches the PO within defined tolerances, human review adds cost without adding value.
The volume reality in Brazil makes automation essential rather than aspirational. Large manufacturers, distributors, and retail chains routinely receive 20,000 or more NF-e documents per month from their supplier base. At that scale, manual validation and data entry is not just expensive — it is physically impractical. Even mid-sized operations with a few thousand monthly NF-e documents find that manual processing creates bottlenecks in month-end close, delays payment term optimization, and increases the risk of duplicate payments or missed tax credits.
The practical challenge most AP teams face is format fragmentation. Not every vendor sends the NF-e XML directly. Some transmit only the DANFE — often as a scanned PDF or a photo taken on a warehouse floor during goods receipt. Your AP team ends up managing two parallel workflows: one for structured XML files and another for unstructured scanned documents. This dual-track approach doubles the process complexity and creates reconciliation gaps where documents in one format are handled differently from documents in the other.
An AI-powered invoice data extraction platform that handles both structured XML and scanned documents in the same batch eliminates this fragmentation. AP teams can run a single extraction job across all inbound Brazilian documents, whether they arrive as NF-e XMLs or photographed DANFEs, and produce a unified structured output that feeds directly into ERP matching and posting workflows. One consistent process, regardless of how each vendor transmits their fiscal documents.
Cancellation, Correction, and Contingency Rules for AP
An authorized NF-e is not necessarily a final document. Brazilian tax law provides several mechanisms for modifying or voiding an electronic invoice after SEFAZ has approved it, and each one creates specific obligations for the receiving side. AP teams that process NF-e need clear procedures for handling cancellations, corrections, and complementary invoices to avoid booking errors and compliance exposure.
Cancellation (Cancelamento)
An issuer can cancel an authorized NF-e within 24 hours of authorization, provided the goods have not yet left the establishment. Once cancelled, the NF-e retains its access key but carries a cancellation event that renders it fiscally void. SEFAZ publishes the cancellation event, and any query against that access key will return the cancelled status.
Under the 2026 tax reform framework, penalties tighten considerably for late cancellations:
- Cancellation after the taxable event has occurred carries a fine of 66% of the tax due
- Cancellation after the legal filing deadline carries a fine of 33% of the tax due
For AP teams, the obligation is straightforward but time-sensitive. If you have already posted an NF-e that is subsequently cancelled, you must reverse the booking entirely: undo any goods receipt, AP accrual, and tax credit entries tied to that document. Monitoring cancellation events against your posted NF-e inventory should be part of your daily or weekly reconciliation cycle. Paying a cancelled NF-e creates a recoverable payment problem and a tax credit that no longer has a valid supporting document.
Carta de Correção Eletrônica (CC-e)
The Carta de Correção Eletrônica is an electronic correction letter that allows the issuer to fix minor errors on an already-authorized NF-e. A CC-e is linked to the original NF-e by its access key and becomes part of the document's event history in SEFAZ.
What a CC-e can correct includes descriptions, NCM classification codes, weight or measurement details, and similar non-financial data. What it cannot change is critical for AP validation:
- Monetary values (product prices, freight charges, totals)
- Tax amounts (ICMS, IPI, PIS, COFINS calculations)
- CNPJ numbers of either party
- CFOP codes (which determine the fiscal nature of the operation)
When your system detects a CC-e event against a posted NF-e, review the correction details. Most CC-e changes will not affect your financial postings, but they may require updates to item master data, product descriptions in your ERP, or compliance records. The original NF-e XML remains unchanged; the CC-e is a separate event record that supplements it.
Complementary NF-e (NF-e Complementar)
When values, quantities, or tax calculations on the original NF-e were understated, the issuer cannot simply correct them with a CC-e. Instead, they issue a Complementary NF-e, which is a second, fully authorized NF-e that references the original document's access key. The complementary document contains only the difference: the additional value, quantity, or tax amount that was missing from the original.
This mechanism is commonly used when tax rates were applied incorrectly, when freight or insurance costs were omitted, or when unit prices were understated. The Complementary NF-e goes through the same SEFAZ authorization process as any standard NF-e and carries its own unique access key.
AP teams must match each Complementary NF-e back to its original transaction. The referenced access key in the complementary document identifies which original NF-e it adjusts. Your three-way match process needs to account for the combined total of the original plus any complementary documents when reconciling against the purchase order and goods receipt. Failing to capture a Complementary NF-e means understated AP liabilities and incomplete tax credit records.
Contingency Modes (EPEC and SVC)
When the primary SEFAZ server is unavailable due to maintenance or technical failure, issuers still need to conduct business. Brazilian tax infrastructure provides two backup channels:
EPEC (Evento Prévio de Emissão em Contingência) allows the issuer to register a summary of the NF-e with the National Environment before transmitting the full XML. This creates a legally valid pre-authorization that permits goods to ship. The full NF-e must be transmitted to the primary SEFAZ within 24 hours of the system coming back online.
SVC (Servidor Virtual de Contingência) routes the complete NF-e through an alternate SEFAZ server. The document is fully authorized by the backup server and is legally valid from the moment of authorization. Once the primary SEFAZ recovers, synchronization happens automatically between the servers.
NF-e issued under either contingency mode will carry specific indicators in the XML identifying the issuance method. AP teams encountering these indicators should treat the documents as legally valid. The key operational consideration is that an EPEC-issued NF-e may initially lack the full XML detail you need for posting. If your extraction process encounters an EPEC pre-event without the corresponding full NF-e, flag it for follow-up rather than rejecting it outright. The complete document should arrive once the issuer transmits to the recovered SEFAZ.
The common thread across all four mechanisms is active monitoring. Cancellations require reversals. CC-e events require record updates. Complementary NF-e require matched postings. Contingency-mode documents require patience and follow-up. Building these checks into your nota fiscal eletrônica processing workflow prevents compliance gaps from accumulating silently.
Other Nota Fiscal Types and the 2026 Tax Reform
The NF-e covers goods transactions, but AP teams working with Brazilian suppliers will encounter several other electronic fiscal document types depending on the nature of the purchase.
NFS-e (Nota Fiscal de Serviços Eletrônica) is the electronic service invoice, governed at the municipal level rather than by SEFAZ. Each of Brazil's 5,570+ municipalities historically maintained its own NFS-e format and web service, creating significant complexity for AP teams processing service invoices across multiple cities. The federal government has been working to standardize NFS-e through a national system, but adoption remains uneven.
NFC-e (Nota Fiscal de Consumidor Eletrônica) handles B2C retail transactions. It shares the same XML layout as the NF-e, making it technically familiar, but it serves a different purpose and rarely appears in B2B accounts payable workflows.
CT-e (Conhecimento de Transporte Eletrônico) is the electronic freight document issued by carriers and logistics providers. AP teams that manage inbound freight costs need to process CT-e documents alongside the NF-e for the goods themselves, matching transport charges to their corresponding shipments.
Brazil has also proposed the NFB-e (Nota Fiscal Brasil Eletrônica), which aims to unify all electronic fiscal document types under a single national framework. Progress has been incremental, but the direction is clear: consolidation and standardization across document types.
The CBS/IBS Tax Reform and What It Means for NF-e Processing
Brazil's sweeping tax reform, detailed in how Brazil's 2026 tax reform changes NF-e invoices, introduces two new value-added taxes that will fundamentally reshape the NF-e XML schema. CBS (Contribuição sobre Bens e Serviços), a federal tax, and IBS (Imposto sobre Bens e Serviços), a combined state and municipal tax, will gradually replace five existing taxes: PIS, COFINS, ICMS, ISS, and IPI. The transition period runs from 2026 through 2033, with the legacy taxes being phased out incrementally as CBS and IBS ramp up.
For AP teams, the most immediate consequence is an expanded NF-e XML schema. New fields for CBS and IBS tax calculations are being added alongside the existing ICMS, PIS, and COFINS groups. During the transition years, invoices will carry both legacy and new tax fields simultaneously, meaning extraction systems must parse and validate a significantly larger set of tax data per document.
The reform also introduces a split payment mechanism that requires real-time tax calculation and payment splitting at the point of transaction. Rather than the supplier simply reporting tax amounts for the buyer to post, the system will direct tax portions to government accounts during payment settlement. This changes how NF-e total values are computed and how AP teams reconcile what they owe the supplier versus what flows directly to tax authorities.
The dual-compliance period creates a practical challenge: AP posting logic, tax validation rules, and ERP tax code tables all need to support two overlapping tax regimes for up to seven years. Organizations that already process NF-e XML programmatically hold a meaningful advantage here. Updating field mappings and adding new tax code structures to an automated extraction pipeline is a defined technical task. Teams still relying on manual DANFE-based data entry face the harder problem of retraining staff on an entirely new tax framework while still maintaining accuracy on the legacy one.
AP teams should begin preparing now by auditing their current NF-e field mappings, confirming that their extraction and ERP systems can accommodate schema expansions, and establishing test procedures for documents that carry both CBS/IBS and legacy tax fields. The organizations that treat this as an integration project rather than a compliance scramble will navigate the transition with far less disruption.
Related Articles
Brazil CFOP and NCM Codes: A Practical Guide for Invoice Recipients
Learn how to decode CFOP and NCM codes on Brazilian invoices. Practical reference tables and structural breakdowns from the invoice recipient's perspective.
Brazil ICMS Invoice Guide: Rates, ICMS-ST & Credit Recovery
How ICMS works on Brazilian invoices: interstate vs intrastate rates, ICMS-ST, DIFAL, credit recovery rules, and NF-e field validation for AP teams.
Brazil NFS-e: Understanding 5,500 Municipal Service Invoice Systems
Guide to Brazil's NFS-e: how 5,500+ municipalities each operate their own service invoice system, the ISS tax, and the national SNNFS-e standard.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.