Qu'est-ce qu'une NFS-e ? Pourquoi le traitement
des factures de services brésiliennes coûte plus cher

L'impôt le plus simple, le processus le plus fragmenté

L'ISS a une seule mission : taxer les services de 2 % à 5 % et reverser les recettes à la municipalité où est établi le prestataire. Il ne comporte aucun système de crédit, aucun barème interétatique, aucun débat destination-vs-origine dans les trois quarts des cas. Pourtant, traiter une NFS-e — extraire ses données dans un tableur, les rapprocher d'un référentiel fournisseurs, valider le montant de la taxe — est une opération qui fait échouer l'automatisation basée sur des modèles dans 5 570 municipalités.

La plupart des équipes AP découvrent cette fragmentation progressivement. Tout commence avec une NFS-e d'un cabinet de conseil IT à São Paulo. Les champs sont clairs : CNPJ do Prestador (identifiant fiscal de l'entreprise prestataire), numéro de la NFS-e, base de cálculo de l'ISS (assiette imposable), alíquota ISS (taux), valor ISS (montant de la taxe). Quelqu'un les saisit dans un tableur. Ça fonctionne. Puis une autre NFS-e arrive d'un cabinet juridique à Rio de Janeiro. Les mêmes champs existent, mais ils sont disposés différemment — le CNPJ du prestataire est dans une barre latérale, la ventilation de l'ISS est répartie sur deux encadrés, le code de service est libellé autrement. Puis une troisième arrive de Belo Horizonte. Et une quatrième de Porto Alegre. Chaque document contient le même type de données. Aucun ne les présente de la même manière.

Le problème n'est pas que les données de la NFS-e soient illisibles. C'est qu'elles refusent de converger vers un format unique — et c'est juridiquement voulu.

C'est là que la plupart des analyses sur la complexité des factures brésiliennes se trompent. Elles traitent la fragmentation de la NFS-e comme un problème technique — une lacune d'interopérabilité qu'une API middleware ou une norme XML nationale finira par combler. Ce n'en est pas un. C'est un problème juridictionnel, ancré dans la Constitution fédérale brésilienne de 1988, qui a accordé à chaque municipalité l'autonomie fiscale sur sa propre taxe sur les services. La fragmentation de la NFS-e n'est pas un inconvénient temporaire. C'est la structure voulue du fédéralisme fiscal brésilien, et elle précède la facture numérique de deux décennies.

LC 116/2003 : la loi qui a conçu 5 570 systèmes fiscaux

Pour comprendre pourquoi les formats NFS-e varient selon les villes, il faut remonter du document à la loi qui l'a autorisé. En 2003, le Brésil a promulgué la Lei Complementar 116/2003 (Loi complémentaire 116) — le texte fédéral de référence régissant l'ISS. La LC 116 a fait deux choses à la fois. Premièrement, elle a établi un cadre national : une liste d'environ 40 catégories de services, un taux plancher de 2 %, un taux plafond de 5 %, et des règles générales déterminant quelle ville perçoit la taxe dans quel scénario. Deuxièmement — et c'est la clause opérante pour les équipes AP — elle a laissé chaque municipalité libre d'adopter sa propre législation dans ce cadre.

Ce n'était pas un oubli. La Constitution de 1988 a délibérément réparti le pouvoir fiscal entre trois niveaux de gouvernement : fédéral, étatique et municipal. Les États ont obtenu l'ICMS (marchandises). Les municipalités ont obtenu l'ISS (services). Chacun des 26 États brésiliens gère sa propre réglementation ICMS, créant 27 régimes fiscaux distincts (y compris le District fédéral). Mais pour la NFS-e, l'échelle est deux ordres de grandeur supérieure : 5 570 municipalités, chacune ayant l'autorité légale de fixer son propre taux d'ISS, son propre calendrier de conformité, son propre service web de validation des factures et — point crucial pour le traitement des données — son propre format de document.

