50 XMLs de NF-e brésiliennes, un seul tableur
Comment le traitement par lots multi-fournisseurs élimine la réconciliation manuelle des taxes

Quand 50 XML de NF-e arrivent — Pourquoi le lot n'est pas « 50 fois la même chose »

Le traitement des NF-e brésiliennes a une particularité : les données sources sont déjà structurées. Contrairement aux factures papier de fournisseurs américains ou européens qui nécessitent une OCR pour être numérisées, chaque NF-e arrive sous forme de fichier XML déjà validé selon plus de 400 règles SEFAZ et signé numériquement avec un certificat ICP-Brasil. La qualité des données d'un seul XML de NF-e est quasi parfaite. Le problème du lot dans la comptabilité fournisseurs brésilienne n'est pas la précision de la saisie — c'est la cohérence des données entre fournisseurs.

Lorsque vous traitez 50 XML de NF-e provenant de 14 fournisseurs en un seul lot, quatre problèmes structurels apparaissent, que le traitement d'une facture unique ne révèle jamais :

Fragmentation des taux d'ICMS. L'ICMS brésilien est une TVA d'État dont les taux varient selon l'État du fournisseur, votre État, le sens de la transaction (intra-étatique vs inter-étatique) et — dans certains cas — la classification NCM du produit. Un lot de 50 XML de NF-e provenant de fournisseurs dans 7 États peut contenir des taux intra-étatiques de 17 %, 18 %, 19 %, 19,5 %, 20 % et 20,5 %, ainsi que des taux inter-étatiques de 4 %, 7 % ou 12 % selon les paires d'origine et de destination. Une colonne « Montant ICMS » dans votre tableur n'a aucun sens sans connaître le taux, l'État applicable et si la transaction est interne ou inter-étatique — car le même montant d'ICMS de 1 000 R$ peut correspondre à un taux de 17 % sur une base de 5 882 R$ ou à un taux de 12 % sur une base de 8 333 R$. Le module fiscal de votre ERP a besoin de cette distinction.

Incohérences de CFOP. Chaque article d'une NF-e comporte un code CFOP (Código Fiscal de Operações e Prestações) à 4 chiffres qui classe la nature fiscale de l'opération — 1.101 pour achat destiné à l'industrialisation dans le même État, 2.102 pour achat interétatique destiné à la revente, 3.101 pour importation. Le premier chiffre indique si l'opération est intra-étatique (1), interétatique (2) ou d'importation internationale (3). Lorsque le fournisseur A utilise le CFOP 1.101 pour un envoi de São Paulo vers votre entrepôt à São Paulo, et que le fournisseur B utilise le CFOP 2.102 pour un envoi interétatique du Minas Gerais, c'est correct et intentionnel. Mais si le fournisseur C utilise le CFOP 1.101 pour un envoi provenant de Rio de Janeiro — une opération interétatique — le CFOP est en contradiction avec les données d'État dans les blocs <ide> et <emit> du XML. Cette discordance créera un drapeau d'audit dans le SPED EFD (Escrituração Fiscal Digital), le système fédéral de comptabilité numérique qui recoupe les codes CFOP sur l'ensemble de la chaîne d'approvisionnement. Dans un lot de 50 factures, 3 à 5 discordances sont courantes — et les trouver manuellement implique de vérifier le CFOP de chaque XML par rapport à la paire d'États d'origine-destination.

Échec de la détection des doublons à partir du seul numéro de facture. Dans la plupart des systèmes AP, la détection des doublons repose sur le fournisseur + le numéro de facture. Cette logique échoue avec la NF-e brésilienne car le numéro de la note (número da nota) n'est unique qu'au sein d'une seule série d'un fournisseur. Le fournisseur A peut émettre la NF-e #1523 dans la série 001, tandis que le fournisseur B émet également la NF-e #1523 dans sa série 001. Même le même fournisseur peut émettre des numéros de facture identiques dans des séries différentes. L'identifiant global unique est la chave de acesso à 44 chiffres — mais la plupart des outils d'extraction par lot ne l'extraient pas, ou l'extraient sans comprendre son rôle de clé de dédoublonnage. Sans la chave de acesso, deux factures différentes de deux fournisseurs différents portant le même numéro de facture seront signalées comme des doublons et l'une sera supprimée — ou pire, une facture soumise à nouveau avec une chave de acesso corrigée (indiquant un événement de lettre de correction CCe) ne sera pas reconnue comme un remplacement.

