50 XMLs de NF-e Brasileiras, Uma Planilha
Como o Processamento em Lote com Múltiplos Fornecedores Elimina a Conciliação Fiscal Manual

Quando 50 XMLs de NF-e Chegam — Por Que o Lote Não É "Uma Única NF-e Repetida 50 Vezes"

O processamento de NF-e brasileiro é incomum em um aspecto: os dados de origem já são estruturados. Diferentemente de notas fiscais em papel de fornecedores dos EUA ou Europa, que exigem OCR para digitalização, toda NF-e chega como um arquivo XML já validado contra mais de 400 regras da SEFAZ e assinado digitalmente com um certificado ICP-Brasil. A qualidade dos dados de uma única NF-e XML é quase perfeita. O problema do lote na AP brasileira não é a precisão da captura de dados — é a consistência dos dados entre fornecedores.

Ao processar 50 XMLs de NF-e de 14 fornecedores em um único lote, surgem quatro problemas estruturais que o processamento de notas individuais nunca expõe:

Fragmentação das alíquotas de ICMS. O ICMS brasileiro é um IVA estadual com alíquotas que variam conforme o estado do fornecedor, seu estado, a direção da transação (intraestadual vs interestadual) e — em alguns casos — a classificação NCM do produto. Um lote de 50 XMLs de NF-e de fornecedores em 7 estados pode conter alíquotas intraestaduais de 17%, 18%, 19%, 19,5%, 20% e 20,5%, além de alíquotas interestaduais de 4%, 7% ou 12%, dependendo das combinações de origem e destino. Uma única coluna "Valor do ICMS" na sua planilha é inútil a menos que você também saiba a alíquota, o estado aplicável e se a transação é interna ou interestadual — porque o mesmo valor de R$ 1.000 de ICMS pode significar uma alíquota de 17% sobre uma base de R$ 5.882 ou uma alíquota de 12% sobre uma base de R$ 8.333. O módulo fiscal do seu ERP precisa dessa distinção.

Inconsistências de CFOP. Cada item da NF-e possui um código CFOP de 4 dígitos (Código Fiscal de Operações e Prestações) que classifica a natureza fiscal da transação — 1.101 para compra para industrialização dentro do mesmo estado, 2.102 para compra interestadual para revenda, 3.101 para importação. O primeiro dígito indica se a transação é intraestadual (1), interestadual (2) ou importação internacional (3). Quando o fornecedor A usa CFOP 1.101 para uma remessa de São Paulo para seu armazém em São Paulo, e o fornecedor B usa CFOP 2.102 para uma remessa interestadual de Minas Gerais, isso está correto e intencional. Mas se o fornecedor C usa CFOP 1.101 em uma remessa originada no Rio de Janeiro — uma transação interestadual — o CFOP diverge dos dados de estado nos blocos <ide> e <emit> do XML. Essa incompatibilidade gerará uma marca de auditoria no SPED EFD (Escrituração Fiscal Digital), o sistema federal de escrituração digital que cruza códigos CFOP em toda a cadeia de suprimentos. Em um lote de 50 notas fiscais, 3 a 5 incompatibilidades são comuns — e encontrá-las manualmente exige verificar o CFOP de cada XML em relação ao par estado de origem-destino.

Falha na detecção de duplicidade apenas pelo número da nota fiscal. Na maioria dos sistemas de contas a pagar, a detecção de duplicidade depende do fornecedor + número da nota fiscal. Essa lógica falha com a NF-e brasileira porque o número da nota (número da nota) é único apenas dentro de uma série de um único fornecedor. O Fornecedor A pode emitir a NF-e #1523 na série 001, enquanto o Fornecedor B também emite a NF-e #1523 em sua série 001. Até o mesmo fornecedor pode emitir números de nota idênticos em séries diferentes. O identificador globalmente único é a chave de acesso de 44 dígitos — mas a maioria das ferramentas de extração em lote não a extrai, ou a extrai sem entender seu papel como chave de desduplicação. Sem a chave de acesso, duas notas fiscais diferentes de dois fornecedores diferentes com o mesmo número de nota serão sinalizadas como duplicatas e uma será suprimida — ou pior, uma nota reenviada com uma chave de acesso corrigida (indicando um evento de carta de correção CCe) não será reconhecida como substituta.

