NFS-e-Daten für Ihre
Brasilien-Geschäfte extrahieren (Leitfaden 2026)

Warum sich eine brasilianische Dienstleistungsrechnung von jeder anderen Rechnung unterscheidet, die Sie verarbeiten

Wenn Sie bereits mit brasilianischen Steuerdokumenten gearbeitet haben, kennen Sie wahrscheinlich die NF-e – die elektronische Warenrechnung, die jedes AP-Team in Brasilien oder im Umgang mit brasilianischen Lieferanten bearbeiten muss. Die NF-e wird auf staatlicher Ebene von der SEFAZ (Secretaria da Fazenda Estadual) reguliert, folgt einem einheitlichen nationalen XML-Schema (Layout-Version 4.0) und führt ICMS – eine staatliche Steuer auf den Warenverkehr. Sie ist komplex, aber es ist ein System.

Eine Dienstleistungsrechnung (Nota Fiscal de Serviços / NFS-e) wird auf kommunaler Ebene reguliert. Die darauf enthaltene Steuer ist ISS – Imposto Sobre Serviços – und der Steuersatz, das Layout, der Prüfworkflow und sogar die Anforderungen an digitale Zertifikate können von Stadt zu Stadt unterschiedlich sein. São Paulo hat seinen eigenen NFS-e-Webdienst. Rio de Janeiro einen anderen. Belo Horizonte einen dritten. Und 5.567 weitere Gemeinden haben jeweils ihren eigenen.

Dies ist kein Ausnahmefall. Es ist die strukturelle Realität des brasilianischen Steuerföderalismus, verankert in Lei Complementar 116/2003, die jeder Gemeinde die Befugnis gibt, ihren eigenen ISS-Satz (2%–5%) festzulegen und ihre eigene Dienstleistungssteuer zu erheben. Die Bundesregierung arbeitet an einer Vereinheitlichung durch das Nationale NFS-e-System (Sistema Nacional de NFS-e / SNNFS-e), dem Anfang 2026 über 1.280 Gemeinden beigetreten sind. Die Teilnahme ist jedoch freiwillig, und viele Großstädte betreiben weiterhin ihre eigenen Systeme.

Für das Team, das diese Dokumente erhält – den AP-Sachbearbeiter, der eine PDF-Datei einer brasilianischen Marketingagentur oder eines IT-Beraters öffnet – hat dies praktische Konsequenzen: Keine zwei NFS-e-Dokumente sehen gleich aus. Eine in São Paulo ausgestellte Dienstleistungsrechnung platziert die ISS-Bemessungsgrundlage (base de cálculo) an einer anderen Stelle als eine in Porto Alegre ausgestellte. Die CNPJ do prestador (Steuernummer des Dienstleisters) kann sich bei einem Dokument im Kopfbereich und bei einem anderen in einer Seitenleiste befinden. Eine Vorlage, die für São Paulo funktioniert, wird für Campinas versagen.

Aus diesem Grund scheitert die templatebasierte OCR – der Ansatz, den die meisten Dokumentextraktionstools verwenden – systematisch bei NFS-e. Templates gleichen Koordinaten ab. Gemeinden ändern Koordinaten. Für einen genaueren Blick auf die Funktionsweise des anderen großen elektronischen Rechnungstyps in Brasilien lesen Sie unseren Leitfaden zur NF-e-XML-Extraktion, der die staatliche Warenrechnung behandelt.

Was eine brasilianische Dienstleistungsrechnung (NFS-e) tatsächlich enthält

Bevor Sie Daten aus einer Dienstleistungsrechnung (Nota Fiscal de Serviços / NFS-e) extrahieren können, müssen Sie wissen, was darauf steht – und vor allem, was jedes Feld für Ihre Buchhaltung bedeutet. Eine NFS-e ist nicht nur eine Rechnung. Es ist ein Steuerdokument mit gesetzlich vorgeschriebenen Feldern, deren Werte Ihre Steuerpflicht, Ihren Lieferantenstammabgleich und Ihren Prüfpfad bestimmen.

