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

Quand 50 XML de NF-e arrivent — pourquoi le traitement par lots n'est pas « un traitement unique répété 50 fois »

Le traitement des NF-e brésiliennes est inhabituel à un égard : 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'une NF-e XML individuelle est quasi parfaite. Le problème du traitement par lots dans la comptabilité fournisseurs brésilienne n'est pas la précision de la capture des données — c'est la cohérence des données entre les fournisseurs.

Lorsque vous traitez 50 XML de NF-e provenant de 14 fournisseurs en un seul lot, quatre problèmes structurels émergent que le traitement de factures individuelles ne révèle jamais :

Fragmentation des taux d'ICMS. L'ICMS brésilien est une TVA au niveau des États, avec des taux qui diffèrent selon l'État du fournisseur, votre État, le sens de la transaction (intra-étatique ou inter-étatique) et — dans certains cas — la classification produit NCM. 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 %, plus des taux inter-étatiques de 4 %, 7 % ou 12 % selon les paires d'origine et de destination. Une colonne « Montant ICMS » dans votre feuille de calcul n'a aucun sens à moins que vous connaissiez également 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 signifier 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.

Écarts de cohérence CFOP. Chaque ligne d'article d'une NF-e porte un code CFOP à 4 chiffres (Código Fiscal de Operações e Prestações) qui classe la nature fiscale de la transaction — 1.101 pour l'achat destiné à l'industrialisation dans le même État, 2.102 pour l'achat inter-étatique destiné à la revente, 3.101 pour l'importation. Le premier chiffre indique si la transaction est intra-étatique (1), inter-étatique (2) ou une importation internationale (3). Lorsque le fournisseur A utilise le CFOP 1.101 pour une expédition de São Paulo vers votre entrepôt de São Paulo, et que le fournisseur B utilise le CFOP 2.102 pour une expédition inter-étatique du Minas Gerais, c'est correct et délibéré. Mais si le fournisseur C utilise le CFOP 1.101 pour une expédition originaire de Rio de Janeiro — une transaction inter-étatique — le CFOP est en désaccord avec les données d'État dans les blocs <ide> et <emit> du XML. Cette incohérence 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 incohérences sont courantes — et les trouver manuellement signifie vérifier le CFOP de chaque XML par rapport à sa 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 de comptabilité fournisseurs, 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 facture (número da nota) n'est unique qu'au sein d'une seule série d'un fournisseur donné. Le fournisseur A peut émettre la NF-e n° 1523 dans la série 001, tandis que le fournisseur B émet également la NF-e n° 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 unique au niveau mondial est la chave de acesso à 44 chiffres — mais la plupart des outils d'extraction par lots ne l'extraient pas, ou l'extraient sans comprendre son rôle de clé de déduplication. 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 aux formats mixtes. Dans un lot de 50 factures de fournisseurs brésiliens, vous obtenez rarement 50 XML propres. Certains fournisseurs — généralement des petits fabricants ou des 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 lots doit gérer tous ces cas en une seule passe — en extrayant les données structurées du XML lorsqu'il est disponible et en lisant le document visuel lorsque le XML est manquant — et en fusionnant 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 lots d'une « extraction unique, répétée 50 fois ».

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

Les taux internes d'ICMS au Brésil ont considérablement changé en 2024, en partie en prévision de la réforme fiscale qui remplacera éventuellement l'ICMS par le nouvel IBS (Imposto sobre Bens e Serviços) entre 2029 et 2033. Onze États brésiliens ont modifié leurs taux standard d'ICMS l'année dernière :

La conséquence pratique pour le traitement par lots : si votre base de fournisseurs couvre plus de deux États brésiliens, votre feuille de calcul de lot doit suivre l'ICMS au niveau taux × État × type de transaction — et non dans une seule colonne qui additionne toutes les valeurs d'ICMS. Un NF-e d'un fournisseur du Pernambouc (20,5 % intrastat) et un NF-e d'un fournisseur de São Paulo (18 % intrastat) auront un traitement ICMS différent dans votre ERP, même si la colonne du montant ICMS affiche le même chiffre.

Les taux interétatiques ajoutent une deuxième dimension, codifiée par la loi fiscale brésilienne :