Fontes em formatos mistos. Em um lote de 50 notas fiscais de fornecedores brasileiros, raramente se obtém 50 XMLs limpos. Alguns fornecedores — geralmente pequenos fabricantes ou produtores agrícolas — enviam apenas o DANFE impresso como PDF ou digitalização. Alguns enviam o XML, mas anexam um DANFE digitalizado com anotações manuscritas. Um fornecedor industrial de médio porte pode enviar o XML da NF-e principal, mas o CT-e (Conhecimento de Transporte Eletrônico) do frete como PDF. O fluxo de processamento em lote precisa lidar com todos esses casos em uma única passada — extraindo dados estruturados do XML quando disponível e lendo o documento visual quando o XML está ausente — e mesclando tudo em colunas consistentes.

Esses quatro problemas não existem com uma única nota fiscal. Com 50, todos os quatro disparam simultaneamente — e resolvê-los é o que diferencia um fluxo de processamento em lote de "extração única, repetida 50 vezes".

A Matriz de Alíquotas de ICMS em 7 Estados — Por que uma Única Coluna de "Imposto" Quebra

As alíquotas internas de ICMS no Brasil mudaram significativamente em 2024, em parte na expectativa da reforma tributária que eventualmente substituirá o ICMS pelo novo IBS (Imposto sobre Bens e Serviços) entre 2029 e 2033. Onze estados brasileiros alteraram suas alíquotas padrão de ICMS no ano passado:

A consequência prática para o processamento em lote: se sua base de fornecedores abranger mais de dois estados brasileiros, sua planilha de lote precisa rastrear o ICMS no nível alíquota × estado × tipo de transação — não em uma única coluna que soma todos os valores de ICMS. Uma NF-e de um fornecedor em Pernambuco (20,5% interestadual) e uma NF-e de um fornecedor em São Paulo (18% interestadual) terão tratamento diferente de ICMS no seu ERP, mesmo que a coluna de valor do ICMS mostre o mesmo número.

As alíquotas interestaduais adicionam uma segunda dimensão, codificada na legislação tributária brasileira:

Combine essas faixas de alíquotas interestaduais com as 11 alterações de alíquotas estaduais acima, e um lote de XMLs de NF-e de fornecedores em 7 estados pode facilmente conter 5 alíquotas de ICMS diferentes — cada uma deve ser identificada, separada por tipo e lançada na conta fiscal correta do seu ERP. Ferramentas que extraem o ICMS como um único número, sem capturar a alíquota, o estado de origem e o tipo de transação do XML, estão gerando uma planilha que cria mais trabalho de conciliação do que economiza.

É aqui que extrair diretamente da estrutura do XML da NF-e — e não fazer OCR do DANFE — compensa em lote. O bloco <imposto> do XML contém grupos de elementos separados para ICMS, IPI, PIS e COFINS, cada um com base de cálculo (vBC), alíquota (pICMS, pIPI, etc.) e valor (vICMS, vIPI, etc.) no nível do item. Uma extração baseada em nomes de colunas que mapeia esses campos estruturados — "Base ICMS", "Alíquota ICMS (%)", "Valor ICMS", "Valor IPI", "Valor PIS", "Valor COFINS" — em colunas separadas da planilha produz uma tabela onde cada valor de imposto é rastreável de volta à sua alíquota e base, sem recálculo manual. Para um detalhamento da estrutura do XML da NF-e e mapeamento de campos, veja o guia completo de extração do XML da NF-e.

Consistência do CFOP entre Fornecedores — A Bandeira de Auditoria que Ninguém Verifica em Lote

