L'IA peut-elle extraire des données des XML NF-e ? Oui — un parsing intelligent, pas de l'OCR

Oui. L'IA peut extraire des données des fichiers XML NF-e (Nota Fiscal Eletrônica) brésiliens — lisant le CNPJ fournisseur, les codes NCM des produits, les valeurs de taxes ICMS/IPI et les détails des lignes d'articles. Mais la NF-e est un cas particulier : les données sont déjà structurées en XML. L'extraction consiste ici à parser intelligemment le schéma XML et à mapper les champs vers des colonnes de feuille de calcul lisibles, et non à faire de l'OCR. Chaque NF-e de fournisseur suit le même schéma gouvernemental mais contient des champs facultatifs, des configurations fiscales et des éléments spécifiques à la version qui diffèrent, ce qui fait de la consolidation manuelle entre des dizaines de fournisseurs un casse-tête récurrent.

Comment fonctionne l’extraction XML des NF-e — et pourquoi vous en avez encore besoin

Si les données des NF-e sont déjà en XML, pourquoi ne pas écrire une feuille de style XSLT et en finir ? Parce que vous ne recevez jamais un seul format de NF-e.

Le système brésilien de NF-e — créé par Ajuste SINIEF 07/05 et désormais obligatoire pour presque toutes les transactions B2B — définit un schéma XML standard du gouvernement (actuellement en version 4.0). Chaque facture électronique partage la même structure racine : CNPJ et raison sociale de l’émetteur, données du destinataire, lignes d’articles avec classification NCM et codes CFOP, et quatre blocs fiscaux distincts pour ICMS (TVA d’État), IPI (taxe fédérale d’accise), PIS et COFINS.

Le problème apparaît quand vous recevez des XML de 30 fournisseurs en un mois. Chacun utilise un ERP différent — TOTVS, Sankhya, Omie, SAP Business One — et chacun remplit des champs facultatifs différents. L’un inclut les détails de fret ; un autre les omet. L’un utilise la NF-e 4.0 avec totalisation étendue ; un autre fonctionne encore en 3.10.

Les approches traditionnelles d’analyse XML — XSLT, scripts Python, importations Power Query — échouent lorsque des champs sont absents ou que les espaces de noms changent. L’IA lit le XML sémantiquement, identifiant les champs par ce qu’ils représentent, non par leur position dans l’arbre. C’est l’Extraction de colonnes personnalisées appliquée aux données structurées — vous définissez les colonnes de sortie souhaitées (« CNPJ du fournisseur », « Code NCM », « Valeur ICMS »), et l’IA localise les données correspondantes, quels que soient les champs facultatifs ou les différences de version.

Ce que l’IA réussit bien sur les XML NF-e

La nature structurée du XML NF-e rend la précision de l’extraction par IA plus élevée que sur les documents basés sur des images — dépassant souvent 99 % pour les champs standardisés de base. Les contraintes de format jouent en faveur de l’IA de trois manières.

Identifiants fiscaux CNPJ et CPF

Chaque XML NF-e contient le CNPJ de l’émetteur (Cadastro Nacional da Pessoa Jurídica — l’identifiant fiscal fédéral à 14 chiffres) dans une position fixe au sein du bloc <emit>. Le format rigide XX.XXX.XXX/XXXX-XX et le chemin XML prévisible rendent l’extraction pratiquement sans erreur. La précision de l’extraction du CNPJ sur les XML NF-e 3.10 et 4.0 dépasse 99,5 % — le format structuré élimine l’ambiguïté de reconnaissance de caractères qui affecte les factures papier scannées.

Codes NCM

Les codes NCM (Nomenclatura Comum do Mercosul) — la classification produit à 8 chiffres utilisée dans les pays du Mercosur — se trouvent dans leur propre balise <NCM> au sein de chaque ligne d'article. Pour les entreprises qui déposent la SPED Fiscal (Sistema Público de Escrituração Digital — le système de comptabilité fiscale numérique du Brésil), une extraction précise du NCM à partir des NF-e d'achat entrantes est cruciale : des codes erronés déclenchent des alertes de vérification. L'IA atteint une précision de 98 à 99 % car le code suit un motif numérique rigide à 8 chiffres dans une balise XML dédiée.

Valeurs fiscales (ICMS, IPI, PIS, COFINS)

Une seule NF-e peut comporter quatre taxes distinctes, chacune avec sa propre base de calcul, son taux et sa valeur finale — une charge fiscale inhabituellement lourde par rapport aux factures d'autres pays. Les sections fiscales sont des blocs XML clairement séparés, et l'IA fait correspondre chacune à sa colonne de sortie avec une grande fiabilité. Sur les NF-e où toutes les sections fiscales sont renseignées, la précision de la valeur ICMS atteint 99 %+ — supérieure à la saisie manuelle, qui introduit des erreurs de transposition.

Où l'IA a du mal avec le XML NF-e