Sources de formats mixtes. Dans un lot de 50 factures de fournisseurs brésiliens, vous obtenez rarement 50 XML propres. Certains fournisseurs — généralement les petits fabricants ou producteurs agricoles — n'envoient que le DANFE imprimé sous forme de PDF ou de scan. Quelques-uns envoient le XML mais joignent un DANFE scanné avec des annotations manuscrites. Un fournisseur industriel de taille moyenne peut envoyer le XML pour la NF-e principale mais le CT-e de fret (Conhecimento de Transporte Eletrônico) en PDF. Le flux de traitement par lot doit gérer tous ces cas en une seule passe — extraire les données structurées du XML lorsque disponible et lire le document visuel lorsque le XML est manquant — et fusionner le tout dans des colonnes cohérentes.

Ces quatre problèmes n'existent pas pour une seule facture. À 50, les quatre se déclenchent simultanément — et les résoudre est ce qui distingue un flux de traitement par lot d'une « extraction unique, répétée 50 fois ».

La matrice des taux ICMS dans 7 États — Pourquoi une seule colonne « Taxe » ne fonctionne pas

As alíquotas internas de ICMS no Brasil mudaram significativamente em 2024, em parte em antecipação à reforma tributária que 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:

Combinez ces paliers de taux interétatiques avec les 11 changements de taux au niveau des États ci-dessus, et un lot de XML de NF-e provenant de fournisseurs de 7 États peut facilement contenir 5 taux ICMS différents — chacun devant être identifié, séparé par type et imputé au bon compte fiscal dans votre ERP. Les outils qui extraient l'ICMS comme un seul nombre sans capturer le taux, l'État d'origine et le type de transaction du XML produisent un tableur qui crée plus de travail de rapprochement qu'il n'en économise.

C'est là que l'extraction directe de la structure du XML de la NF‑e — et non l'OCR du DANFE — fait la différence en volume. Le bloc <imposto> du XML contient des groupes d'éléments distincts pour ICMS, IPI, PIS et COFINS, chacun avec la base taxable (vBC), le taux (pICMS, pIPI, etc.) et le montant (vICMS, vIPI, etc.) au niveau de la ligne. Une extraction par nom de colonne qui mappe ces champs structurés — « Base ICMS », « Taux ICMS (%) », « Montant ICMS », « Montant IPI », « Montant PIS », « Montant COFINS » — dans des colonnes distinctes du tableur produit un tableau où chaque montant de taxe est traçable jusqu'à son taux et sa base, sans recalcul manuel. Pour une analyse détaillée de la structure XML de la NF‑e et du mappage des champs, voir le guide complet d'extraction XML de la NF‑e.

Cohérence des codes CFOP entre fournisseurs — le drapeau de contrôle que personne ne vérifie en lot

Les codes CFOP sont des classifications d'opérations fiscales à 4 chiffres intégrées dans chaque ligne de la NF‑e. Il existe plus de 500 codes CFOP définis par le fisc brésilien, organisés par le premier chiffre :

Dans une NF-e unique, une divergence de CFOP est facile à repérer : si l'État du fournisseur est le Minas Gerais et que votre entreprise est à São Paulo, chaque code CFOP doit commencer par 2 (entrée interétatique). Si une ligne affiche le CFOP 1.101 — intraétatique — il y a une erreur de données. À grande échelle, sur 50 factures de plusieurs fournisseurs, ce type de validation devient essentiel et complexe. Un fournisseur peut utiliser correctement le CFOP 1.101 pour ses expéditions locales (vers ses propres clients), mais doit utiliser le 2.101 lorsqu'il vous livre au-delà des frontières de l'État. Si son ERP a auto-rempli le mauvais CFOP, vous héritez d'un risque de contrôle que le SPED EFD détectera — car le système de comptabilité numérique croise les enregistrements de CFOP côté acheteur et côté vendeur pour chaque transaction. Une divergence entre votre enregistrement de CFOP entrant et celui sortant correspondant du fournisseur génère un drapeau de contrôle automatique.