Os códigos CFOP são classificações fiscais de operação de 4 dígitos embutidos em cada item da NF-e. Existem mais de 500 códigos CFOP definidos pelas autoridades fiscais brasileiras, organizados pelo primeiro dígito:

Em uma única NF-e, uma divergência de CFOP é fácil de identificar: se o estado do fornecedor é Minas Gerais e sua empresa está em São Paulo, todo CFOP deve começar com 2 (entrada interestadual). Se um item da nota apresentar CFOP 1.101 — intraestadual — há um erro de dados. Em escala, com 50 notas fiscais de vários fornecedores, esse tipo de validação se torna essencial e não trivial. Um fornecedor pode usar corretamente o CFOP 1.101 para remessas locais (para seus próprios clientes), mas deveria usar 2.101 ao enviar para você entre estados. Se o ERP dele preencheu automaticamente o CFOP errado, você herda uma exposição fiscal que o SPED EFD detectará — pois o sistema de escrituração digital cruza os registros de CFOP do comprador e do vendedor para cada transação. Uma divergência entre o CFOP de entrada registrado por você e o CFOP de saída correspondente do fornecedor gera uma bandeira automática de auditoria.

A validação em lote de CFOP significa verificar três relações para cada item da nota no lote:

1. Primeiro dígito vs par de estados. O primeiro dígito do CFOP deve corresponder se o fornecedor e o comprador estão no mesmo estado (1/5) ou em estados diferentes (2/6). Extraia o código IBGE do estado dos blocos <emit> e <dest> — códigos 35 (SP), 33 (RJ), 31 (MG), 41 (PR), etc. — e valide o prefixo do CFOP com a determinação de mesmo estado/estados diferentes.
2. Consistência do sufixo do CFOP em operações similares. Se o fornecedor A usa CFOP 2.102 (compra interestadual para revenda) e o fornecedor B usa CFOP 2.101 (compra interestadual para industrialização) para o mesmo tipo de produto, pelo menos um deles está errado — o sufixo do CFOP deve refletir a finalidade real da transação.
3. Sem contradição CFOP-NCM. O CFOP codifica a natureza da operação, o NCM codifica a classificação do produto. Um CFOP sugerindo insumo industrial combinado com um NCM de produto final de consumo é um sinal de alerta — significa que ou o CFOP ou o NCM está incorreto, e ambos afetam o tratamento tributário.

A Chave de Acesso de 44 Dígitos — A Chave de Deduplicação Integrada do Brasil que a Maioria das Ferramentas em Lote Ignora

A chave de acesso é uma string de 44 dígitos que identifica de forma única toda NF-e emitida no Brasil, permanentemente. Não é apenas um número de referência — é um identificador estruturado que codifica o estado do emissor (primeiros 2 dígitos, conforme código IBGE), ano-mês de emissão (próximos 4), CNPJ do emissor (próximos 14), modelo do documento (2), série (3), número sequencial (9), tipo de emissão (1), um código aleatório de colisão (8) e um dígito verificador módulo 11 (1). Todo XML de NF-e carrega essa chave no atributo <infNFe Id="NFe[chave]"> e no elemento <chNFe>. É o mais próximo de um identificador global único de fatura que qualquer sistema tributário no mundo oferece.

No entanto, a maioria das ferramentas de lote extrai uma coluna "Número da Nota Fiscal" e encerra. No Brasil, essa coluna não é suficiente:

• O Fornecedor A pode emitir NF-e #1523 na série 001 e NF-e #1523 na série 002 — mesmo número de nota, dois documentos fiscais completamente diferentes, distinguíveis apenas pela série e chave de acesso.
• O Fornecedor B pode emitir NF-e #1523 em sua própria série 001 — mesmo número de nota do Fornecedor A, fornecedor diferente, transação diferente — e uma verificação simples de duplicidade por fornecedor+número da nota suprimirá uma como duplicada.
• O sistema de cancelamento e correção da SEFAZ depende da chave de acesso. Quando um fornecedor emite uma Carta de Correção (CCe) para corrigir um erro na NF-e original, a chave de acesso original permanece válida — mas o histórico de eventos vinculado a essa chave registra a correção. Uma ferramenta de lote que não rastreia a chave não consegue distinguir entre a versão original e a corrigida.

