NF-e Nota Fiscal Brasileira
Extração de XML para Excel

A Armadilha do DANFE: Por Que a Maioria das Equipes de AP Internacionais Está Processando o Documento Errado

Quando uma remessa chega de um fornecedor brasileiro, o motorista entrega um documento impresso com um código de barras e um número de 44 dígitos no canto superior direito. Este é o DANFE — Documento Auxiliar da Nota Fiscal Eletrônica — e a palavra "auxiliar" em seu nome não é decorativa. Ele existe para um único propósito: acompanhar mercadorias físicas durante o transporte, para que as autoridades fiscais em postos de fiscalização rodoviária possam escanear o código de barras e verificar a remessa. Ele nunca foi projetado para ser uma fatura completa.

No entanto, para a grande maioria das equipes de AP internacionais que recebem mercadorias brasileiras, o DANFE é a fatura. Ele é escaneado, submetido a OCR ou digitado manualmente no ERP. A chave de acesso de 44 dígitos é copiada — diligentemente, todos os 44 dígitos — em um campo chamado "Número da Fatura". E então o funcionário de AP passa para o próximo documento, sem saber que, para cada fornecedor, para cada remessa, a fatura completa já existe em um formato XML legível por máquina que o governo brasileiro exige que o vendedor gere, assine digitalmente com um certificado ICP-Brasil e envie à SEFAZ (a Secretaria da Fazenda estadual) antes que as mercadorias pudessem legalmente sair do armazém.

A escala da perda de dados não é marginal. O DANFE imprime um resumo condensado — nome do fornecedor, nome do comprador, data, itens com quantidades e preços unitários, e um total geral. O XML da NF-e, regido por mais de 400 regras de validação automatizadas executadas pela SEFAZ no momento da autorização, contém mais de 500 tags estruturadas na atual versão 4.0 do layout, definida pela Nota Técnica 2016/002. A diferença entre os dois documentos é a diferença entre um comprovante de pagamento e o registro fiscal completo de uma transação — aquele que determina seus créditos de imposto de entrada, sua reconciliação aduaneira e sua trilha de auditoria pelos próximos cinco anos.

A distinção entre DANFE e XML não é um mero detalhe técnico. É o conceito mais importante para qualquer departamento de AP que lida com faturas de fornecedores brasileiros, e tem uma consequência financeira direta: se sua equipe está inserindo dados do DANFE, você está redigitando manualmente uma fração de informações que já existem em formato estruturado e legível por máquina — e perdendo os detalhes fiscais que determinam se você está recuperando o valor correto de ICMS, IPI, PIS e COFINS em cada transação.

O que há dentro de um XML de NF-e — e por que isso importa para o AP

Um XML de NF-e não é apenas uma fatura escrita em colchetes angulares. É um documento fiscal juridicamente autoritativo que carrega a assinatura digital do vendedor, foi validado contra mais de 400 regras da SEFAZ e armazena dados fiscais com uma granularidade que supera qualquer padrão de faturamento eletrônico fora do Brasil. Em comparação, o padrão europeu Peppol BIS utiliza aproximadamente 100 elementos. Uma NF-e carrega cinco vezes mais — e cada elemento é legível por máquina.

Antes de projetar um fluxo de extração, você precisa entender o que está extraindo. Aqui estão os principais grupos de elementos dentro de cada XML de NF-e e por que cada um importa para contas a pagar:

A chave de acesso de 44 dígitos é o identificador universal da NF-e. Ela codifica o estado do emissor (2 primeiros dígitos, conforme código IBGE — 35 para São Paulo, 33 para Rio de Janeiro, 31 para Minas Gerais), o ano-mês de emissão (próximos 4), o CNPJ do emissor (próximos 14), o modelo do documento (2), a série (3), o número sequencial (9), o tipo de emissão (1), um código aleatório de 8 dígitos para evitar colisões e um dígito verificador módulo 11 (1). Todo XML de NF-e contém essa chave no atributo <infNFe Id="NFe...>, e você pode usá-la para consultar a SEFAZ diretamente, verificar a autenticidade, checar cancelamentos ou baixar o XML completo se seu fornecedor enviou apenas o DANFE.

Configurando Seu Fluxo de Extração de XML de NF-e