Le résultat pratique est quelque chose qu'aucun outil d'extraction basé sur des modèles ne peut survivre. Une facture de services émise à São Paulo place la base de cálculo ISS (base de calcul de l'ISS) à une position ; une facture de Campinas — une ville à 100 kilomètres — la place à une autre. Le champ du taux d'ISS peut être intitulé « Alíquota » dans une municipalité, « Alíquota ISS » dans une autre, et intégré dans une ligne de tableau dans une troisième. Un modèle qui fonctionne pour São Paulo échoue pour Campinas, qui échoue pour Guarulhos, qui échoue pour les 5 567 autres villes. Maintenir une bibliothèque de modèles pour seulement les 20 villes où se trouvent vos fournisseurs signifie 20 modèles qui échouent à la prochaine mise à jour de format publiée par une prefeitura (mairie).

Le contraste NF-e : ce à quoi ressemble une norme nationale unifiée

Le Brésil a déjà résolu ce problème de fragmentation une fois — pour les marchandises. La NF-e (Nota Fiscal Eletrônica / Facture électronique de marchandises), lancée en 2006, est régie au niveau de l'État par la SEFAZ (Secretaria da Fazenda Estadual / Secrétariat des Finances de l'État) selon un schéma XML national unique — version de mise en page 4.0. Une NF-e émise en Amazonas utilise la même structure de champs, les mêmes balises XML et les mêmes règles de validation qu'une NF-e émise dans le Rio Grande do Sul. Un modèle d'extraction unique fonctionne pour les 27 États. La NF-e comprend l'ICMS, le PIS, la COFINS et l'IPI — quatre taxes, chacune plus complexe que l'ISS — et pourtant, traiter un lot de documents NF-e provenant de plusieurs États est un problème d'ingénierie résolu, car la structure des données est normalisée au niveau fédéral.

Puis regardez la NFS-e. La structure des données est fragmentée au niveau municipal — parce que la taxe est administrée au niveau municipal — et la taxe qu'elle porte (ISS, un taux, une ville, aucune chaîne de crédit) est la plus simple du système brésilien. C'est le paradoxe au cœur du problème de la NFS-e : plus la taxe est simple, plus le document est fragmenté. La NF-e porte quatre taxes dans 27 États, et un seul schéma XML les gère toutes. La NFS-e porte une taxe dans 5 570 villes, et il n'existe — à la mi-2026 — aucune mise en page unique couvrant toutes les municipalités.

Lorsque les équipes AP disent « les factures brésiliennes sont complexes », elles parlent généralement de la NF-e — des codes fiscaux qu'elles n'ont jamais vus, des chaînes de calcul inconnues, un modèle de dédouanement qui exige une autorisation gouvernementale avant que les marchandises ne circulent. Mais la NF-e est complexe de manière structurée. La NFS-e est simple de manière fragmentée — et cette dernière est plus coûteuse à traiter.

Le système NF-e a été conçu en pensant au destinataire : la DANFE (Documento Auxiliar da NF-e / Document auxiliaire de la NF-e), la version imprimable, omet la plupart des données XML, mais le XML complet est toujours accessible via le portail SEFAZ à l'aide de la clé d'accès à 44 chiffres imprimée sur chaque DANFE. Le système NFS-e, en revanche, a été conçu en pensant à l'émetteur et à la municipalité. Le destinataire reçoit un PDF — la DANFSE (Documento Auxiliar da NFS-e) — et est censé gérer tout le reste lui-même. Aucun portail de clé d'accès unifié entre les municipalités. Aucune garantie que le PDF imprimé contienne tous les champs XML. Aucune norme nationale pour ce qui figure sur le document imprimé par rapport à ce qui reste dans la base de données municipale.

Une concurrence fiscale cachée à la vue de tous

La fourchette de taux d'ISS de 2 % à 5 % n'est pas un détail technique. C'est le moteur d'une concurrence fiscale municipale qui aggrave le problème de fragmentation des données. Chaque ville contrôlant son propre taux, les municipalités utilisent l'ISS pour attirer les entreprises. São Paulo applique un taux général de 5 %. Alphaville — un quartier d'affaires planifié à 30 kilomètres de São Paulo — facture 2 % pour la plupart des catégories de services. Une entreprise qui transfère son adresse enregistrée de São Paulo à Alphaville réduit sa facture de taxe sur les services des trois cinquièmes sans déplacer ses activités réelles.