Em um lote de 50 XMLs de NF-e, extraia a chave de acesso como uma coluna própria. Em seguida, implemente três verificações:

1. Unicidade no lote. Duas linhas não podem compartilhar a mesma chave de acesso. Se isso ocorrer, a mesma NF-e foi enviada duas vezes — suprima a linha duplicada e sinalize a ocorrência.
2. Unicidade do número da nota dentro do fornecedor × série. Agrupe por CNPJ + série + número da nota. Se a mesma combinação aparecer duas vezes com chaves de acesso diferentes, provavelmente uma é uma correção — a chave com o carimbo de data/hora de emissão mais recente prevalece.
3. Verificação SEFAZ para notas de alto valor. Para notas acima de um limite de materialidade, use a chave de acesso para consultar o portal público da SEFAZ ou uma API de terceiros como a consulta NF-e da TF Fiscal para verificar o status de autorização (Autorizada/Cancelada/Denegada). Uma NF-e cancelada no seu lote significa que o fornecedor a reemitiu — e você precisa da chave de substituição.

Os 44 dígitos parecem intimidadores para equipes de contas a pagar não brasileiras. Mas são a chave de desduplicação mais confiável disponível em qualquer regime de faturamento eletrônico globalmente. Não usá-los no processamento em lote é como ter um CPF e identificar pessoas pelo primeiro nome.

O Lote Misto de XML + DANFE — Quando Alguns Fornecedores Enviam a Nota Completa e Outros Apenas Papel

Fornecedores brasileiros de grande porte — especialmente fabricantes industriais e distribuidores que usam SAP, TOTVS Protheus ou Oracle — enviam o XML da NF-e como rotina. Ele é gerado pelo ERP, assinado pelo certificado ICP-Brasil e transmitido à SEFAZ automaticamente. Enviá-lo ao comprador junto com a DANFE é uma operação de um clique.

Fornecedores menores — cooperativas agrícolas, prestadores de serviços locais, alguns fornecedores de materiais de construção — podem não ter a infraestrutura de ERP para gerenciar a transmissão de XML. Eles imprimem o DANFE, entregam ao motorista do caminhão, e esse é o único documento que o comprador vê. A nota fiscal é real, foi autorizada pela SEFAZ (o protocolo de autorização está impresso no DANFE), mas o departamento de contas a pagar recebedor só tem um PDF escaneado ou uma foto do documento em papel.

Um fluxo de trabalho de contas a pagar em lote que lida apenas com XML ou apenas PDF força a equipe de AP a dividir o recebimento mensal de notas fiscais em dois pipelines de processamento separados — um para XML estruturado, outro para DANFEs escaneados — e depois mesclar manualmente as saídas em um único lançamento contábil. O custo da fragmentação é real: sessões de upload separadas, revisões separadas e uma etapa de conciliação no final para garantir que todas as notas do mesmo fornecedor (algumas XML, outras PDF) caiam no mesmo lote de AP.

Extração de Colunas Personalizadas — a abordagem do ImageToTable.ai de extrair dados pelo significado do campo, em vez de coordenadas de modelo — lida com ambas as fontes em um único upload em lote. Você define os nomes das colunas uma vez: "Chave de Acesso", "CNPJ do Fornecedor", "Nome do Fornecedor", "Número da NF-e", "Série", "Data de Emissão", "CFOP", "NCM", "Descrição do Item", "Quantidade", "Preço Unitário", "Total do Item", "Base ICMS", "Alíquota ICMS", "Valor ICMS", "Valor IPI", "Valor PIS", "Valor COFINS", "Valor Total da NF-e". A IA lê dados estruturados de arquivos XML, onde os campos são legíveis por máquina, e extrai os mesmos campos de PDFs de DANFE escaneados, entendendo visualmente o significado de cada rótulo — independentemente do layout. Ambas as fontes se mesclam na mesma planilha, com as mesmas colunas, em um único lote.