La validation par lot des CFOP consiste à vérifier trois relations pour chaque ligne du lot :

1. Primeiro dígito vs par de estados. O primeiro dígito do CFOP deve corresponder à situação de mesmo estado (1/5) ou 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 conforme 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 que sugere insumo industrial combinado com um NCM de produto acabado para 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 Nativa 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 cada NF-e emitida no Brasil, para sempre. Não é apenas 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), código aleatório de colisão (8) e um dígito verificador módulo 11 (1). Todo XML de NF-e contém essa chave no atributo <infNFe Id="NFe[chave]"> e no elemento <chNFe>. É o mais próximo de um identificador globalmente único de nota fiscal 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 por ali. 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 delas como duplicata.
• 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. Unicité dans le lot. Deux lignes ne doivent pas partager la même chave de acesso. Si c'est le cas, la même NF-e a été téléchargée deux fois — supprimez la ligne en double et signalez l'occurrence.
2. Unicité du numéro de facture par fournisseur × série. Regroupez par CNPJ + série + numéro de facture. Si la même combinaison apparaît deux fois avec des chaves de acesso différentes, l'une est probablement une correction — la chave avec l'horodatage d'émission le plus récent prévaut.
3. Vérification SEFAZ pour les factures de valeur élevée. Pour les factures dépassant un seuil de matérialité, utilisez la chave de acesso pour interroger le portail de consultation publique de SEFAZ ou une API tierce comme la recherche NF-e de TF Fiscal afin de vérifier le statut d'autorisation (Autorizada/Cancelada/Denegada). Une NF-e annulée dans votre lot signifie que le fournisseur l'a réémise — et vous avez besoin de la chave de remplacement.

Les 44 chiffres peuvent sembler intimidants pour le personnel AP non brésilien. Mais ils constituent la clé de déduplication la plus fiable disponible dans tout régime de facturation électronique au monde. Ne pas les utiliser dans le traitement par lots revient à avoir un numéro de sécurité sociale et à identifier les gens par leur prénom.

Le lot mixte XML + DANFE — Quand certains fournisseurs envoient la facture complète et d'autres uniquement le papier

Les grands fournisseurs brésiliens — en particulier les fabricants industriels et les distributeurs utilisant SAP, TOTVS Protheus ou Oracle — envoient le XML de la NF-e par routine. Il est généré par leur ERP, signé par leur certificat ICP-Brasil et transmis automatiquement à SEFAZ. L'envoyer à l'acheteur avec la DANFE est une opération en un clic.

Les petits fournisseurs — coopératives agricoles, prestataires locaux, certains fournisseurs de matériaux de construction — n'ont pas toujours l'infrastructure ERP nécessaire pour gérer la transmission XML. Ils impriment le DANFE, le remettent au chauffeur du camion, et c'est le seul document que l'acheteur reçoit. La facture est réelle, elle a été autorisée par la SEFAZ (le protocole d'autorisation est imprimé sur le DANFE), mais le service AP récepteur ne dispose que d'un PDF scanné ou d'une photo du document papier.

Un flux de travail AP par lots qui ne gère que le XML ou que le PDF oblige l'équipe AP à diviser ses factures mensuelles en deux pipelines de traitement distincts — l'un pour le XML structuré, l'autre pour les DANFE scannés — puis à fusionner manuellement les résultats en une seule écriture comptable. Le coût de cette fragmentation est réel : sessions de téléchargement séparées, passes de vérification distinctes, et une étape de rapprochement finale pour s'assurer que toutes les factures d'un même fournisseur (certaines en XML, d'autres en PDF) aboutissent dans le même lot AP.