La structure qui rend l'extraction NF-e précise crée également des cas particuliers. Trois scénarios réduisent la fiabilité.

Différences de schéma entre versions

La NF-e a évolué à travers plusieurs versions — 1.0, 2.0, 3.10 et 4.0 (actuelle). Chaque révision a ajouté, supprimé ou renommé des balises XML. Lorsque l'IA rencontre une ancienne NF-e 2.0 XML où un champ n'existe tout simplement pas, elle laisse correctement la cellule vide — mais cette cellule vide peut casser les formules de feuille de calcul en aval qui attendent une valeur. La solution : traiter les XML des versions plus anciennes séparément et appliquer une validation post-extraction pour signaler les champs manquants.

Champs facultatifs et NF-e de services uniquement

De nombreux champs NF-e sont facultatifs. Les factures de services omettent complètement les champs liés aux produits — pas de codes NCM, pas d'IPI. Lorsque l'IA traite un lot mixte, elle laisse correctement les colonnes inapplicables vides, mais si votre feuille de calcul suppose que chaque ligne a un code NCM, les lignes de services semblent incomplètes. Définissez des colonnes qui couvrent les deux scénarios — « Code NCM (NF-e produit uniquement) » — pour définir les attentes.

Workflows mixtes XML + DANFE

Le DANFE (Documento Auxiliar da NF-e) est le PDF imprimé qui accompagne la facture. De nombreux petits fournisseurs brésiliens n'envoient que le DANFE, sans le XML sous-jacent. Les PDF DANFE nécessitent une extraction par IA basée sur l'image, avec une précision de 90 à 95 % — inférieure aux 99 %+ obtenus par analyse directe du XML. La bonne pratique : demander le XML à chaque fournisseur et traiter les fichiers DANFE seuls comme un lot séparé, à confiance réduite.

Comment obtenir les meilleurs résultats de l'extraction XML NF-e

Cinq étapes qui font une différence mesurable lors du traitement des factures électroniques brésiliennes.

Définissez des noms de colonnes sémantiques, pas des chemins XML. Utilisez « CNPJ du fournisseur », « Code NCM », « Valeur ICMS » — pas de chaînes XPath comme /nfeProc/NFe/infNFe/emit/CNPJ. L'IA résout ces termes sémantiquement, trouvant le CNPJ qu'il soit à la position NF-e 4.0 ou à un emplacement légèrement différent NF-e 3.10. C'est l'Extraction de colonnes personnalisées appliquée aux données structurées.

Demandez le XML, pas les PDF DANFE. Ce simple changement d'habitude améliore la précision de 5 à 10 points de pourcentage. La loi brésilienne oblige les fournisseurs à fournir le XML — dites aux nouveaux fournisseurs : « Por favor, enviar o arquivo XML da NF-e juntamente com o DANFE. »

Regroupez les NF-e par version lors du traitement par lots. Séparez le XML NF-e 4.0 des fichiers plus anciens 3.10 ou 2.0. La version actuelle du schéma renseigne plus de champs — les traiter ensemble signifie que les lignes des versions plus anciennes auront plus de cellules vides, ce qui peut ressembler à des échecs d'extraction. Le regroupement par version vous permet de réviser chaque lot avec les bonnes attentes.

Utilisez des colonnes calculées pour la validation fiscale. Les taxes brésiliennes créent des contrôles d'audit intégrés. Définissez une colonne calculée vérifiant que valeur ICMS ≈ base ICMS × taux ICMS — l'IA signale les écarts lors de l'extraction plutôt que vous les découvriez plus tard dans votre système comptable.

Vérifiez ponctuellement le bloc des totaux. La section <total> contient les valeurs sommées définitives. Après extraction, vérifiez que les totaux des lignes correspondent au total déclaré dans le XML — un écart signale une erreur plus rapidement que de revoir chaque champ. Sur un XML propre, moins de 2 % des NF-e échouent à ce contrôle.

Scénarios concrets

Consolidation multi-fournisseurs de NF-e pour le SPED Fiscal

Un fabricant de taille moyenne à São Paulo reçoit 30 à 50 XML de NF-e par mois de la part de ses fournisseurs de matières premières — l'acier de Gerdau, les composants électriques de WEG, les emballages de fournisseurs locaux. Chaque NF-e comporte des taux d'ICMS différents (de 7 % à 18 % selon l'État d'origine) et un niveau de complétude variable. La saisie manuelle prenait deux journées complètes par mois à un employé de la comptabilité fournisseurs.

Grâce à l'extraction par IA, le téléchargement de tous les fichiers XML dans un lot produit une feuille de calcul consolidée avec les colonnes : CNPJ du fournisseur, numéro de NF-e, date d'émission, code NCM, description du produit, quantité, prix unitaire, base ICMS, valeur ICMS, total NF-e — prête à être importée dans l'ERP TOTVS de l'entreprise. Deux jours de travail deviennent trois minutes, et les valeurs d'ICMS sont recoupées avec le bloc des totaux du XML, ce qui permet de détecter les erreurs avant qu'elles n'atteignent le SPED. Pour le flux de travail au niveau des champs et les trois méthodes comparées en détail, consultez notre guide d'extraction NF-e XML vers Excel.