A vantagem prática não é apenas a velocidade — é a consistência. A coluna chave de acesso dos arquivos XML é extraída diretamente do elemento <chNFe>. A mesma coluna de uma digitalização de DANFE é lida a partir da área de código de barras de 44 dígitos no canto superior direito do documento impresso. Ambas as entradas vão para a mesma coluna, permitindo a mesma lógica de deduplicação descrita acima. Sem um fluxo de trabalho em lote unificado, a chave de acesso do lote XML e a chave de acesso do lote de DANFE digitalizado ficam em planilhas separadas — e a detecção de duplicatas entre elas é manual.

A Transição da Reforma Tributária 2026–2033 — Conformidade Dupla em um Único Lote

A reforma tributária sobre o consumo no Brasil — instituída pela Emenda Constitucional 132 de dezembro de 2023 e regulamentada pela Lei Complementar 214 de janeiro de 2025 — está reestruturando todo o sistema tributário indireto do país ao longo de uma transição de oito anos. Até 2033, cinco tributos legados (PIS, COFINS, IPI, ICMS e ISS) serão substituídos por um sistema dual de IVA: o CBS federal (Contribuição sobre Bens e Serviços) e o IBS estadual-municipal (Imposto sobre Bens e Serviços), além do Imposto Seletivo (IS) sobre bens prejudiciais à saúde e ao meio ambiente. A transição começou em 1º de janeiro de 2026.

Para as equipes de AP que processam lotes de NF-e brasileiras, a preocupação operacional imediata é a conformidade dupla no esquema XML. Durante os anos de transição, os XMLs de NF-e trarão simultaneamente campos de tributos legados (ICMS, IPI, PIS, COFINS) e novos campos tributários (CBS, IBS) — ou seja, o já complexo XML de NF-e com mais de 500 campos está prestes a se tornar ainda maior. Aqui está o cronograma que afeta o design da extração em lote:

A implicação prática para a extração em lote em 2026: se você está montando as definições de colunas agora, inclua as colunas CBS e IBS junto com as de ICMS e PIS/COFINS — mesmo que às alíquotas de teste. Os dados já estão no XML hoje. Extraí-los não custa nada. Tê-los na sua planilha quando a transição acelerar em 2027 significa que seus dados históricos em lote já conterão a base para a apuração baseada em CBS, sem necessidade de reextração retroativa de XMLs de NF-e arquivados de 2026.

Um sistema de extração em lote que lê nomes de campos semanticamente — "Base ICMS", "Alíquota ICMS", "Base CBS", "Alíquota CBS", etc. — lida com essa transição sem reconfiguração por fornecedor. As definições de colunas permanecem as mesmas; a IA encontra quaisquer campos de tributos presentes na versão atual do esquema XML. Conforme as atualizações da Nota Técnica adicionam novos campos e depreciam os antigos nos próximos sete anos, a lógica de extração se adapta ao XML que chega — e não a um template que precisa ser reconstruído toda vez que a SEFAZ publica uma nova versão de layout.

Um Fluxo de Processamento em Lote de NF-e que Sobrevive ao Fim do Mês

Com os problemas estruturais mapeados, aqui está uma sequência de processamento em lote projetada para a realidade do AP brasileiro com múltiplos fornecedores e estados:

Este fluxo pressupõe que sua ferramenta de extração em lote pode lidar com documentos XML e visuais na mesma sessão de upload — porque o AP brasileiro raramente recebe um formato exclusivamente. Se seu processo atual exige um fluxo separado para análise de XML e outro para OCR de PDF, a etapa de mesclagem na etapa 5 dobra seu tempo de processamento e introduz o risco de mapeamentos inconsistentes de colunas entre os dois pipelines.

Perguntas Frequentes