Cette « guerra fiscal » (guerre fiscale) entre municipalités a été documentée par le FMI, l'OCDE et le Service fédéral des recettes du Brésil lui-même comme un frein persistant à l'efficacité fiscale. Le PNUD estimait en 2023 que les recettes perdues dues à la concurrence fiscale municipale — au titre de l'ISS, de l'IPTU et d'autres impôts locaux — pourraient atteindre plusieurs points de pourcentage du PIB. Mais la conséquence pour la comptabilité fournisseurs (AP) est plus immédiate : si votre prestataire informatique de São Paulo émet depuis une entité enregistrée à Alphaville, le taux d'ISS sur sa NFS-e indique 2 %, et non 5 %. Votre ERP s'attend à 5 % en fonction de l'emplacement physique du prestataire. L'écart déclenche un drapeau de rapprochement. Quelqu'un dans l'équipe AP doit déterminer pourquoi le taux est incorrect — ou s'il l'est réellement.

Ce n'est pas hypothétique. Les conflits d'ISS entre la municipalité enregistrée du prestataire et celle du preneur de services sont suffisamment courants pour que certaines entreprises paient l'ISS deux fois — aux deux villes — plutôt que de contester le litige. Comme l'a documenté BPC Partners dans son analyse de la taxe sur les services brésilienne, l'ISS est la principale source de revenus du gouvernement municipal et le principal instrument de concurrence fiscale inter-municipale. Pour une équipe AP traitant un lot de 50 documents NFS-e provenant de 15 villes, cela signifie que vous ne pouvez pas considérer le taux d'ISS figurant sur la facture comme un montant fiscal vérifié prêt pour la comptabilisation dans l'ERP. Vous devez le valider — par document, par ville, par code de service.

Le problème « Por Dentro » : quand un calcul de taxe semble simple mais ne l'est pas