Existem três abordagens distintas para obter dados de XML de NF-e em uma planilha do Excel, e elas se situam em pontos muito diferentes no espectro custo-complexidade. Qual delas se encaixa para você depende do seu volume, da configuração do seu ERP e se sua subsidiária brasileira já utiliza um módulo de localização.

Método 1: Módulo de Importação do ERP (SAP TDF, Oracle EBS Brasil, Dynamics 365 Finance)

Se sua empresa opera SAP, Oracle EBS ou Microsoft Dynamics 365 com o módulo de localização Brasil ativado, o próprio ERP pode importar arquivos XML de NF-e diretamente. O TDF da SAP (módulo Nota Fiscal) processa XMLs de NF-e recebidos através da transação J1BNFE, mapeando cada elemento XML para a tabela SAP correspondente. A localização Brasil do Oracle EBS (disponível na versão 12.2.6+) usa o programa XML Generator SEFAZ (P76B601) para importações. O Dynamics 365 Finance fornece um fluxo de trabalho de importação dedicado em Contas a Pagar > Localização Brasil > Importar XML NF-e.

Este é o padrão ouro — ele valida junto à SEFAZ em tempo real, lança nas contas fiscais corretas e lida com a conciliação de três vias automaticamente. Também tem um preço elevado. Os módulos de localização Brasil do SAP e Oracle são custos de licença separados, e o TOTVS — o ERP dominante entre as empresas brasileiras de médio porte, com 33% de participação de mercado de acordo com a pesquisa mais recente da Fundação Getúlio Vargas (FGV) — é totalmente focado no Brasil e incomum fora do país. Se sua equipe global de contas a pagar não tem uma localização de ERP brasileira, esta abordagem não está disponível para você.

Método 2: Conversão de XML para Excel

No nível mais básico, um XML de NF-e é um arquivo XML, e qualquer arquivo XML pode ser convertido para um formato de planilha. Ferramentas como a importação XML nativa do Microsoft Excel (Dados > Obter Dados > De Arquivo > De XML), conversores online ou scripts Python usando bibliotecas como xml.etree.ElementTree podem achatar a estrutura XML em linhas e colunas.

O desafio da conversão genérica de XML é a profundidade do esquema da NF-e. Um único XML de NF-e aninha dados de itens dentro de elementos <det>, cada um contendo sua própria subárvore <imposto> com grupos separados de ICMS, IPI, PIS e COFINS. Uma conversão ingênua de XML para CSV vai achatar tudo em uma única linha com centenas de colunas, muitas com nomes idênticos (cada item tem um campo vProd, cada grupo de imposto tem um campo vBC). O resultado está tecnicamente "no Excel", mas não é utilizável sem uma limpeza substancial.

O xml.etree ou lxml do Python com consultas XPath explícitas oferece controle preciso — você extrai exatamente os elementos necessários e os mapeia para colunas nomeadas. Isso funciona bem se você tiver recursos de desenvolvimento disponíveis, mas exige a manutenção de mapeamentos XPath que quebram sempre que o esquema da NF-e é atualizado. Com a reforma tributária de 2026 adicionando novos grupos de elementos CBS/IBS ao esquema (veja abaixo), esses mapeamentos precisarão de atualização.

Método 3: Extração de Documentos com IA

Uma terceira abordagem — que evita tanto o custo da localização de ERP quanto a fragilidade dos scripts XPath — é a extração de documentos baseada em IA. Em vez de analisar o XML diretamente, você envia o DANFE (ou o XML da NF-e renderizado como PDF pelo sistema do seu fornecedor) para uma ferramenta de extração, especifica quais colunas deseja na tabela de saída — "CNPJ", "Número da Nota Fiscal", "Base ICMS", "Valor ICMS", "Código NCM", "CFOP" — e a IA lê o documento para localizar cada valor, independentemente de onde ele aparece na página.

Essa abordagem — às vezes chamada de Extração de Colunas Personalizadas — funciona de forma diferente do OCR baseado em modelo. O OCR tradicional exige que você defina um modelo para o layout da nota fiscal de cada fornecedor, informando ao sistema "o número da nota fiscal está sempre nas coordenadas (x,y)". Se o layout mudar, o modelo quebra. Já a extração baseada em colunas funciona por compreensão semântica: você nomeia os campos desejados, e a IA localiza os valores correspondentes em qualquer lugar do documento, entendendo o que o campo significa, não onde ele está. Isso é particularmente relevante para o processamento de NF-e porque os layouts dos DANFEs dos fornecedores brasileiros variam muito — não existe um modelo visual padronizado, apenas o esquema XML padronizado subjacente.

