Comment extraire les données NFS-e pour vos
opérations brésiliennes (guide 2026)

Pourquoi une facture de service brésilienne est différente de toutes les autres factures que vous traitez

Si vous avez déjà travaillé avec des documents fiscaux brésiliens, vous connaissez probablement la NF-e — la facture électronique de marchandises que toute équipe AP au Brésil ou travaillant avec des fournisseurs brésiliens doit gérer. La NF-e est régie au niveau de l'État par la SEFAZ (Secrétariat d'État aux Finances), suit un schéma XML national unique (version 4.0 du layout) et porte l'ICMS — une taxe d'État sur la circulation des marchandises. C'est complexe, mais c'est un système unique.

Une facture de service (Nota Fiscal de Serviços / NFS-e) est régie au niveau municipal. La taxe qu'elle porte est l'ISS — Impôt sur les Services — et le taux, le layout, le workflow de validation, et même les exigences de certificat numérique peuvent tous différer d'une ville à l'autre. São Paulo a son propre service web NFS-e. Rio de Janeiro en a un différent. Belo Horizonte en a un troisième. Et 5 567 autres municipalités ont le leur.

Ce n'est pas un cas marginal. C'est la réalité structurelle du fédéralisme fiscal brésilien, consacrée par la Loi Complémentaire 116/2003, qui accorde à chaque municipalité le pouvoir de fixer son propre taux d'ISS (2 %–5 %) et d'administrer sa propre collecte de la taxe sur les services. Le gouvernement fédéral s'efforce d'unifier cela via le Système National de NFS-e (Sistema Nacional de NFS-e / SNNFS-e), avec plus de 1 280 municipalités inscrites début 2026. Mais l'adoption est volontaire, et de nombreuses grandes villes gèrent encore leurs propres systèmes.