Combinez ces niveaux de taux interétatiques avec les 11 changements de taux au niveau des États mentionnés ci-dessus, et un lot de XML NF-e provenant de fournisseurs dans 7 États peut facilement contenir 5 taux ICMS différents — chacun devant être identifié, séparé par type et comptabilisé dans le bon compte fiscal de 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 à partir du XML produisent une feuille de calcul qui crée plus de travail de rapprochement qu'elle n'en économise.

C'est là que l'extraction directe à partir de la structure du XML NF-e — et non l'OCR du DANFE — porte ses fruits en volume. Le bloc <imposto> du XML contient des groupes d'éléments distincts pour ICMS, IPI, PIS et COFINS, chacun avec la base de calcul (vBC), le taux (pICMS, pIPI, etc.) et le montant (vICMS, vIPI, etc.) au niveau de la ligne. Une extraction basée sur les noms de colonnes qui mappe ces champs structurés — « Base ICMS », « Taux ICMS (%) », « Montant ICMS », « Montant IPI », « Montant PIS », « Montant COFINS » — dans des colonnes de feuille de calcul distinctes produit un tableau où chaque montant fiscal est traçable jusqu'à son taux et sa base, sans recalcul manuel. Pour une ventilation détaillée de la structure du XML NF-e et du mappage des champs, consultez le guide complet d'extraction XML NF-e.

Cohérence des codes CFOP entre fournisseurs — le signal d'audit que personne ne vérifie en traitement par lots

Les codes CFOP sont des classifications d'opérations fiscales à 4 chiffres intégrées à chaque ligne d'article de la NF-e. Plus de 500 codes CFOP sont définis par les autorités fiscales brésiliennes, organisés selon le premier chiffre :

Dans une NF-e unique, une incohérence 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 interstate). Si une ligne d'article affiche le CFOP 1.101 — intrastate — il y a une erreur de données. À grande échelle, sur 50 factures provenant de plusieurs fournisseurs, ce type de validation devient essentiel et non trivial. Un fournisseur peut utiliser correctement le CFOP 1.101 pour ses expéditions locales (vers ses propres clients), mais devrait utiliser le 2.101 lors de l'expédition vers vous au-delà des frontières de l'État. Si son ERP a pré-rempli le mauvais CFOP, vous héritez d'une exposition d'audit que SPED EFD détectera — car le système de comptabilité numérique croise les enregistrements CFOP côté acheteur et côté vendeur pour chaque transaction. Une incohérence entre votre enregistrement CFOP entrant et l'enregistrement sortant correspondant du fournisseur génère un signal d'audit automatique.

La validation CFOP par lots consiste à vérifier trois relations pour chaque ligne d'article du lot :

1. Premier chiffre vs paire d'États. Le premier chiffre du CFOP doit correspondre au fait que le fournisseur et l'acheteur se trouvent dans le même État (1/5) ou dans des États différents (2/6). Extrayez le code IBGE de l'État des blocs <emit> et <dest> — codes 35 (SP), 33 (RJ), 31 (MG), 41 (PR), etc. — et validez le préfixe du CFOP par rapport à la détermination même-État/États-différents.
2. Cohérence du suffixe CFOP entre opérations similaires. Si le fournisseur A utilise le CFOP 2.102 (achat interstate pour revente) et le fournisseur B utilise le CFOP 2.101 (achat interstate pour industrialisation) pour le même type de produit, au moins l'un d'eux est erroné — le suffixe du CFOP doit refléter l'objet commercial réel de la transaction.
3. Aucune contradiction CFOP-NCM. Le CFOP encode la nature de l'opération, le NCM encode la classification du produit. Un CFOP suggérant un intrant industriel associé à un NCM pour un produit fini de consommation est un signal d'alarme — cela signifie que soit le CFOP, soit le NCM est incorrect, et les deux affectent le traitement fiscal.

La Chave de Acesso à 44 chiffres — la clé de déduplication intégrée du Brésil que la plupart des outils de traitement par lot ignorent