A limitação, e é honesto reconhecer, é que você ainda está extraindo do layout visual do DANFE, e não do XML legível por máquina. Você está obtendo os 10% de dados que o DANFE mostra, não os mais de 500 campos do XML. Para muitos casos de uso de contas a pagar — dados de cabeçalho, itens, totais — isso é suficiente e dramaticamente mais rápido que a entrada manual. Mas se você precisar dos cálculos completos de PIS/COFINS por linha, códigos CFOP ou códigos de situação tributária CST que existem apenas no XML, a extração por IA do DANFE não consegue recuperar dados que não estão impressos na página.

Mapeamento de Campos da NF-e para Sua Planilha: O Que Extrair e Por Quê

Seja escrevendo consultas XPath para análise de XML ou definindo nomes de colunas para extração por IA, as colunas escolhidas determinam a utilidade do resultado. Aqui está um mapeamento prático de campos que cobre os três fluxos de trabalho principais de contas a pagar — verificação de fornecedor, conciliação de três vias e lançamento de créditos tributários — usando os caminhos reais dos elementos XML.

Um detalhe crítico: o caminho do elemento ICMS depende da situação tributária. O esquema da NF-e usa diferentes subgrupos XML para diferentes regimes de ICMS — ICMS00 para operações tributadas padrão, ICMS40 para isentas, ICMS60 para tributadas anteriormente com substituição tributária. Sua lógica de extração deve navegar por essa estrutura ramificada: verifique qual subgrupo existe em <ICMS> antes de tentar ler seus filhos.

Lidando com a Complexidade Tributária Brasileira nos Dados Extraídos

Extrair os dados é o primeiro passo. Validá-los é onde o trabalho real começa — e onde a maioria dos erros que surgem durante uma auditoria fiscal se origina. O sistema tributário brasileiro opera em três níveis de governo (federal, estadual, municipal) com alíquotas que variam conforme a classificação do produto, o par origem-destino e a natureza jurídica da operação. Estas são as verificações de validação que devem fazer parte de qualquer fluxo de extração de dados de NF-e:

Validação da Alíquota de ICMS por Par de Estados

As alíquotas de ICMS não são uniformes. Para transações interestaduais, a alíquota é determinada pelos estados de origem e destino:

Para transações internas (dentro do mesmo estado), as alíquotas variam de 17% a 22%, dependendo do estado. Em 2024, Pernambuco cobra 20,5%, Bahia 20,5%, Maranhão 22%, Rio de Janeiro 20%, São Paulo 18%, Santa Catarina 17%. Essas alíquotas mudaram para 11 estados apenas em 2024 — a alíquota da Bahia aumentou de 19% para 20,5% em 7 de fevereiro, a do Maranhão de 20% para 22% em 19 de fevereiro — e sua lógica de validação de extração deve se manter atualizada com a tabela de alíquotas de cada estado brasileiro do qual você recebe notas fiscais.

Interpretação do Código CFOP

O CFOP (Código Fiscal de Operações e Prestações) é um código de 4 dígitos que classifica a natureza fiscal da transação. É pré-definido pela SEFAZ — não é texto livre — e o primeiro dígito indica se a operação é de entrada ou saída e de qual estado a mercadoria se origina:

Para o destinatário, o CFOP em uma nota fiscal de entrada (1xxx, 2xxx ou 3xxx) determina se os créditos de ICMS e IPI estão disponíveis e sob quais regras. Um CFOP 1101 (compra dentro do estado para industrialização) geralmente dá direito ao crédito integral de ICMS à alíquota interna. Um CFOP 1102 (compra dentro do estado para revenda) pode ter tratamento diferente. E isso interage com o CST (Código de Situação Tributária) — o código de 2 dígitos que especifica se o item é tributado (00), isento (40), sujeito à substituição tributária (60) ou se enquadra em regime especial. O CFOP informa qual é o tipo de operação; o CST informa como ela é tributada. Ambos devem ser extraídos e validados de forma cruzada.