Il existe une deuxième raison pour laquelle le montant de l'ISS sur une NFS-e peut faire échouer la validation automatisée. L'ISS au Brésil est calculé « por dentro » (de l'intérieur) — c'est-à-dire que la taxe est intégrée dans le prix brut plutôt que d'être ajoutée par-dessus. Si la valeur nette du service est de 100 R$ et que le taux d'ISS est de 5 %, le montant brut n'est pas de 105 R$. Il est de 100 R$ ÷ 0,95 = 105,26 R$. L'ISS est alors de 105,26 R$ × 0,05 = 5,26 R$, et non de 5,00 R$.

Pour un document unique, la différence est de 0,26 R$ — négligeable. Pour 50 documents par mois sur 12 mois, avec des taux d'ISS variant entre 2 % et 5 %, et des valeurs de services allant de 5 000 R$ à 250 000 R$, l'écart cumulé entre un calcul naïf « taux × net » et le montant réel d'ISS « por dentro » peut franchir des seuils de matérialité. Plus important encore, si votre flux d'extraction ou votre ERP est configuré pour valider l'ISS en multipliant taux × base sans tenir compte du calcul por dentro, chaque document semblera contenir une erreur — et votre équipe passera des heures à enquêter sur des erreurs qui n'en sont pas du tout, mais simplement un décalage entre la logique d'extraction et la convention de calcul de la taxe.

La méthode por dentro s'applique à l'ICMS et à l'ISS dans tout le Brésil, et elle est bien documentée — elle est décrite dans les PwC Worldwide Tax Summaries for Brazil et dans le texte officiel de la LC 116/2003. Mais la plupart des équipes AP internationales ne rencontrent pas la taxation « por dentro » dans leurs opérations nationales. Une facture américaine ou européenne ajoute la taxe par-dessus ; une facture brésilienne l'intègre. Sans ce contexte, le montant d'ISS sur une NFS-e reçue ressemble à une erreur de calcul. Ce n'en est pas une. C'est une convention arithmétique différente appliquée à une taxe dont le taux a été fixé par une ville dont la mise en page est différente de celle de la ville précédente.

Le paradoxe de la réforme fiscale de 2026 : un remède qui aggrave d'abord les symptômes

La réforme de la taxe sur la consommation au Brésil — la plus profonde depuis des décennies — est censée résoudre ce problème. En vertu de l'amendement constitutionnel 132/2023, réglementé par la loi complémentaire 214/2025, cinq impôts existants (PIS, COFINS, ICMS, ISS, IPI) seront éventuellement remplacés par deux : la CBS (Contribuição sobre Bens e Serviços / Contribution sur les biens et services) au niveau fédéral et l'IBS (Imposto sobre Bens e Serviços / Impôt sur les biens et services) au niveau des États et des municipalités. Le taux standard combiné CBS + IBS est projeté à environ 26,5 %. À long terme — d'ici 2033 — cela unifiera la base de la taxe sur la consommation, éliminera la fragmentation municipale de l'ISS et normalisera vraisemblablement les formats de factures de services à l'échelle nationale.

Le problème, c'est le calendrier de transition. Voici à quoi ressemblent les années entre aujourd'hui et 2033 pour le traitement des données AP :

Pour le traitement des données AP, cette transition est un multiplicateur de complexité. Entre 2026 et 2033, une seule facture de services peut porter simultanément des champs ISS, des champs CBS et des champs IBS — chacun avec son propre taux, sa propre base et son propre montant, chacun mis à jour selon un calendrier différent selon la municipalité. La prefeitura de São Paulo a publié la version 3.2 de la mise en page NFS-e en août 2025 pour introduire les champs IBS/CBS ; d'autres villes suivront selon leurs propres calendriers. Une NFS-e reçue en 2028 d'une ville peut être structurellement différente d'une NFS-e reçue le même mois d'une autre ville — non pas à cause de l'ancien problème de fragmentation, mais à cause du nouveau qui s'y superpose.

La réforme finira par résoudre la fragmentation. Mais d'ici là, elle l'aggravera temporairement — car la transition elle-même est fragmentée. Chaque ville met à jour son format selon son propre calendrier. L'adhésion de chaque ville à la norme nationale NFS-e est volontaire. Le calendrier de chaque ville pour l'introduction des champs IBS est différent. Sept ans de complexité croissante avant la simplification finale.

Le correctif partiel du SNNFS-e : 2 000 municipalités incluses, 3 570 toujours exclues

Le Brésil construit une norme nationale NFS-e — SNNFS-e (Sistema Nacional da NFS-e) — depuis 2023. Le système offre un format XML unifié, un portail de facturation centralisé, un référentiel national de données (ADN — Ambiente de Dados Nacional) et un document unique de paiement d'impôt (DNA — Documento Nacional de Arrecadação) valable dans toutes les municipalités participantes. En janvier 2026, environ 2 000 municipalités avaient activé le système — soit environ 35 % de toutes les villes brésiliennes — couvrant environ 80 % des contribuables en volume, car les premiers adoptants sont principalement les municipalités les plus grandes et les plus actives.

Mais voici ce que les chiffres d'adoption masquent. São Paulo, la plus grande ville du Brésil et le moteur économique du pays, a confirmé qu'elle ne migrera pas vers le système national NFS-e en 2026. La ville conservera sa propre plateforme NFS-e — Nota Fiscal Paulistana — qui fonctionne avec son propre schéma XML, son propre service web, son propre manuel de format (version 3.2 en août 2025) et son propre calendrier de mises à jour. São Paulo n'est pas seule. D'autres grandes villes évaluent leurs options, et la loi n'impose pas la migration — elle l'encourage par la menace de perdre les transferts fédéraux, mais les grandes villes disposant de bases de revenus propres importantes sont moins sensibles à cette menace.

Le résultat est un système à deux vitesses indéfiniment : certaines villes sur la norme nationale, d'autres sur leurs propres plateformes municipales, toutes tenues de transmettre les données au référentiel national ADN — ce qui garantit la visibilité fiscale mais ne standardise en rien le format de document qui arrive dans votre boîte de réception AP. Le destinataire reçoit toujours des formats variés. Le problème de fragmentation persiste.

Et pour les 106 petites municipalités qui n'avaient toujours pas signé l'accord début 2026, comme l'a rapporté le Service fédéral des recettes brésilien, les prestataires de services de ces villes peuvent encore émettre des NFS-e via des systèmes hérités — ou, dans certains cas, via des processus papier antérieurs à la facturation numérique. La Receita Federal elle-même a reconnu le 6 janvier 2026 que de nombreuses municipalités avaient signé l'accord à la dernière minute mais n'avaient pas achevé la configuration technique requise pour être opérationnelles.

Ce que cela signifie pour votre flux de travail AP

Si votre entreprise traite 30 à 50 factures de services par mois provenant de fournisseurs brésiliens dans 10 villes différentes, vous n'êtes pas confronté à un problème de saisie de données. Vous êtes confronté à un problème structurel de fragmentation des données créé par le fédéralisme fiscal brésilien, amplifié par la concurrence fiscale municipale, compliqué par une convention de calcul fiscal non standard, et qui entre maintenant dans une transition de sept ans durant laquelle chaque document portera deux cadres fiscaux parallèles.

La réponse AP standard à la diversité des documents — créer plus de modèles — échoue ici. Vous ne pouvez pas créer des modèles pour 5 570 mises en page potentielles. Même si vous ne traitez qu'avec 10 villes, chacune de ces 10 villes peut mettre à jour sa mise en page NFS-e indépendamment, selon des calendriers que vous ne contrôlez pas. La prefeitura de São Paulo a publié trois versions du manuel NFS-e en 2025 seulement. Un modèle de maintenance qui fonctionnait pour 27 schémas NF-e au niveau des États s'effondre à l'échelle municipale.

La réponse AP standard à la complexité fiscale — faire confiance à la facture — échoue également ici. Le taux d'ISS sur une NFS-e d'Alphaville peut indiquer 2 % alors que votre ERP attend 5 % en fonction de l'emplacement physique du fournisseur à São Paulo. Le fournisseur peut avoir un enregistrement légitime à Alphaville, ou il peut s'adonner à une optimisation fiscale que votre équipe de conformité doit examiner. Le montant de l'ISS peut sembler erroné parce qu'il a été calculé por dentro alors que votre logique de validation attendait une arithmétique additive. Faire confiance à la facture sans vérification signifie importer d'éventuelles inexactitudes fiscales dans votre ERP — une exposition à la conformité qui s'aggrave avec chaque document.

Avant de penser aux outils ou à l'automatisation, vous devez reconnaître ce que vous traitez : un format de document qui a été légalement conçu pour ne pas converger vers une norme, émis par un système fiscal fragmenté au niveau municipal par conception constitutionnelle, pendant une période de réforme qui rendra la fragmentation temporairement pire.

C'est le diagnostic. La solution n'est pas un meilleur modèle. C'est une approche d'extraction qui ne dépend pas du tout de modèles — une approche qui lit les champs par leur signification (CNPJ = identifiant fiscal à 14 chiffres étiqueté « Prestador ») plutôt que par leur position sur la page d'une ville spécifique. L'extraction sémantique — alimentée par des modèles de langage visuels qui comprennent la structure des documents comme le ferait une personne — est la réponse technique à un problème juridictionnel que les outils basés sur des modèles n'ont jamais été conçus pour gérer. Mais la première étape est de comprendre la nature du problème. Sans cela, vous évaluez les outils selon de mauvais critères.

FAQ : Variation municipale de la NFS-e au Brésil et traitement AP

Pourquoi les formats de NFS-e diffèrent-ils d'une ville brésilienne à l'autre ?

Parce que l'ISS est un impôt municipal, et non fédéral. La Constitution fédérale de 1988 accorde à chacune des 5 570 municipalités brésiliennes le pouvoir de légiférer et d'administrer son propre impôt sur les services. La LC 116/2003 a fourni des directives nationales (fourchette de taux de 2 % à 5 %, 40 catégories de services), mais a explicitement laissé la mise en œuvre — y compris le format de la facture électronique — à chaque municipalité. Contrairement à la NF-e (facture de marchandises), régie par une norme XML fédérale unique dans tous les États, la normalisation du format de la NFS-e dépend de l'adoption volontaire du système national SNNFS-e par les municipalités. Début 2026, environ 2 000 municipalités l'avaient adopté ; São Paulo et d'autres grandes villes ont jusqu'ici choisi de conserver leurs propres systèmes.

Comment la réforme fiscale de 2026 affecte-t-elle le traitement de la NFS-e ?

La réforme introduit l'IBS et la CBS pour éventuellement remplacer l'ISS et d'autres taxes sur la consommation, mais la transition s'étend jusqu'en 2033. Pendant cette période, les documents NFS-e comporteront à la fois les anciens champs ISS et les nouveaux champs IBS/CBS — créant une double ventilation fiscale sur un même document. Chaque municipalité met à jour son format selon son propre calendrier, ce qui signifie que vous pouvez recevoir des documents NFS-e de différentes villes avec des combinaisons de champs fiscaux différentes pendant les années de transition. La réforme simplifie la situation à long terme (une TVA unifiée d'ici 2033) mais accroît la complexité du traitement à court terme.