La chave de acesso est une chaîne de 44 chiffres qui identifie de manière unique chaque NF-e émise au Brésil, pour toujours. Ce n'est pas simplement un numéro de référence — c'est un identifiant structuré qui encode l'état de l'émetteur (2 premiers chiffres, selon le code IBGE), l'année-mois d'émission (4 suivants), le CNPJ de l'émetteur (14 suivants), le modèle de document (2), la série (3), le numéro séquentiel (9), le type d'émission (1), un code aléatoire anti-collision (8) et un chiffre de contrôle modulo-11 (1). Chaque XML de NF-e porte cette clé dans son attribut <infNFe Id="NFe[chave]"> et dans l'élément <chNFe>. C'est ce qui se rapproche le plus d'un identifiant de facture globalement unique que tout système fiscal au monde puisse fournir.

Pourtant, la plupart des outils de traitement par lot pour la comptabilité fournisseurs extraient une colonne « Numéro de facture » et s'en contentent. Au Brésil, cette colonne ne suffit pas :

• Le fournisseur A peut émettre la NF-e n° 1523 en série 001 et la NF-e n° 1523 en série 002 — même numéro de facture, deux documents fiscaux complètement différents, uniquement distinguables par la série et la chave de acesso.
• Le fournisseur B peut émettre la NF-e n° 1523 dans sa propre série 001 — même numéro de facture que le fournisseur A, fournisseur différent, transaction différente — et une simple vérification de doublon fournisseur+numéro_de_facture supprimera l'une des deux comme doublon.
• Le système d'annulation et de correction de la SEFAZ repose sur la chave de acesso. Lorsqu'un fournisseur émet une Carta de Correção (CCe) pour corriger une erreur de saisie dans la NF-e d'origine, la chave de acesso d'origine reste valide — mais l'historique des événements rattaché à cette chave enregistre la correction. Un outil de traitement par lot qui ne suit pas la chave ne peut pas distinguer la version d'origine de la version corrigée.

Dans un lot de 50 XML de NF-e, extrayez la chave de acesso dans sa propre colonne. Mettez ensuite en œuvre trois vérifications :

1. Unicité au sein du lot. Aucune ligne ne doit partager la même chave de acesso. Si c'est le cas, la même NF-e a été téléversée deux fois — supprimez la ligne en double et signalez l'occurrence.
2. Unicité du numéro de facture au sein du fournisseur × série. Regroupez par CNPJ + série + numéro de facture. Si la même combinaison apparaît deux fois avec des chave de acessos 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 consultation 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 semblent 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 niveau mondial. Ne pas les utiliser dans le traitement par lots, c'est comme avoir un numéro de sécurité sociale et identifier les gens par leur prénom.

Le lot mixte XML + DANFE — lorsque 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 le DANFE est une opération en un clic.

Les petits fournisseurs — coopératives agricoles, prestataires de services locaux, certains fournisseurs de matériaux de construction — peuvent ne pas disposer de 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 voit. La facture est réelle, elle a été autorisée par 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 photographie du document papier.

Un flux de travail AP par lots qui ne gère que le XML ou uniquement le PDF oblige l'équipe AP à diviser son flux mensuel de factures en deux pipelines de traitement distincts — un pour le XML structuré, un pour les DANFE scannés — puis à fusionner manuellement les sorties en une seule écriture de grand livre. Le coût de la fragmentation est réel : sessions de téléversement séparées, passes de revue séparées, et une étape de rapprochement à la fin pour garantir que toutes les factures du 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 consistant à extraire des données par signification des champs plutôt que par coordonnées de modèle — traite les deux sources en un seul lot. Vous définissez vos noms de colonnes une seule fois : « Chave de Acesso », « CNPJ du fournisseur », « Nom du fournisseur », « Numéro NF-e », « Série », « Date d'émission », « CFOP », « NCM », « Description de la ligne », « Quantité », « Prix unitaire », « Total de la 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 libellé — indépendamment de la mise en page. Les deux sources fusionnent dans le même tableur, avec les mêmes colonnes, en un seul lot.

L'avantage pratique ne réside pas seulement dans la rapidité — c'est la cohérence. La colonne chave de acesso des fichiers XML est extraite directement de l'élément <chNFe>. La même colonne issue d'un scan DANFE est lue dans la zone du code-barres à 44 chiffres située dans le coin supérieur droit du document imprimé. Les deux entrées aboutissent dans la même colonne, permettant la même logique de déduplication décrite ci-dessus. Sans un flux de travail par lots unifié, la chave de acesso du lot XML et celle du lot DANFE scanné vivent dans des tableurs séparés — et la détection des doublons entre eux est manuelle.

