50 XMLs de NF-e brasileiras, uma única planilha
Como o processamento em lote multi-fornecedor elimina a conciliação fiscal manual

Quando 50 XMLs de NF-e Chegam — Por Que o Lote Não É "Único, Repetido 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 da Europa que exigem OCR para digitalização, cada NF-e chega como um arquivo XML que já foi validado contra mais de 400 regras da SEFAZ e assinado digitalmente com um certificado ICP-Brasil. A qualidade dos dados de um único XML de NF-e é quase perfeita. O problema de 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, quatro problemas estruturais surgem que o processamento de nota única nunca expõe:

Fragmentação das alíquotas de ICMS. O ICMS brasileiro é um imposto estadual com alíquotas que variam conforme o estado do fornecedor, o seu estado, a direção da transação (intraestadual vs interestadual) e — em alguns casos — a classificação do produto pelo NCM. 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 coluna "Valor do ICMS" na sua planilha não significa nada 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.

Lacunas de consistência do CFOP. Cada item de linha de uma NF-e contém um código CFOP (Código Fiscal de Operações e Prestações) de 4 dígitos 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 codifica se a transação é intraestadual (1), interestadual (2) ou importação internacional (3). Quando o fornecedor A usa o CFOP 1.101 para uma remessa de São Paulo para o seu armazém em São Paulo, e o fornecedor B usa o CFOP 2.102 para uma remessa interestadual de Minas Gerais, isso é correto e deliberado. Mas se o fornecedor C usa o CFOP 1.101 em uma remessa originada no Rio de Janeiro — uma transação interestadual — o CFOP discorda dos dados de estado nos blocos <ide> e <emit> do XML. Essa incompatibilidade criará um sinalizador 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, 3–5 incompatibilidades são comuns — e encontrá-las manualmente significa verificar o CFOP de cada XML contra o par de estados de origem e destino.

Falha na detecção de duplicatas apenas pelo número da nota. Na maioria dos sistemas de AP, a detecção de duplicatas depende do fornecedor + número da nota. Essa lógica falha com a NF-e brasileira porque o número da nota é único apenas dentro de uma única série de um fornecedor. O fornecedor A pode emitir a NF-e nº 1523 na série 001, enquanto o fornecedor B também emite a NF-e nº 1523 na 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 deduplicação. Sem a chave de acesso, duas notas 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 uma substituição.

Fontes de formatos mistos. Em um lote de 50 notas fiscais de fornecedores brasileiros, raramente você obtém 50 XMLs limpos. Alguns fornecedores — normalmente fabricantes menores 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 de frete (Conhecimento de Transporte Eletrônico) como PDF. O fluxo de trabalho 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 estiver ausente — e mesclando tudo em colunas consistentes.

Esses quatro problemas não existem em uma única nota fiscal. Em 50, todos os quatro disparam simultaneamente — e resolvê-los é o que diferencia um fluxo de trabalho 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" Falha

As alíquotas internas de ICMS no Brasil mudaram significativamente em 2024, em parte em antecipação à 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 abrange 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% interna) e uma NF-e de um fornecedor em São Paulo (18% interna) terão tratamentos de ICMS diferentes 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 mudanças de alíquotas estaduais acima, e um lote de XMLs de NF-e de fornecedores em 7 estados pode facilmente conter 5 alíquotas diferentes de ICMS — cada uma das quais 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 escala. O bloco <imposto> do XML contém grupos de elementos separados para ICMS, IPI, PIS e COFINS, cada um com a base de cálculo (vBC), a alíquota (pICMS, pIPI, etc.) e o 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 na planilha produz uma tabela em que cada valor de imposto é rastreável até sua alíquota e base, sem recálculo manual. Para um detalhamento completo da estrutura do XML da NF-e e do mapeamento de campos, consulte o guia completo de extração de XML da NF-e.

Consistência do Código CFOP Entre Fornecedores — O Sinal de Auditoria Que Ninguém Verifica em Lote