Puis-je créer des modèles pour les villes où se trouvent mes fournisseurs ?

Vous le pouvez, mais le coût de maintenance est le problème. Même si vous ne traitez que des NFS-e de 10 villes, celles-ci peuvent chacune mettre à jour leur format indépendamment — São Paulo a publié trois versions manuelles en 2025 à elle seule. Un modèle qui fonctionne en janvier peut casser en août parce que la prefeitura a modifié les positions des champs. À l'échelle municipale — 10 villes × plusieurs versions de format × des calendriers de mise à jour indépendants — la maintenance des modèles devient un coût opérationnel récurrent, et non une configuration ponctuelle. Pour une discussion sur la façon dont l'extraction sémantique sans modèle gère cela, consultez notre guide sur l'extraction de données NFS-e pour les opérations brésiliennes.

Pourquoi le montant ISS sur ma NFS-e ne correspond-il pas au taux × base ?

L'ISS au Brésil est calculé « por dentro » — la taxe est intégrée dans le prix brut plutôt que d'être ajoutée par-dessus. Un service net de 100 R$ à 5 % d'ISS produit un brut de 100 R$ ÷ 0,95 = 105,26 R$, et non 105 R$. L'ISS est alors de 5,26 R$, et non de 5,00 R$. Si votre logique de validation multiplie le taux × la base sans tenir compte de cette convention, chaque document semblera contenir une erreur de calcul. La formule est : ISS = (valeur brute du service × taux), où brut = valeur nette du service ÷ (1 − taux).