Hier sind die wichtigsten Felder einer typischen NFS-e und warum jedes auf der Empfängerseite relevant ist:

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 um processamento preciso de contas a pagar 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.

O Custo da 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 comum de uma página leva cerca de 3 minutos para ser digitado em uma planilha. Mas, especificamente com 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 dígitos — 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 em seu ERP (2% registrado como 5%) significa que sua provisão fiscal está errada para todo o período de relatório, 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 erradas, 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ços brasileiros — uma consultoria de TI, uma agência de marketing, um escritório de advocacia, um contador, uma empresa de administração de instalações 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 discrepâ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.

Wie KI-Extraktion kommunale Unterschiede bewältigt – ohne stadtabhängige Vorlagen

Die zentrale technische Herausforderung bei der NFS-e-Extraktion liegt nicht darin, dass die Dokumente schwer lesbar wären. Eine Dienstleistungsrechnung (Nota Fiscal de Serviços / NFS-e) aus jeder brasilianischen Stadt ist ein klar gedrucktes, meist maschinell erstelltes Dokument. Die Herausforderung ist, dass dasselbe Feld an unterschiedlichen Positionen und mit unterschiedlichen Bezeichnungen auf Dokumenten verschiedener Städte erscheint.

Traditionelle vorlagenbasierte OCR löst dies, indem sie für jedes Feld einen rechteckigen Bereich definiert: „CNPJ do Prestador befindet sich an den Koordinaten (x=150, y=320, b=200, h=30)." Das funktioniert perfekt – für eine einzige Gemeinde. Bei der nächsten versagt es. Eine Vorlagenbibliothek für 5.570 Städte zu pflegen, ist nicht praktikabel. Selbst die Pflege für die 20 Städte, in denen Ihre Dienstleister ansässig sind, bedeutet 20 Vorlagen, die versagen, sobald die Stadtverwaltung ein Layout-Update veröffentlicht (was São Paulo erst im August 2025 mit Version 3.2 seines NFS-e-Handbuchs getan hat).

Die Alternative ist die semantische Extraktion: Statt ein Feld anhand seiner Position zu suchen, sucht man nach seiner Bedeutung. Man sagt der Extraktions-Engine: „Ich brauche die CNPJ des Dienstleisters", und die Engine liest das Dokument, versteht, dass eine 14-stellige Zahl mit der Bezeichnung „CNPJ" neben „Prestador" die Steuernummer des Dienstleisters ist – unabhängig davon, wo sie auf der Seite steht.

Das unterscheidet sich grundlegend von OCR. OCR wandelt Pixel in Zeichen um. Semantische Extraktion – unterstützt durch visuelle Sprachmodelle – liest ein Dokument eher wie ein Mensch: Sie versteht Bezeichnungen, Kontext und Dokumentenstruktur. Wenn das Layout von São Paulo „Prestador de Serviços" oben links platziert und Porto Alegre es in eine zentrierte Kopfzeile setzt, ist das für eine semantische Engine irrelevant. Sie sucht nicht nach einer Position. Sie sucht nach einer Bedeutung.

Der Extraktionsansatz verwendet die benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen in Ihre Ausgabe ein – „Dienstleister-CNPJ", „Service-Code (LC 116)", „ISS-Betrag", „NFS-e-Nummer" – und die KI lokalisiert jeden Wert im Dokument, indem sie versteht, was die Bezeichnung bedeutet, nicht wo sie steht. Diese Spaltennamen werden zu den Überschriften Ihrer finalen Excel-Tabelle, sodass die Ausgabe ohne Neuformatierung direkt in Ihr ERP oder Buchhaltungssystem importiert werden kann.

Schritt für Schritt: NFS-e-Daten in Excel extrahieren

Hier ist der praktische Arbeitsablauf, um Daten aus Ihren erhaltenen NFS-e-Dokumenten in eine strukturierte Tabelle zu extrahieren. Der Prozess funktioniert sowohl mit dem PDF/DANFSE (dem gedruckten Hilfsdokument für Dienstleistungen) als auch mit der zugrunde liegenden XML-Datei.

Umgang mit ISS-Einbehalt, mehreren Dienstleistungscodes und Batch-Szenarien