Os códigos CFOP são classificações de operações fiscais de 4 dígitos embutidas 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 código CFOP deve começar com 2 (entrada interestadual). Se um item mostrar 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 deve usar 2.101 ao enviar para você entre estados. Se o ERP dele preencheu automaticamente o CFOP errado, você herda uma exposição de auditoria que o SPED EFD detectará — porque o sistema de escrituração digital cruza os registros de CFOP do comprador e do vendedor para cada transação. Uma divergência entre seu registro de CFOP de entrada e o registro de saída correspondente do fornecedor gera um sinal automático de auditoria.

A validação de CFOP em lote significa verificar três relações para cada item do 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 semelhantes. 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 o propósito comercial 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 que sugere insumo industrial combinado com um NCM de produto de consumo acabado é 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 de Lote Ignora

A chave de acesso é uma string de 44 dígitos que identifica exclusivamente cada NF-e emitida no Brasil, para sempre. Não é meramente um número de referência — é um identificador estruturado que codifica o estado do emissor (2 primeiros dígitos, conforme código IBGE), ano-mês de emissão (4 seguintes), CNPJ do emissor (14 seguintes), 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). Cada XML de NF-e carrega essa chave no atributo <infNFe Id="NFe[chave]"> e no elemento <chNFe>. É o mais próximo de um identificador globalmente único de fatura que qualquer sistema tributário do mundo oferece.

No entanto, a maioria das ferramentas de lote de contas a pagar extrai uma coluna "Número da Nota" e encerra por aí. 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 pela chave de acesso.
• O Fornecedor B pode emitir NF-e #1523 na 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 de nota suprimirá uma delas 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 de digitação 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. Exclusividade no lote. Nenhuma linha deve 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. Exclusividade do número da nota dentro de 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, uma provavelmente é uma correção — a chave com o timestamp de emissão mais recente prevalece.
3. Verificação na 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 de 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 substituta.

Os 44 dígitos parecem intimidadores para equipes de contas a pagar não brasileiras. Mas eles são a chave de deduplicaçã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 número de CPF e identificar as pessoas pelo primeiro nome.

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

Fornecedores brasileiros maiores — especialmente fabricantes industriais e distribuidores que usam SAP, TOTVS Protheus ou Oracle — enviam o XML da NF-e por rotina. Ele é gerado pelo ERP deles, assinado pelo certificado ICP-Brasil e transmitido à SEFAZ automaticamente. Enviá-lo ao comprador junto com o 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 é real, foi autorizada pela SEFAZ (o protocolo de autorização está impresso no DANFE), mas o departamento de contas a pagar que a recebe 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 com PDF força a equipe a dividir o recebimento mensal de notas em dois pipelines separados — um para XML estruturado, outro para DANFEs escaneados — e depois mesclar manualmente os resultados 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 reconciliação no final para garantir que todas as notas do mesmo fornecedor (algumas XML, algumas PDF) cheguem ao mesmo lote de contas a pagar.

Extração de Colunas Personalizadas — a abordagem da ImageToTable.ai de extrair dados pelo significado do campo, em vez de coordenadas de modelo — processa 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 DANFE digitalizados, entendendo o significado de cada rótulo visualmente — independentemente do layout. Ambas as fontes são mescladas 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 um DANFE digitalizado é lida da área do código de barras de 44 dígitos no canto superior direito do documento impresso. Ambas as entradas são registradas na mesma coluna, permitindo a mesma lógica de deduplicação descrita acima. Sem um fluxo de trabalho unificado em lote, a chave de acesso do lote XML e a chave de acesso do lote 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 de tributos indiretos do país ao longo de uma transição de oito anos. Até 2033, cinco tributos atuais (PIS, COFINS, IPI, ICMS e ISS) serão substituídos por um sistema dual de IVA: a CBS federal (Contribuição sobre Bens e Serviços) e o IBS estadual e municipal (Imposto sobre Bens e Serviços), além do Imposto Seletivo (IS) sobre bens e serviços prejudiciais à saúde e ao meio ambiente. A transição começou em 1º de janeiro de 2026.