Est-il sûr d'insérer les montants ISS des NFS-e directement dans mon ERP sans validation ?

Pas de manière fiable, pour deux raisons. Premièrement, les municipalités brésiliennes se font concurrence sur les taux d'ISS — un prestataire enregistré à Alphaville (2 %) peut émettre depuis un lieu que vous connaissez comme São Paulo (5 %), créant une variation de taux légitime mais inattendue. Deuxièmement, le champ « ISS Retido na Fonte » (retenu à la source) sur une NFS-e transfère l'obligation de remise de la taxe du prestataire à votre entreprise — s'il est marqué « Sim » (oui), vous êtes responsable du paiement de l'ISS à la municipalité, et pas seulement de la comptabilisation de la facture. Manquer ce drapeau est une exposition à la non-conformité, pas seulement une erreur de données.

Pourquoi la NFS-e est-elle plus difficile à automatiser que la NF-e alors que l'ISS est plus simple que l'ICMS ?

Parce que la normalisation suit la juridiction. L'ICMS est un impôt d'État, régi par 27 autorités SEFAZ qui ont collectivement convenu d'une norme XML unique (format NF-e 4.0) avant la mise en service du système en 2006. L'ISS est un impôt municipal, régi par 5 570 prefeituras qui ne sont jamais parvenues à un format unique — et le gouvernement fédéral n'a commencé à pousser à la normalisation via la SNNFS-e qu'en 2023, 17 ans après la normalisation de la NF-e. L'impôt est plus simple, mais la structure de gouvernance qui crée le document est plus fragmentée — et la gouvernance détermine le format.

Diagnostic avant prescription

Le problème du traitement des NFS-e n'est pas que la saisie des données est lente. C'est que vos documents d'entrée sont structurellement non convergents — une caractéristique du fédéralisme fiscal brésilien, pas une lacune d'intégration temporaire. Tant que vous n'avez pas traité le diagnostic, chaque évaluation d'outil se fait par rapport à un mauvais critère. Vous ne cherchez pas quelque chose qui accélère la frappe. Vous cherchez quelque chose qui supprime la dépendance à la cohérence des formats, car dans un système de 5 570 formats de documents municipaux, la cohérence des formats n'existe pas.

C'est pourquoi l'extraction sémantique — qui localise les champs par le sens plutôt que par la position — s'adapte au problème d'une manière que l'OCR basé sur des modèles ne peut pas. Pour une démonstration pratique de son fonctionnement sur des documents NFS-e individuels, y compris les codes de service LC 116, les drapeaux de retenue ISS et l'extraction de champs inter-villes, voir comment extraire les données NFS-e pour les opérations brésiliennes. Pour le scénario de volume — traitement de 50 documents NFS-e ou plus provenant de plusieurs villes en un seul lot — voir traitement par lots multi-municipalités des NFS-e.

Le diagnostic structurel ne prescrit pas un outil. Il définit le problème qu'un outil doit résoudre. L'écart entre comprendre la fragmentation et y répondre avec la bonne approche d'extraction est la différence entre réagir à chaque changement de format de chaque ville et traiter la NFS-e de n'importe quelle ville sans remarquer de quelle ville elle provient.