Die meisten NFS-e-Extraktionen sind unkompliziert – ein einzelner Anbieter, eine einzelne Dienstleistung, Standardfelder. In der realen Finanzwelt treten jedoch Randfälle auf, die relevant sind. Hier sind drei, die manuelle Prozesse ins Stocken bringen:

ISS an der Quelle einbehalten (ISS Retido na Fonte)

Wenn eine NFS-e mit „ISS Retido na Fonte = Sim“ gekennzeichnet ist, geht die Pflicht zur Abführung der ISS an die Gemeinde vom Dienstleister auf den Leistungsempfänger – also auf Sie – über. Dies ist kein Datenvermerk, sondern ein steuerlicher Handlungsbedarf. Ihre Finanzabteilung muss: (1) diese Rechnungen im Extraktionsergebnis identifizieren, (2) den abzuführenden ISS-Betrag berechnen (der auf der Rechnung ausgewiesene Satz × Bemessungsgrundlage) und (3) die Zahlung fristgerecht an die zuständige Stadtverwaltung (Prefeitura) leisten.

Wird dieser Schritt versäumt, wurde die ISS an niemanden gezahlt – der Anbieter hat sie nicht gezahlt (da er sie als einbehalten deklariert hat), und Sie haben sie nicht gezahlt (da Sie das Kennzeichen übersehen haben). Beide Parteien sind gefährdet. Ein Extraktionsworkflow, der diese Dokumente automatisch kennzeichnet – indem das Feld „ISS Retido“ als Ja/Nein-Spalte extrahiert wird – verwandelt ein Compliance-Risiko in eine sortierbare Tabellenspalte.

Mehrere Servicecodes auf einer Rechnung

Eine einzelne NFS-e kann mehrere Positionen enthalten, jede mit eigenem LC-116-Servicecode und eigenem ISS-Satz. Eine IT-Beratung könnte „Análise e desenvolvimento de sistemas“ (Code 1.01, ISS 5 % in São Paulo) und „Suporte técnico“ (Code 1.07, ggf. anderer Satz) separat abrechnen. Wenn Sie nur den ISS-Gesamtbetrag auf Rechnungsebene extrahieren, geht die Klassifizierung pro Position verloren, die bestimmt, ob jede Position korrekt besteuert wurde. Definieren Sie Ihre Spalten so, dass Servicecodes und ISS-Beträge auf Positionsebene extrahiert werden, nicht nur der Rechnungsendbetrag.

Stapelverarbeitung über mehrere Dienstleister hinweg

Wenn Sie NFS-e-Dokumente von fünf verschiedenen Dienstleistern aus fünf verschiedenen Städten erhalten, potenziert sich der Vorteil der Stapelverarbeitung. Statt jedes PDF einzeln zu öffnen und Felder in separate Tabellenzeilen zu kopieren, laden Sie alle gemeinsam hoch. Die Extraktions-Engine verarbeitet sie parallel – eine einzelne Seite dauert 5 bis 10 Sekunden – und erstellt eine konsolidierte Tabelle mit allen Daten der Dienstleister in denselben Spalten. Das ist die praktische Antwort auf das Problem der kommunalen Fragmentierung: Die KI übernimmt die Layout-Unterschiede pro Dokument automatisch, und Ihr Team bearbeitet eine einzige Ausgabedatei.

Bei hohen Volumina – 50, 100 oder mehr NFS-e-Dokumente pro Monat – eliminiert die Stapel-Rechnungsextraktion nach Excel den Einrichtungsaufwand pro Dokument, der die manuelle Verarbeitung linear mit der Dokumentanzahl skalieren lässt.

Die Steuerreform 2026: Was sich für die NFS-e-Extraktion ändert

Brasilien befindet sich mitten in einer Steuerreform, die ISS und ICMS durch ein einheitliches IBS (Imposto sobre Bens e Serviços) ersetzen und PIS/COFINS durch CBS (Contribuição sobre Bens e Serviços) ablösen wird. Der Übergang erfolgt schrittweise – bis 2033 –, aber die NFS-e-Layouts werden bereits aktualisiert. São Paulo veröffentlichte im August 2025 Version 3.2 seines NFS-e-Handbuchs mit Feldern für die neue Steuerstruktur. Andere Gemeinden werden folgen.