Extraction des codes NCM pour les droits d'importation

Une entreprise de logistique spécialisée dans les importations a besoin des codes NCM et des valeurs des produits issus des NF-e fournisseurs pour calculer les droits d'importation. Chaque NF-e contient 5 à 20 lignes d'articles avec des classifications différentes. L'IA extrait une ligne par article en quelques secondes — formatée selon le modèle de déclaration du transitaire.

FAQ

L'IA peut-elle distinguer l'ICMS, l'IPI, le PIS et la COFINS sur une même NF-e ?

Oui. Chaque taxe possède son propre bloc XML avec des éléments enfants uniques — l'ICMS comporte <orig> et <CST>, l'IPI comporte <clEnq>. L'IA les mappe proprement dans des colonnes de sortie distinctes, car la structure XML les différencie sans ambiguïté. C'est plus facile pour l'IA que l'extraction basée sur l'image, où les taxes apparaissent comme des rangées de chiffres indifférenciées.

L'IA fonctionne-t-elle avec des NF-e de différents États brésiliens ayant des taux d'ICMS différents ?

Oui. Le taux d'ICMS (alíquota) est indiqué dans le bloc <ICMS> de chaque NF-e. Que la NF-e porte le taux de 18 % de São Paulo ou celui de 19 % de Rio de Janeiro, l'IA lit le taux directement dans le XML. Les scénarios d'ICMS-ST (Substituição Tributária) inter-États sont également capturés, car le XML identifie explicitement les montants d'ICMS-ST.

L'IA peut-elle extraire des données de XML NF-e en portugais vers un tableur avec des colonnes en anglais ?

Oui. Définissez des colonnes de sortie en anglais — « Supplier CNPJ », « Invoice Total » — et l'IA fait correspondre les champs XML portugais aux en-têtes anglais. Les balises XML sont indépendantes de la langue, et la correspondance sémantique fonctionne entre les langues. Pour en savoir plus, consultez comment l'IA gère l'extraction multilingue.

Qu'en est-il des NFS-e (factures de services municipaux) ?

La NFS-e (Nota Fiscal de Serviços Eletrônica) est un document municipal distinct — chaque ville (prefeitura) a son propre schéma. Contrairement à la normalisation fédérale de la NF-e, les formats NFS-e varient selon la municipalité. L'IA peut aussi extraire des données des XML NFS-e, mais la variation des schémas par ville nécessite davantage de vérifications. La NF-e (fédérale, pour les marchandises) est fiable ; la NFS-e (municipale, pour les services) introduit plus de variables. Pour le volet services, consultez notre guide d'extraction NFS-e.

L'extraction par IA des XML NF-e est-elle conforme à la tenue des registres fiscaux brésiliens ?

L'extraction est une étape de transformation des données — elle ne modifie pas le XML d'origine, qui reste votre document fiscal légal. Les autorités fiscales brésiliennes exigent la conservation du XML NF-e signé numériquement pendant 5 ans (prazo decadencial, CTN Art. 173). L'extraction par IA crée un tableur dérivé ; le XML d'origine, signé numériquement, reste intact.

Quelle est la différence de précision entre l'extraction du XML NF-e et celle du PDF DANFE ?

C'est une toute autre catégorie. L'extraction du XML NF-e atteint plus de 99 % sur les champs essentiels, car les données se trouvent dans des balises XML sans ambiguïté. L'extraction du PDF DANFE — lecture de la représentation imprimée — tombe à 90-95 % car elle devient un problème de reconnaissance d'image : les variations de police, la qualité d'impression et les alignements de colonnes introduisent les mêmes erreurs que tout document scanné. Privilégiez toujours le XML au DANFE lorsque les deux sont disponibles.

En résumé

L'extraction du XML NF-e n'est pas une question de capacité de l'IA — c'est une décision de flux de travail. Le format structuré rend l'extraction plus précise que tout document basé sur une image, mais cette structure peut être trompeuse : « c'est juste du XML » donne l'impression que le problème de consolidation est plus simple qu'il ne l'est. Le vrai travail — faire correspondre des champs incohérents chez 30 fournisseurs, quatre versions de NF-e et plusieurs configurations fiscales — est une correspondance de motifs répétitive que l'IA automatise mieux que tout script XSLT ou macro Excel.

La question n'est pas de savoir si l'IA peut extraire le XML NF-e. C'est de savoir si vous voulez passer votre après-midi à tracer les chemins <ICMS><ICMSSN102><orig> dans 200 fichiers ou laisser l'IA faire correspondre les CNPJ, les codes NCM et les valeurs ICMS à un tableur en moins d'une minute.

Essayez avec vos fichiers XML NF-e →