Para equipes de contas a pagar 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 conterão simultaneamente campos de tributos atuais (ICMS, IPI, PIS, COFINS) e novos campos de tributos (CBS, IBS) — o que significa que o já complexo XML de NF-e com mais de 500 campos está prestes a ficar ainda maior. Este é 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á construindo definições de columna agora, inclua colunas CBS e IBS junto às suas colunas ICMS e PIS/COFINS — mesmo com alíquotas de teste. Os dados estão no XML hoje. Extraê-los não custa nada. Tenerlos en su hoja de cálculo cuando la transición se acelere en 2027 significa que sus datos históricos de lote ya contienen la base para informes basados en CBS, sin re-extracción retroactiva de XMLs de NF-e archivados de 2026.

Um sistema de extração em lote que lee nombres de campos semánticamente — "Base ICMS", "Alíquota ICMS", "Base CBS", "Alíquota CBS", etc. — maneja esta transición sin reconfiguración por proveedor. Las definiciones de columna permanecen iguales; la IA encuentra los campos de impuestos presentes en la versión actual del esquema XML. A medida que las actualizaciones de Nota Técnica agreguen nuevos campos y deprecen los antiguos durante los próximos siete años, la lógica de extracción se adapta al XML que llega — no a un modelo que deba reconstruirse cada vez que SEFAZ publique una nueva versión del layout.

Um Fluxo de Trabalho de Processamento em Lote de NF-e que Sobrevive ao Fechamento 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 múltiplos estados:

Este fluxo de trabalho pressupõe que sua ferramenta de extração em lote possa lidar com documentos XML e visuais na mesma sessão de upload — porque a AP brasileira raramente recebe um único formato exclusivamente. Se o seu processo atual exige um fluxo de trabalho separado para análise de XML e outro para OCR de PDF, a etapa de mesclagem na etapa 5 dobra o 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 lê semântica em vez de depender apenas da análise de XML. A extração semântica lê as tags estruturadas do XML de NF-e para dados que existem em ambos formatos (CNPJ, número de NF-e, totais, montantes de impostos) e lê visualmente o DANFE para casos onde apenas o documento impresso está disponível. A saída é mesclada em uma única planilha com colunas consistentes. Se sua ferramenta apenas analiza XML ou apenas faz OCR, você precisará de dois fluxos de trabalho separados e uma etapa de mesclagem manual.

O que acontece quando dois XMLs de NF-e têm o mesmo número de fatura, mas chaves de acesso diferentes?

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

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

ICMS-ST aparece no XML de NF-e como um grupo de impostos separado (<ICMSTot> no bloco de totais) com sua própria base, alíquota e montante. Debe ser extraído em colunas separadas ("Base ICMS-ST", "Montante ICMS-ST") — não mesclado com ICMS regular. ICMS-ST representa imposto já pago a montante por um contribuente substituto, e seu ERP o trata de forma diferente do ICMS regular para fins de crédito. Misturarlos em uma coluna "ICMS" sobrestimará seus créditos disponíveis.

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

Sim. Ao definir suas colunas de extração, inclua os campos que você precisa no nível de item de linha (NCM, CFOP, descrição, quantidade, preço unitário, total de linha e impostos por linha). A IA extrae cada item de linha de cada NF-e que corresponde à sua definição de columna. Se você só precisa de certas colunas — digamos, NCM + quantidade + CFOP, sem preço unitário — deixe as colunas não desejadas fora da sua definição. A extração produz apenas o que você solicita.

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

Em 2026, o schema do XML de NF-e agora inclui campos de CBS e IBS em alíquotas de teste (0,9% e 0,1%, respectivamente), além dos campos existentes de ICMS, PIS e COFINS. Essas alíquotas de teste são totalmente dedutíveis de PIS/COFINS, portanto a carga tributária líquida não muda. No entanto, os campos existem no XML e devem ser extraídos agora — quando a CBS substituir PIS/COFINS em alíquotas integrais em 2027, suas definições de colunas de extração em lote já estarão prontas. 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 encerramento 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 é possível reconstruir o registro fiscal completo que a SEFAZ solicitará. Boa 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.