Aus Sicht der Datenextraktion bedeutet dies zweierlei. Erstens werden Felder, die Sie heute extrahieren (ISS-Basis, ISS-Satz, ISS-Betrag), auf zukünftigen NFS-e-Dokumenten durch IBS/CBS-Felder ergänzt oder ersetzt. Zweitens können Sie während der Übergangszeit Rechnungen erhalten, die sowohl alte ISS-Felder als auch neue IBS-Felder enthalten – und Sie müssen beide für den Abgleich extrahieren.

Der oben beschriebene Extraktionsansatz handhabt dies natürlich. Da er nicht auf festen Feldpositionen oder hartcodierten Vorlagen basiert, werden neue Felder in einem aktualisierten NFS-e-Layout genauso extrahiert wie bestehende: Sie fügen den Spaltennamen hinzu (z. B. „IBS-Betrag“), und die KI findet ihn im Dokument. Keine Vorlagenneukonfiguration erforderlich.

Eine praktische Anleitung zur Extraktion von Steuerdaten aus brasilianischen Warenrechnungen – die ICMS, IPI, PIS und COFINS enthalten und einem anderen regulatorischen Rahmen unterliegen – finden Sie in unserem NF-e-XML-Extraktionsleitfaden. Wenn Sie auch brasilianische Lohnabrechnungsdokumente verarbeiten, deckt unser Holerite-Extraktionsleitfaden (Gehaltsabrechnung) diesen Workflow ab.

FAQ: Extraktion von NFS-e-Dienstleistungsrechnungen

Kann ich Daten aus einem NFS-e-PDF extrahieren, wenn ich keine XML-Datei habe?

Ja. Das PDF/DANFSE enthält alle für die Gemeinde verbindlichen Steuerfelder zur Validierung. Anders als das NF-e-DANFE – das rund 90 % der zugrunde liegenden XML-Daten auslässt – ist das NFS-e-Druckdokument eigenständiger, da die Gemeinden keinen einheitlichen Standard dafür haben, was in die XML-Datei gehört und was auf dem gedruckten Hilfsdokument erscheint. Die vollständige Liste der Felder in der obigen Anatomietabelle (CNPJ Leistungserbringer/-empfänger, LC-116-Code, ISS-Aufschlüsselung, NFS-e-Nummer, RPS-Nummer) ist in der Regel im PDF enthalten. Falls Sie jedoch Zugriff auf die XML-Datei haben, nutzen Sie diese – sie garantiert 100 % Feldabdeckung und eliminiert OCR-bedingte Ungenauigkeiten.

Funktioniert die Extraktion mit NFS-e-Dokumenten aus jeder brasilianischen Stadt?

Die semantische Extraktion liest Felder durch Verständnis des Dokumentinhalts, nicht durch Anpassung an das Layout einer bestimmten Stadt. Sie funktioniert mit NFS-e aus São Paulo, Rio de Janeiro, Belo Horizonte, Porto Alegre oder jeder anderen Gemeinde, ohne dass eine stadt-spezifische Vorlage erforderlich ist. Die Extraktionsgenauigkeit bei handschriftlichen NFS-e-Dokumenten – die selten sind (fast alle NFS-e werden maschinell erstellt) – ist jedoch geringer als bei gedruckten oder digitalen Dokumenten. Handschrifterkennung funktioniert, ist aber von Natur aus weniger genau als das Lesen von gedrucktem Text.

Was ist mit einbehaltener ISS – wie gehe ich mit der Steuerabführungspflicht um?