Pour l'équipe qui reçoit ces documents — le commis AP qui ouvre un PDF d'une agence de marketing brésilienne ou d'un consultant IT — la conséquence pratique est la suivante : aucun document NFS-e ne se ressemble. Une facture de service émise à São Paulo place la base de cálculo (base imposable) de l'ISS à un endroit différent de celle émise à Porto Alegre. Le CNPJ do prestador (identifiant fiscal de l'entreprise prestataire) peut être dans l'en-tête sur un document et dans une barre latérale sur un autre. Un modèle qui fonctionne pour São Paulo échouera pour Campinas.

C'est pourquoi l'OCR basé sur des modèles — l'approche utilisée par la plupart des outils d'extraction de documents — échoue systématiquement sur la NFS-e. Les modèles correspondent à des coordonnées. Les municipalités changent les coordonnées. Pour un aperçu plus détaillé du fonctionnement de l'autre grand type de facture électronique brésilienne, consultez notre guide d'extraction XML NF-e, qui couvre la facture de marchandises au niveau de l'État.

Ce que contient réellement une NFS-e (Nota Fiscal de Serviços)

Avant d'extraire des données d'une NFS-e, il faut savoir ce qu'elle contient — et surtout, ce que chaque champ signifie pour votre comptabilité. Une NFS-e n'est pas qu'une simple facture. C'est un document fiscal dont les champs, imposés par la loi, déterminent vos obligations fiscales, le rapprochement de vos fournisseurs et votre piste d'audit.

Voici les champs clés d'une NFS-e type et pourquoi chacun est important côté réception :

A lista de códigos de serviço da LC 116 contém 40 categorias principais, cada uma com subitens que abrangem desde serviços de TI (categoria 1) até serviços jurídicos (item 17.14), engenharia (categoria 7) e saúde (categoria 4). A lista completa está disponível publicamente no anexo da Lei Complementar 116/2003. Cada NFS-e que você recebe contém um desses códigos, e esse código determina diretamente a alíquota de ISS que seu prestador deveria ter aplicado.

Nenhum desses campos é opcional. O município que valida a NFS-e verifica cada um deles antes de autorizar o documento. Isso significa que os dados necessários para o processamento preciso da AP já existem — foram verificados por uma autoridade fiscal governamental antes de a fatura chegar à sua caixa de entrada. A questão é se você consegue extraí-los do documento e colocá-los na sua planilha sem redigitá-los.

Quanto Custa a Digitação Manual de NFS-e para sua Equipe Financeira

A suposição padrão é que inserir dados de faturas manualmente é lento. E é — um documento simples de uma página leva em média 3 minutos para ser digitado em uma planilha. Mas, especificamente com a NFS-e, a lentidão não é o problema mais caro. O problema mais caro é a propagação de erros em seus registros fiscais.

Um CNPJ digitado errado — um dígito incorreto em uma sequência de 14 — significa que a reconciliação do cadastro de fornecedores falha, e você não pode creditar o ISS se sua entidade for a responsável pela retenção. Uma alíquota de ISS incorreta inserida no seu ERP (2% registrado como 5%) significa que sua provisão de impostos está errada para todo o período de apuração, podendo ser sinalizada em uma auditoria municipal. Um flag "ISS Retido na Fonte = Sim" perdido significa que você deixa de recolher o ISS pelo qual você — e não o prestador — é legalmente responsável perante a prefeitura.

Esses não são riscos hipotéticos. As autoridades fiscais brasileiras realizam cruzamentos eletrônicos entre emissores e tomadores de NFS-e. Se seu prestador reportou ter recebido R$ 50.000 do seu CNPJ e seus registros SPED mostram R$ 48.000 porque duas notas foram digitadas errado, a divergência gera uma notificação automática — e, em seguida, uma investigação formal.

Multiplique isso por um volume, mesmo que modesto. Uma empresa de médio porte com 10 prestadores de serviço brasileiros — uma consultoria de TI, uma agência de marketing, um escritório de advocacia, uma contabilidade, uma empresa de administração de condomínios e alguns freelancers — pode receber de 30 a 50 documentos NFS-e por mês. A 3 minutos por documento, são cerca de 2,5 horas de digitação manual. Mas o custo real não são as 2,5 horas. É o ciclo de correção: a planilha de reconciliação que não fecha, a ligação para o prestador pedindo uma segunda via, a declaração fiscal retificada, a taxa de contabilidade para resolver a divergência.

É aqui que a expressão "extração de documentos" se torna concreta. Não se trata de economizar tempo de digitação. Trata-se de eliminar a lacuna entre o que o município validou e o que seu ERP recebeu.

Comment l'extraction par IA gère les variations municipales — sans modèles par ville

Le défi technique principal de l'extraction des NFS-e n'est pas que les documents soient difficiles à lire. Une facture de service (Nota Fiscal de Serviços / NFS-e) de n'importe quelle ville brésilienne est un document clairement imprimé, généralement généré par machine. Le défi est que le même champ apparaît à une position différente, avec des libellés différents, sur les documents de différentes villes.

L'OCR traditionnel basé sur des modèles résout ce problème en définissant une zone rectangulaire pour chaque champ : « CNPJ do Prestador est aux coordonnées (x=150, y=320, l=200, h=30). » Cela fonctionne parfaitement — pour une seule municipalité. Cela échoue pour la suivante. Maintenir une bibliothèque de modèles pour 5 570 villes n'est pas réalisable. Même en maintenir une pour les 20 villes où se trouvent vos prestataires signifie 20 modèles qui se brisent lorsque la préfecture publie une mise à jour de mise en page (ce que São Paulo a fait en août 2025 avec la version 3.2 de son manuel NFS-e).

L'alternative est l'extraction sémantique : au lieu de chercher un champ par sa position, on le cherche par ce qu'il signifie. Vous dites au moteur d'extraction « J'ai besoin du CNPJ du prestataire de services », et le moteur lit le document, comprend qu'un nombre à 14 chiffres étiqueté « CNPJ » à côté de « Prestador » est l'identifiant fiscal du prestataire — peu importe où il se trouve sur la page.

C'est fondamentalement différent de l'OCR. L'OCR convertit les pixels en caractères. L'extraction sémantique — alimentée par des modèles de langage visuels — lit un document plus comme une personne le ferait : en comprenant les libellés, le contexte et la structure du document. Lorsque la mise en page de São Paulo place « Prestador de Serviços » en haut à gauche et celle de Porto Alegre le place dans un en-tête centré, un moteur sémantique s'en moque. Il ne cherche pas une position. Il cherche un sens.

L'approche d'extraction utilise l'extraction par colonnes personnalisées : vous tapez les noms des champs souhaités dans votre sortie — « CNPJ du Prestataire », « Code Service (LC 116) », « Montant ISS », « Numéro NFS-e » — et l'IA localise chaque valeur sur le document en comprenant ce que signifie le libellé, et non où il se trouve. Ces noms de colonnes deviennent les en-têtes de votre feuille de calcul Excel finale, de sorte que la sortie est prête à être importée dans votre ERP ou système comptable sans reformatage.

Étape par étape : extraire les données NFS-e vers Excel

Voici le processus pratique pour extraire les données de vos NFS-e reçues dans un tableur structuré. La méthode fonctionne que vous ayez le PDF/DANFSE (le document auxiliaire imprimé pour les services) ou le fichier XML sous-jacent.

Gestion de la retenue d'ISS, des codes de service multiples et des scénarios par lots

L'extraction de NFS-e est généralement simple — un seul prestataire, un seul service, des champs standards. Mais les flux de travail financiers réels rencontrent des cas particuliers qui comptent. En voici trois qui compliquent les processus manuels :

ISS retenu à la source (ISS Retido na Fonte)

Lorsqu'une NFS-e est marquée « ISS Retido na Fonte = Sim », l'obligation de reverser l'ISS à la municipalité passe du prestataire de services au preneur — c'est-à-dire à vous. Ce n'est pas une simple note de saisie. C'est une action de conformité fiscale. Votre équipe financière doit : (1) identifier ces factures dans l'extraction, (2) calculer le montant d'ISS à reverser (le taux × la base indiquée sur la facture), et (3) effectuer le paiement à la bonne préfecture municipale dans les délais.

Omettre cette étape signifie que l'ISS n'a jamais été payé à personne — le prestataire ne l'a pas payé (car il l'a déclaré retenu), et vous ne l'avez pas payé non plus (car vous avez manqué l'indicateur). Les deux parties sont exposées. Un flux d'extraction qui signale automatiquement ces documents — en extrayant le champ « ISS Retido » sous forme de colonne oui/non — transforme un risque de conformité en une colonne de feuille de calcul triable.