Classificação NCM e seus Efeitos a Jusante

O NCM (Nomenclatura Comum do Mercosul) é um código de 8 dígitos baseado no Sistema Harmonizado internacional, com dois dígitos adicionais específicos do Mercosul. Ele aparece em cada item da nota e determina a alíquota do IPI para aquele produto (publicada na tabela TIPI, um PDF de mais de 400 páginas atualizado pela Receita Federal), qualquer alíquota de imposto de importação e — crucialmente — se o produto se qualifica para benefícios fiscais (alíquotas reduzidas, créditos presumidos ou isenções) que substituem o cálculo tributário padrão.

Um código NCM que se enquadra em um regime de benefício fiscal significa que a alíquota padrão de ICMS ou IPI exibida na nota fiscal pode não ser a que você deve registrar como crédito. Seu fluxo de extração deve sinalizar qualquer item cujo NCM corresponda a categorias de benefício conhecidas, para que sua equipe fiscal possa verificar o cálculo do crédito — e não apenas presumir que a alíquota bruta está correta.

A Reforma Tributária de 2026 e o que Ela Significa para seu Fluxo de Extração

A reforma tributária brasileira — instituída pela Emenda Constitucional 132/2023 e regulamentada pela Lei Complementar 214/2025 — está reestruturando fundamentalmente o sistema tributário indireto do país. Cinco tributos existentes (PIS, COFINS, ICMS, ISS e IPI) estão sendo gradualmente substituídos por um modelo de IVA dual: CBS (Contribuição sobre Bens e Serviços) no nível federal e IBS (Imposto sobre Bens e Serviços) nos níveis estadual e municipal, além de um Imposto Seletivo (IS) sobre bens considerados prejudiciais à saúde ou ao meio ambiente.

O cronograma de transição é:

A principal preocupação operacional para as equipes de AP é o período de esquema duplo de 2026 a 2033. Durante esses anos, os arquivos XML da NF-e conterão simultaneamente grupos de elementos tributários legados e novos. Um fluxo de extração que codifique mapeamentos de campos para o esquema anterior a 2026 (lendo apenas vICMS, vPIS, vCOFINS) ignorará silenciosamente os novos campos CBS/IBS. Isso não é um problema futuro — começa agora. A partir de 1º de agosto de 2026, XMLs de NF-e enviados sem os campos CBS/IBS serão rejeitados pela SEFAZ. A mudança de esquema é obrigatória, não opcional.

Se você está escrevendo scripts de análise de XML, planeje a ramificação de esquema: detecte quais grupos tributários existem no documento, extraia os que estiverem presentes e normalize-os em um conjunto consistente de colunas de saída. Se você usa extração baseada em IA a partir da DANFE, verifique com seu provedor se os campos CBS/IBS serão reconhecidos quando começarem a aparecer na representação impressa.

Perguntas Frequentes

Posso obter todos os dados do XML apenas pela DANFE?

Não. A DANFE é um resumo impresso que omite mais de 90% dos dados do XML. Foi projetada para inspeção física durante o transporte, não para processamento financeiro. As discriminações tributárias completas, códigos CFOP, classificações NCM, códigos de situação tributária CST e detalhes de transporte existem apenas no XML. Se seu fornecedor enviou apenas a DANFE, peça a ele o XML — eles são legalmente obrigados a fornecê-lo, e você também pode recuperá-lo da SEFAZ usando a chave de acesso de 44 dígitos impressa na DANFE.

Como saber qual alíquota de ICMS se aplica a uma nota fiscal específica?

A alíquota de ICMS em uma NF-e é determinada pelo estado de origem (extraído da inscrição estadual do emitente em <emit>), pelo estado de destino (estado da sua entidade em <dest>) e se as mercadorias contêm mais de 40% de conteúdo importado (o que aciona a alíquota de 4%, independentemente do par de estados). O próprio XML traz a alíquota aplicada pelo vendedor em pICMS, mas você deve validá-la em relação à tabela de alíquotas correta, em vez de presumir que o vendedor a aplicou corretamente — erros de alíquota são uma constatação comum em auditorias.

A IA consegue interpretar automaticamente os códigos CFOP corretamente?