O processamento em lote pode lidar com XMLs de NF-e e PDFs de DANFE no mesmo upload?

Sim — se a ferramenta de extração interpretar a semântica em vez de depender apenas da análise XML. A extração semântica lê as tags estruturadas do XML da NF-e para dados que existem em ambos os formatos (CNPJ, número da NF-e, totais, valores de impostos) e lê visualmente o DANFE nos casos em que apenas o documento impresso está disponível. A saída é consolidada em uma única planilha com colunas consistentes. Se sua ferramenta apenas analisa XML ou faz apenas OCR, você precisará de dois fluxos de trabalho separados e uma etapa manual de mesclagem.

O que acontece quando duas NF-e XML têm o mesmo número de nota fiscal, mas chaves de acesso diferentes?

Este é um cenário legítimo — normalmente uma NF-e corrigida reemitida após um evento de CCe, ou dois documentos NF-e de séries diferentes com o mesmo número sequencial. A chave de acesso é única em ambos os casos. Sua validação em lote deve agrupar por chave de acesso (e não por número da nota fiscal) para deduplicação, e preservar a relação entre número da nota fiscal, série e chave para fins de auditoria. Se o mesmo CNPJ + série + número da nota fiscal aparecer com duas chaves de acesso diferentes, revise os carimbos de data/hora de emissão — a chave posterior substitui a anterior.

Como lidar com ICMS-ST (substituição tributária) em um lote?

O ICMS-ST aparece no XML da NF-e como um grupo de impostos separado (<ICMSTot> no bloco de totais) com sua própria base, alíquota e valor. Ele deve ser extraído em colunas separadas ("Base ICMS-ST", "Valor ICMS-ST") — não mesclado com o ICMS regular. O ICMS-ST representa imposto já pago upstream por um substituto tributário, e seu ERP o trata de forma diferente do ICMS regular para fins de crédito. Misturá-los em uma única coluna "ICMS" superestimará seus créditos disponíveis.

Posso extrair apenas itens específicos de uma NF-e em vez de todos os itens?

Sim. Ao definir suas colunas de extração, inclua os campos necessários no nível do item (NCM, CFOP, descrição, quantidade, preço unitário, total do item e impostos por linha). A IA extrai cada item de cada NF-e que corresponde à sua definição de coluna. Se você precisar apenas de algumas colunas — por exemplo, NCM + quantidade + CFOP, sem o preço unitário — deixe as colunas indesejadas de fora da sua definição. A extração produz apenas o que você solicitar.

A reforma tributária de 2026 altera o que preciso extrair dos XMLs de NF-e?

Em 2026, o esquema XML da NF-e agora inclui campos de CBS e IBS com alíquotas de teste (0,9% e 0,1%, respectivamente), juntamente com os campos existentes de ICMS, PIS e COFINS. Essas alíquotas de teste são totalmente dedutíveis do PIS/COFINS, portanto, a obrigação tributária líquida não muda. No entanto, os campos existem no XML e devem ser extraídos agora — quando a CBS substituir o PIS/COFINS com alíquotas integrais em 2027, suas definições de colunas de extração em lote já estarão em vigor. O cronograma da reforma tributária está codificado na Lei Complementar 214/2025 e na análise de 2025 da OCDE sobre a reforma.

Por quanto tempo preciso manter os XMLs de NF-e e os registros de extração?

A legislação tributária brasileira exige que os XMLs de NF-e e documentos fiscais relacionados sejam arquivados por um período mínimo de cinco anos a partir do final do exercício fiscal em que a transação ocorreu. Isso se aplica tanto aos XMLs originais recebidos dos fornecedores quanto aos seus registros de extração. O DANFE não é um substituto legalmente suficiente para o XML durante uma auditoria — se você manteve apenas o DANFE digitalizado e descartou o XML, não poderá reconstruir o registro fiscal completo que a SEFAZ solicitará. Melhor prática: arquive os XMLs como estão e mantenha a planilha de extração como um registro separado e pesquisável para conciliação interna.