Plusieurs codes de service sur une même facture

Une NFS-e peut contenir plusieurs lignes, chacune avec son propre code de service LC 116 et son propre taux d'ISS. Un cabinet de conseil IT peut facturer séparément « Análise e desenvolvimento de sistemas » (code 1.01, ISS 5 % à São Paulo) et « Suporte técnico » (code 1.07, taux potentiellement différent). Si vous n'extrayez que le total ISS de la facture, vous perdez la classification par ligne qui détermine si chaque ligne a été correctement taxée. Définissez vos colonnes pour extraire les codes de service et les montants ISS par ligne, pas seulement le total du document.

Traitement par lots pour plusieurs prestataires de services

Lorsque vous recevez des NFS-e de cinq prestataires différents dans cinq villes différentes, l'avantage du traitement par lots se cumule. Au lieu d'ouvrir chaque PDF individuellement et de copier les champs dans des lignes de tableur séparées, vous les téléchargez tous ensemble. Le moteur d'extraction les traite en parallèle — une page unique prend 5 à 10 secondes — et produit un tableur consolidé avec les données de tous les prestataires dans les mêmes colonnes. C'est la réponse pratique au problème de fragmentation municipale : l'IA gère les différences de mise en page par document automatiquement, et votre équipe gère un seul fichier de sortie.

Pour les scénarios de volume — 50, 100 NFS-e ou plus par mois — l'extraction par lots de factures vers Excel élimine la configuration par document qui rend le traitement manuel linéaire par rapport au nombre de documents.

La réforme fiscale de 2026 : ce qui change pour l'extraction des NFS-e

Le Brésil est en pleine réforme fiscale qui remplacera à terme l'ISS et l'ICMS par un IBS unifié (Imposto sobre Bens e Serviços) et le PIS/COFINS par la CBS (Contribuição sobre Bens e Serviços). La transition est progressive — jusqu'en 2033 — mais les mises en page des NFS-e sont déjà mises à jour. São Paulo a publié la version 3.2 de son manuel NFS-e en août 2025, introduisant des champs pour la nouvelle structure fiscale. D'autres municipalités suivront.

Du point de vue de l'extraction de données, cela signifie deux choses. Premièrement, les champs que vous extrayez aujourd'hui (base ISS, taux ISS, montant ISS) seront éventuellement complétés ou remplacés par des champs IBS/CBS sur les futurs documents NFS-e. Deuxièmement, pendant la période de transition, vous pouvez recevoir des factures comportant à la fois les anciens champs ISS et les nouveaux champs IBS — et vous devrez extraire les deux pour le rapprochement.

L'approche d'extraction décrite ci-dessus gère cela naturellement. Comme elle ne dépend pas de positions de champ fixes ou de modèles codés en dur, les nouveaux champs sur une mise en page NFS-e mise à jour sont extraits de la même manière que les existants : vous ajoutez le nom de la colonne (par exemple, « Montant IBS »), et l'IA le localise sur le document. Aucune reconfiguration de modèle requise.

Pour un guide pratique sur l'extraction des données fiscales des factures de biens brésiliennes — qui comportent ICMS, IPI, PIS et COFINS et sont régies par un cadre réglementaire différent — consultez notre guide d'extraction XML NF-e. Si vous traitez également des documents de paie brésiliens, notre guide d'extraction de holerite (fiche de paie) couvre ce flux de travail.

FAQ : Extraction de factures de service NFS-e brésiliennes

Puis-je extraire des données d'un PDF NFS-e si je n'ai pas le XML ?

