L'IA peut-elle extraire des données d'un XML NF-e ?
Oui — Parsing intelligent, pas d'OCR
Oui. L'IA peut extraire des données des fichiers XML NF-e (Nota Fiscal Eletrônica) brésiliens — en lisant le CNPJ du fournisseur, les codes NCM des produits, les valeurs fiscales 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 à analyser intelligemment le schéma XML et à mapper les champs vers des colonnes de tableur 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 rendent la consolidation manuelle entre des dizaines de fournisseurs un casse-tête récurrent.
Points clés
- Les données XML NF-e normalisées par le gouvernement devraient être trivialement lisibles par machine — pourtant, la plupart des équipes financières brésiliennes passent encore deux jours par mois à consolider manuellement les champs de 30 fournisseurs qui utilisent chacun un ERP différent.
- Un script d'analyse NF-e qui fonctionne parfaitement sur la version 4.0 échoue silencieusement sur la version 2.0 car le même champ n'existe tout simplement pas — le XML est valide mais le champ est absent, et le script n'a aucun moyen de signaler ce qu'il ne trouve pas.
- L'extraction sémantique lit les champs par leur signification — CNPJ du fournisseur ou Valeur ICMS — et non par leur emplacement dans l'arborescence XML, de sorte qu'un seul ensemble de définitions de colonnes extrait les mêmes données de chaque NF-e, quel que soit le fournisseur ou la version utilisée.
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.
/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.<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 chaque mois 30 à 50 XML de NF-e de ses fournisseurs de matières premières — acier de Gerdau, composants électriques de WEG, emballages de fournisseurs locaux. Chaque NF-e comporte des taux d'ICMS différents (7 % à 18 % selon l'État d'origine) et une complétude variable des champs. La saisie manuelle prenait deux jours complets par mois à un assistant comptable.
Avec l'extraction par IA, le téléchargement de tous les fichiers XML en un lot produit un tableau consolidé 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êt à être importé 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, détectant les erreurs avant qu'elles n'atteignent le SPED.
Extraction des codes NCM pour les droits d'importation
Une entreprise de logistique gérant des importations a besoin des codes NCM et des valeurs des produits à partir 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 pour le modèle de déclaration du courtier en douane.
FAQ
L'IA peut-elle distinguer ICMS, IPI, PIS et COFINS sur une même NF-e ?
Oui. Chaque taxe possède son propre bloc XML avec des éléments enfants uniques — l'ICMS a <orig> et <CST>, l'IPI a <clEnq>. L'IA les associe proprement à des colonnes de sortie distinctes car la structure XML les différencie. C'est plus facile pour l'IA que l'extraction basée sur l'image, où les taxes apparaissent comme des lignes 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 depuis le XML. Les scénarios d'ICMS-ST (Substituição Tributária) inter-États sont également capturés car le XML étiquette explicitement les montants d'ICMS-ST.
L'IA peut-elle extraire des données d'un XML NF-e en portugais vers un tableur en anglais ?
Oui. Définissez les colonnes 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 le mappage sémantique fonctionne entre 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 du XML NFS-e, mais la variation par ville nécessite plus de vérification. La NF-e (fédérale, pour les marchandises) est fiable ; la NFS-e (municipale, pour les services) introduit plus de variables.
L'extraction par IA du 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'IA crée un tableur dérivé ; le XML original signé reste intact.
Quelle est la différence de précision entre l'extraction XML NF-e et l'extraction PDF DANFE ?
C'est une catégorie totalement différente. L'extraction XML NF-e atteint 99 %+ sur les champs principaux car les données sont dans des balises XML non ambiguës. L'extraction PDF DANFE — lecture de la représentation imprimée — tombe à 90-95 % car il s'agit d'un problème de reconnaissance d'image : variations de polices, qualité d'impression et 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 XML NF-e n'est pas une question de capacité de l'IA — c'est un choix de workflow. Le format structuré rend l'extraction plus précise que tout document basé sur une image, mais cette structure peut être trompeuse : « ce n'est que du XML » donne l'impression que le problème de consolidation est plus simple qu'il ne l'est. Le vrai travail — mapper des champs incohérents entre 30 fournisseurs, quatre versions de NF-e et plusieurs configurations fiscales — est un appariement répétitif que l'IA automatise mieux que toute feuille XSLT ou macro Excel.
La question n'est pas de savoir si l'IA peut extraire du 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 mapper CNPJ, codes NCM et valeurs ICMS dans un tableur en moins d'une minute.