Extraction de colonnes personnalisées — l'approche d'ImageToTable.ai qui extrait les données par sens du champ plutôt que par coordonnées de modèle — traite les deux sources en un seul téléchargement par lots. Vous définissez vos noms de colonnes une fois : « Chave de Acesso », « CNPJ du fournisseur », « Nom du fournisseur », « Numéro NF-e », « Série », « Date d'émission », « CFOP », « NCM », « Description de l'article », « Quantité », « Prix unitaire », « Total ligne », « Base ICMS », « Taux ICMS », « Montant ICMS », « Montant IPI », « Montant PIS », « Montant COFINS », « Valeur totale NF-e ». L'IA lit les données structurées des fichiers XML où les champs sont lisibles par machine, et extrait les mêmes champs des PDF DANFE scannés en comprenant visuellement la signification de chaque étiquette — quelle que soit la mise en page. Les deux sources fusionnent dans le même tableur, avec les mêmes colonnes, en un seul lot.

O ganho prático 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, quando proveniente de um DANFE escaneado, é lida a partir do código de barras de 44 dígitos no canto superior direito do documento impresso. Ambas as entradas caem na mesma coluna, permitindo a mesma lógica de deduplicação descrita acima. Sem um fluxo de lote unificado, a chave de acesso do lote de XML e a chave de acesso do lote de DANFEs escaneados 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 do 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 oito anos de transição. Até 2033, cinco tributos legados (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 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 conterão simultaneamente campos de tributos legados (ICMS, IPI, PIS, COFINS) e novos campos tributários (CBS, IBS) — o que significa que o XML de NF-e, já complexo com mais de 500 campos, está prestes a se tornar ainda maior. Veja o cronograma que afeta o design da extração em lote:

L'implication pratique pour l'extraction par lots en 2026 : si vous construisez des définitions de colonnes maintenant, incluez les colonnes CBS et IBS à côté de vos colonnes ICMS et PIS/COFINS — même aux taux de test. Les données sont dans le XML aujourd'hui. Les extraire ne coûte rien. Les avoir dans votre tableur lorsque la transition s'accélérera en 2027 signifie que vos données historiques par lots contiennent déjà la base pour le reporting basé sur CBS, sans avoir à réextraire rétroactivement les XML NF-e archivés de 2026.

Un système d'extraction par lots qui lit les noms de champs sémantiquement — « Base ICMS », « Taux ICMS », « Base CBS », « Taux CBS », etc. — gère cette transition sans reconfiguration par fournisseur. Les définitions de colonnes restent les mêmes ; l'IA trouve les champs fiscaux présents dans la version actuelle du schéma XML. Au fur et à mesure que les mises à jour de la Nota Técnica ajoutent de nouveaux champs et en déprécient d'anciens au cours des sept prochaines années, la logique d'extraction s'adapte au XML qui arrive — et non à un modèle qui doit être reconstruit chaque fois que SEFAZ publie une nouvelle version de mise en page.

Un Workflow de Traitement par Lots NF-e qui Survit à la Fin de Mois

Une fois les problèmes structurels cartographiés, voici une séquence de traitement par lots conçue pour la réalité de la AP brésilienne multi-fournisseurs et multi-états :

Ce workflow suppose que votre outil d'extraction par lots peut gérer les documents XML et visuels dans la même session de téléchargement — car la AP brésilienne reçoit rarement un format exclusivement. Si votre processus actuel nécessite un workflow séparé pour l'analyse XML et un autre pour l'OCR PDF, l'étape de fusion à l'étape 5 double votre temps de traitement et introduit un risque de mappages de colonnes incohérents entre les deux pipelines.

Questions Fréquentes

Le traitement par lots peut-il gérer les XML NF-e et les PDF DANFE dans le même téléchargement ?

Oui — si l'outil d'extraction lit la sémantique plutôt que de se fier uniquement à l'analyse XML. L'extraction sémantique lit les balises structurées du XML de la NF-e pour les données présentes dans les deux formats (CNPJ, numéro de NF-e, totaux, montants de taxes) et lit visuellement le DANFE lorsque seul le document imprimé est disponible. La sortie fusionne en un seul tableur avec des colonnes cohérentes. Si votre outil ne fait qu'analyser le XML ou uniquement de l'OCR, vous aurez besoin de deux flux de travail distincts et d'une étape de fusion manuelle.

Que se passe-t-il lorsque deux XML de NF-e ont le même numéro de facture mais des chaves de acesso différentes ?

C'est un scénario légitime — généralement une NF-e corrigée réémise après un événement CCe, ou deux documents NF-e de séries différentes avec le même numéro séquentiel. La chave de acesso est unique dans les deux cas. Votre validation par lot doit regrouper par chave de acesso (et non par numéro de facture) pour la déduplication, et conserver la relation entre numéro de facture, série et chave à des fins d'audit. Si le même CNPJ + série + numéro de facture apparaît avec deux chaves de acesso différentes, vérifiez les horodatages d'émission — la chave la plus récente remplace la précédente.

Comment gérer l'ICMS-ST (substitution fiscale) dans un lot ?

L'ICMS-ST apparaît dans le XML de la NF-e comme un groupe de taxes distinct (<ICMSTot> dans le bloc des totaux) avec sa propre base, taux et montant. Il doit être extrait dans des colonnes séparées (« Base ICMS-ST », « Montant ICMS-ST ») — sans être fusionné avec l'ICMS normal. L'ICMS-ST représente une taxe déjà payée en amont par un contribuable substitut, et votre ERP le traite différemment de l'ICMS normal à des fins de crédit. Les mélanger dans une seule colonne « ICMS » gonflera vos crédits disponibles.

Puis-je extraire uniquement des lignes spécifiques d'une NF-e au lieu de toutes les lignes ?

Oui. Lorsque vous définissez vos colonnes d'extraction, incluez les champs nécessaires au niveau des lignes (NCM, CFOP, description, quantité, prix unitaire, total ligne et taxes par ligne). L'IA extrait chaque ligne de chaque NF-e correspondant à votre définition de colonne. Si vous n'avez besoin que de certaines colonnes — par exemple, NCM + quantité + CFOP, sans le prix unitaire — laissez les colonnes inutiles hors de votre définition. L'extraction ne produit que ce que vous demandez.

La réforme fiscale de 2026 modifie-t-elle ce que je dois extraire des XML de NF-e ?

En 2026, le schéma XML de la NF-e inclut désormais les champs CBS et IBS à des taux tests (0,9 % et 0,1 % respectivement), en plus des champs ICMS, PIS et COFINS existants. Ces taux tests sont entièrement déductibles du PIS/COFINS, donc la charge fiscale nette ne change pas. Cependant, les champs existent dans le XML et doivent être extraits dès maintenant — lorsque le CBS remplacera le PIS/COFINS aux taux pleins en 2027, vos définitions de colonnes d'extraction par lots seront déjà en place. Le calendrier de la réforme fiscale est codifié dans la Loi Complémentaire 214/2025 et l'analyse 2025 de l'OCDE sur la réforme.

Combien de temps dois-je conserver les XML de NF-e et les enregistrements d'extraction ?

La législation fiscale brésilienne exige que les XML de NF-e et les documents fiscaux associés soient archivés pendant au moins cinq ans à compter de la fin de l'exercice fiscal au cours duquel la transaction a eu lieu. Cela s'applique à la fois aux XML originaux reçus des fournisseurs et à vos enregistrements d'extraction. Le DANFE n'est pas un substitut légalement suffisant au XML lors d'un audit — si vous n'avez conservé que le DANFE scanné et jeté le XML, vous ne pouvez pas reconstituer l'intégralité du dossier fiscal que SEFAZ demandera. Bonne pratique : archivez les XML tels quels et conservez le tableur d'extraction comme un enregistrement séparé et consultable pour le rapprochement interne.