Oui. Le PDF/DANFSE contient tous les champs fiscaux obligatoires exigés par la municipalité pour validation. Contrairement au DANFE de la NF-e — qui omet environ 90 % des données XML sous-jacentes — le document imprimé NFS-e est plus autonome car les municipalités ne partagent pas un standard unique pour ce qui va dans le XML par rapport à ce qui apparaît sur le document auxiliaire imprimé. L'ensemble complet des champs listés dans le tableau d'anatomie ci-dessus (CNPJ prestataire/preneur, code LC 116, ventilation de l'ISS, numéro NFS-e, numéro RPS) est généralement présent sur le PDF. Cependant, si vous avez accès au XML, utilisez-le — il garantit une couverture à 100 % des champs et élimine les variations de précision liées à la ROC.

L'extraction fonctionne-t-elle avec les documents NFS-e de n'importe quelle ville brésilienne ?

L'extraction sémantique lit les champs en comprenant le contenu du document, sans correspondre à la mise en page d'une ville spécifique. Elle fonctionne sur une NFS-e de São Paulo, Rio de Janeiro, Belo Horizonte, Porto Alegre ou toute autre municipalité sans nécessiter de modèle par ville. Cependant, la précision de l'extraction sur les documents NFS-e manuscrits — qui sont rares (presque toutes les NFS-e sont générées par machine) — sera inférieure à celle des documents imprimés ou numériques. La reconnaissance de l'écriture manuscrite fonctionne, mais elle est intrinsèquement moins précise que la lecture de texte imprimé.

Qu'en est-il de l'ISS retenu à la source — comment gérer l'obligation de remise de l'impôt ?

Extrayez le champ « ISS Retido na Fonte » comme colonne dédiée. Toute facture où ce champ est égal à « Sim » (ou « Oui ») doit être acheminée vers votre flux de conformité fiscale, et non saisie comme une écriture AP standard. Le taux d'ISS et la base d'ISS sur la facture vous indiquent le montant à remettre ; la municipalité du prestataire vous indique où le remettre. L'outil d'extraction vous fournit les données. La remise de l'impôt elle-même est une étape de conformité distincte que votre équipe comptable ou fiscale doit exécuter via le système de paiement de la préfecture concernée.

Puis-je traiter des NFS-e par lots avec des factures internationales classiques ?

Oui. Si vos colonnes sont assez larges pour couvrir les deux types de documents (ex. « Numéro de facture », « Nom du fournisseur », « Montant total »), vous pouvez inclure des NFS-e brésiliennes dans le même lot que des factures internationales. Le moteur d'extraction lit chaque document indépendamment et remplit les champs qu'il trouve. Pour les champs propres aux NFS-e — comme le code service LC 116 ou le montant ISS — ces colonnes resteront vides pour les factures non brésiliennes, ce qui est normal et ne génère pas d'erreur.

Quel est l'impact de la réforme fiscale de 2026 sur l'extraction des champs NFS-e ?

La réforme ne change pas le fonctionnement de l'extraction — elle modifie les champs qui apparaîtront sur les futurs documents NFS-e. À mesure que les municipalités mettront à jour leurs formulaires pour inclure les champs IBS et CBS, en remplacement ou en complément de l'ISS, vous devrez mettre à jour vos colonnes avec les nouveaux noms de champs. La méthode d'extraction reste la même : ajoutez le nouveau nom de colonne, et l'IA localise la valeur correspondante. La transition progressive jusqu'en 2033 signifie que vous traiterez probablement des documents avec des champs fiscaux anciens et nouveaux pendant la période de chevauchement.

Ai-je besoin d'un CNPJ (identifiant fiscal brésilien) pour utiliser cette méthode d'extraction ?

Non. L'extraction de données à partir d'une NFS-e reçue est une tâche de traitement documentaire, pas une action de déclaration fiscale. Vous n'avez pas besoin de CNPJ pour extraire des données d'un PDF ou XML NFS-e vers un tableur. Les champs CNPJ sur le document identifient le prestataire et le preneur de service ; l'outil d'extraction les lit comme des données et les place dans vos colonnes de sortie — il n'interagit avec aucun système fiscal municipal.

De la saisie document par document au traitement par lots

La NFS-e a été conçue pour rendre la collecte fiscale efficace pour l'administration — et elle y parvient. Chaque facture de service émise au Brésil est validée par une autorité fiscale municipale avant de vous parvenir, ce qui signifie que les données ont déjà été vérifiées pour leur cohérence. L'inefficacité se situe entièrement du côté du destinataire : le comptable qui ressaisit des champs déjà vérifiés par une machine, sur un document qui varie selon les villes, dans un tableur qui doit être exact pour le rapprochement fiscal.

L'extraction sémantique change cette équation côté réception. Les champs sont déjà là, déjà validés, déjà lisibles par machine (ou presque). Les récupérer dans votre tableur en un seul lot est une décision de workflow, pas une avancée technique. Testez-la sur votre prochain lot de documents NFS-e — voyez si le temps par document passe de la référence manuelle de 3 minutes aux secondes nécessaires pour définir vos colonnes une fois et laisser l'extraction s'exécuter.