Extrahieren Sie das Feld „ISS Retido na Fonte“ als eigene Spalte. Jede Rechnung, bei der dieses Feld „Sim“ (oder „Ja“) lautet, sollte an Ihren Steuer-Compliance-Workflow weitergeleitet werden und nicht als Standard-Kreditoreneintrag verbucht werden. Der ISS-Satz und die ISS-Bemessungsgrundlage auf der Rechnung geben den abzuführenden Betrag an; die Gemeinde des Leistungserbringers gibt an, wohin die Abführung erfolgt. Das Extraktionstool liefert Ihnen die Daten. Die Steuerabführung selbst ist ein separater Compliance-Schritt, den Ihre Buchhaltungs- oder Steuerabteilung über das Zahlungssystem der jeweiligen Stadtverwaltung durchführen muss.

Kann ich NFS-e-Dokumente zusammen mit regulären internationalen Rechnungen stapelverarbeiten?

Ja. Wenn Ihre Spaltendefinitionen breit genug sind, um beide Dokumenttypen abzudecken (z. B. „Rechnungsnummer“, „Lieferantenname“, „Gesamtbetrag“), können Sie brasilianische NFS-e-Dokumente im selben Stapel wie internationale Rechnungen verarbeiten. Die Extraktions-Engine liest jedes Dokument unabhängig und füllt die Felder, die sie findet. Bei NFS-e-spezifischen Feldern – wie dem LC-116-Dienstleistungscode oder dem ISS-Betrag – bleiben die Spalten für nicht-brasilianische Rechnungen leer, was erwartet wird und keine Fehler verursacht.

Wie wirkt sich die Steuerreform 2026 auf die Extraktion von NFS-e-Feldern aus?

Die Reform ändert nicht die Funktionsweise der Extraktion – sie ändert, welche Felder auf zukünftigen NFS-e-Dokumenten erscheinen. Wenn Gemeinden ihre Layouts aktualisieren, um IBS- und CBS-Felder zusätzlich oder anstelle von ISS aufzunehmen, müssen Sie Ihre Spaltendefinitionen um die neuen Feldnamen erweitern. Der Extraktionsansatz bleibt gleich: Fügen Sie den neuen Spaltennamen hinzu, und die KI findet den entsprechenden Wert. Der schrittweise Übergang bis 2033 bedeutet, dass Sie während der Übergangsphase wahrscheinlich Dokumente mit alten und neuen Steuerfeldern verarbeiten werden.

Benötige ich eine brasilianische Steuernummer (CNPJ), um diesen Extraktionsansatz zu nutzen?

Nein. Die Datenextraktion aus einer erhaltenen NFS-e ist eine Dokumentenverarbeitungsaufgabe, keine Steuererklärungsaktion. Sie benötigen keine CNPJ, um Daten aus einem NFS-e-PDF oder XML in eine Tabelle zu extrahieren. Die CNPJ-Felder auf dem Dokument identifizieren den Dienstleister und den Leistungsempfänger; das Extraktionstool liest sie als Datenpunkte und platziert sie in Ihren Ausgabespalten – es interagiert nicht mit einem kommunalen Steuersystem.

Vom Einzeldokument-Tippen zur Stapelverarbeitung

Die NFS-e wurde entwickelt, um die Steuererhebung für die Regierung effizient zu gestalten – und das tut sie auch. Jede in Brasilien ausgestellte Dienstleistungsrechnung wird von einer kommunalen Steuerbehörde validiert, bevor sie Sie erreicht, was bedeutet, dass die Daten darauf bereits auf Konsistenz geprüft wurden. Die Ineffizienz liegt vollständig auf der Empfängerseite: Der AP-Sachbearbeiter tippt Felder neu ab, die eine Maschine bereits überprüft hat, aus einem Dokument, das je nach Stadt variiert, in eine Tabelle, die für die Steuerabstimmung korrekt sein muss.

Semantische Extraktion ändert die Empfängerseite dieser Gleichung. Die Felder sind bereits vorhanden, bereits validiert, bereits maschinenlesbar (oder fast). Sie in einem Stapel in Ihre Tabelle zu bekommen, ist eine Workflow-Entscheidung, kein technischer Durchbruch. Testen Sie es an Ihrem nächsten Stapel NFS-e-Dokumente – sehen Sie, ob die Zeit pro Dokument von der manuellen 3-Minuten-Marke auf die Sekunden sinkt, die es braucht, um Ihre Spalten einmal zu definieren und die Extraktion laufen zu lassen.