Os códigos CFOP são extraídos como estão do documento — o código de 4 dígitos aparece na DANFE e no XML. Se a ferramenta consegue interpretar o código (por exemplo, identificar como "compra dentro do estado para revenda" vs. "compra interestadual para industrialização") depende das capacidades da ferramenta. Algumas ferramentas de extração por IA conseguem mapear códigos CFOP para suas descrições usando uma tabela de referência. Se a interpretação for essencial para seu fluxo de trabalho, verifique com seu provedor de ferramentas se o mapeamento CFOP é suportado, ou mantenha uma tabela de consulta separada no Excel para decodificar os códigos extraídos.

Nossa empresa não tem uma localização brasileira de ERP. Ainda assim podemos extrair dados de NF-e?

Sim. O XML em si é um arquivo de formato padrão que qualquer empresa com o arquivo XML pode analisar. Você não precisa do SAP TDF ou da localização Oracle Brasil para lê-lo. Scripts Python, conversores online de XML para Excel ou ferramentas de extração por IA podem colocar os dados em uma planilha. O módulo de localização do ERP adiciona integração (lançamento automático, validação SEFAZ, mapeamento de contas fiscais), mas não é necessário para a extração.

A extração de NF-e cobre os requisitos de relatórios SPED?

Não. O SPED (Sistema Público de Escrituração Digital) é o sistema de escrituração digital do Brasil que exige declarações separadas — EFD-ICMS/IPI para imposto estadual, EFD-Contribuições para PIS/COFINS e ECD para livros contábeis digitais. A extração de NF-e obtém os dados da nota fiscal no Excel; ela não gera arquivos compatíveis com o SPED. As declarações SPED exigem mapear os dados extraídos para os códigos de layout específicos do SPED e enviá-los por meio de software validado pelo governo — um fluxo de trabalho separado, tratado pela sua equipe contábil brasileira ou provedor de conformidade fiscal.

O que acontece se um fornecedor cancelar uma NF-e depois que eu já extraí os dados?

Uma NF-e pode ser cancelada pelo emissor dentro de 24 horas da autorização, se as mercadorias ainda não tiverem sido enviadas. O cancelamento cria um evento (evento de cancelamento) no sistema da SEFAZ vinculado à mesma chave de acesso de 44 dígitos. Qualquer consulta a essa chave retornará o status de cancelado. Seu fluxo de trabalho de extração deve validar periodicamente as chaves de acesso junto à SEFAZ — especialmente para notas fiscais próximas às datas de pagamento — para evitar lançamentos contra documentos cancelados. Sob a reforma de 2026, o cancelamento após o fato gerador acarreta multa de 66% do imposto devido, o que deve reduzir a frequência de cancelamentos tardios, mas a verificação continua sendo um controle necessário.

Como lidar com a extração em lote de vários arquivos XML de NF-e?

Para métodos baseados em XML, use um script que percorra uma pasta de arquivos XML, extraia o mesmo conjunto de consultas XPath de cada um e anexe os resultados a uma planilha cumulativa. Para extração baseada em IA de DANFE em PDF, use a capacidade de processamento em lote — envie vários arquivos DANFE juntos, defina suas colunas uma vez, e a ferramenta extrairá dados de cada documento e mesclará os resultados em um único arquivo Excel. Essa abordagem também lida com formatos mistos: se alguns fornecedores enviam DANFE em PDF e outros enviam o XML renderizado como impressão, o processamento em lote extrai de ambos na mesma execução.

Qual é a precisão da extração de dados de NF-e em comparação com a digitação manual?

Para extração baseada em XML, a precisão é efetivamente de 100% para os campos selecionados — você está lendo dados estruturados de um arquivo legível por máquina, não interpretando um layout visual. Para extração baseada em IA do DANFE, a precisão do texto impresso pode chegar a 99%, mas a precisão em campos complexos (como a chave de acesso de 44 dígitos, onde um único dígito trocado invalida a chave) depende do tratamento da ferramenta para strings numéricas longas. O verdadeiro ganho de precisão em relação à digitação manual não está apenas na precisão em nível de caractere — está na completeza. Um humano digitando dados de um DANFE normalmente captura de 8 a 12 campos por nota fiscal. A extração automatizada captura todos os campos especificados em todos os documentos, eliminando a omissão de dados, que é a forma mais comum e menos visível de erro de digitação manual.