La transition de la réforme fiscale 2026–2033 — double conformité en un seul lot

La réforme fiscale sur la consommation au Brésil — adoptée par l'amendement constitutionnel 132 de décembre 2023 et réglementée par la loi complémentaire 214 de janvier 2025 — restructure l'ensemble du système d'imposition indirecte du pays sur une transition de huit ans. D'ici 2033, cinq impôts existants (PIS, COFINS, IPI, ICMS et ISS) seront remplacés par un système de TVA dual : la CBS fédérale (Contribuição sobre Bens e Serviços) et l'IBS étatique-municipal (Imposto sobre Bens e Serviços), plus une taxe sélective (IS) sur les biens nocifs pour la santé et l'environnement. La transition a débuté le 1er janvier 2026.

Pour les équipes AP traitant des lots de NF-e brésiliens, la préoccupation opérationnelle immédiate est la double conformité dans le schéma XML. Pendant les années de transition, les XML NF-e contiendront à la fois les champs fiscaux existants (ICMS, IPI, PIS, COFINS) et les nouveaux champs fiscaux (CBS, IBS) simultanément — ce qui signifie que le XML NF-e, déjà complexe avec plus de 500 champs, va s'agrandir. Voici le calendrier qui affecte la conception de l'extraction par lots :

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

Un système d'extraction par lots qui lit les noms de champs de manière sémantique — « 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. À mesure que les mises à jour de la Nota Técnica ajoutent de nouveaux champs et déprécient les anciens au cours des sept prochaines années, la logique d'extraction s'adapte au XML reçu — et non à un modèle qui doit être reconstruit à chaque fois que SEFAZ publie une nouvelle version de mise en page.

Un flux de traitement par lots NF-e qui survit à la fin du 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 comptabilité fournisseurs multi-fournisseurs et multi-états au Brésil :

Ce flux de travail suppose que votre outil d'extraction par lot peut traiter les documents XML et visuels dans la même session de téléversement — car la AP brésilienne reçoit rarement un seul format exclusivement. Si votre processus actuel exige un flux de travail distinct pour l'analyse XML et un autre pour l'OCR des PDF, l'étape de fusion à l'étape 5 double votre temps de traitement et introduit un risque de correspondances de colonnes incohérentes entre les deux pipelines.

Questions fréquemment posées

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

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 NF-e pour les données présentes dans les deux formats (CNPJ, numéro NF-e, totaux, montants de taxes) et lit visuellement le DANFE pour les cas où seul le document imprimé est disponible. La sortie fusionne le tout dans une seule feuille de calcul avec des colonnes cohérentes. Si votre outil analyse uniquement le XML ou ne fait que 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 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 lots doit regrouper par chave de acesso (et non par numéro de facture) pour la déduplication, et préserver 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, examinez les horodatages d'émission — la chave la plus récente remplace la plus ancienne.

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

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

Puis-je extraire uniquement des postes de ligne spécifiques d'une NF-e au lieu de tous les postes de ligne ?

Oui. Lors de la définition de vos colonnes d'extraction, incluez les champs dont vous avez besoin au niveau du poste de ligne (NCM, CFOP, description, quantité, prix unitaire, total de ligne et taxes par ligne). L'IA extrait chaque poste de ligne de chaque NF-e qui correspond à votre définition de colonnes. Si vous n'avez besoin que de certaines colonnes — par exemple, NCM + quantité + CFOP, sans 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 change-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 de test (0,9 % et 0,1 %, respectivement) en plus des champs existants ICMS, PIS et COFINS. Ces taux de test sont entièrement déductibles du PIS/COFINS, de sorte que la charge fiscale nette ne change pas. Cependant, les champs existent dans le XML et doivent être extraits dès maintenant — lorsque la CBS remplacera le PIS/COFINS aux taux complets 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 une durée minimale de 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 ne constitue pas un substitut juridiquement 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 la SEFAZ demandera. Bonne pratique : archivez les XML tels quels et conservez le tableur d'extraction comme un enregistrement distinct et consultable pour le rapprochement interne.