Multi-City NFS-e, One Spreadsheet:
Batch Without Municipal Templates

Warum die Batch-Verarbeitung von NFS-e ein anderes Problem ist als die Extraktion einzelner Dokumente

Wenn Sie den Leitfaden zur Extraktion einzelner NFS-e gelesen haben, kennen Sie den Kernmechanismus: Die semantische Extraktion liest eine NFS-e, indem sie versteht, was jedes Feld bedeutet – sie findet den 14-stelligen CNPJ des Dienstleisters neben dem Label „Prestador“, die ISS-Bemessungsgrundlage im ISS-Abschnitt, den ISS-Steuersatz, wo auch immer die Stadtverwaltung ihn gedruckt hat. Ein Dokument, ein Satz Spaltendefinitionen, eine Ausgabezeile. Das Problem der kommunalen Unterschiede wird auf Dokumentebene gelöst.

Die Batch-Verarbeitung bringt eine andere Klasse von Herausforderungen mit sich, die bei der Einzeldokumentextraktion nicht auftauchen. Wenn Sie 30 NFS-e-Dokumente von Dienstleistern aus São Paulo (ISS 5 % für IT-Beratung), Rio de Janeiro (ISS 5 % für dieselbe Dienstleistung), Belo Horizonte (ISS 3 %), Curitiba (ISS 4 %) und sechs weiteren Städten in eine Verarbeitungswarteschlange legen, passieren drei Dinge, die bei einem einzelnen Dokument nie passieren:

Erstens wird eine städteübergreifende Überprüfung des ISS-Steuersatzes notwendig. Eine einzelne NFS-e mit 3 % ISS sieht isoliert betrachtet korrekt aus. Aber wenn Sie sehen, dass derselbe Dienstleistungscode (Position 1.01 – Análise e desenvolvimento de sistemas, also IT-Analyse und -Entwicklung) im selben Batch mit 5 % aus São Paulo, 5 % aus Rio und 3 % aus Belo Horizonte auftaucht, sticht der Satz aus Belo Horizonte sofort hervor. Vielleicht ist er korrekt – Belo Horizonte legt seine eigenen Sätze fest. Vielleicht hat der Dienstleister den falschen kommunalen Satz angewendet. Nur eine Batch-Ansicht macht dies erkennbar.

Zweitens wird die Nachverfolgung der einbehaltenen ISS zu einer Compliance-Aufgabe im Batch-Maßstab. Wenn eine NFS-e mit „ISS Retido na Fonte = Sim“ markiert ist, geht die Pflicht zur Abführung der ISS vom Dienstleister auf den Dienstleistungsempfänger über – also auf Sie. Jedes Vorkommen erfordert eine separate Zahlung an die jeweilige Stadtverwaltung, jeweils mit eigenem Fälligkeitsdatum und eigenem Zahlungssystem. Bei 10 Dokumenten aus mehreren Städten ist die Nachverfolgung, welche Rechnungen diese Pflicht auslösen und welche nicht, als manuelle Checkliste nicht mehr zu bewältigen.

Drittens sind die Daten in der Summe wertvoller. ISS-Gesamtbeträge pro Dienstleister, Ausgaben pro Stadt, das Verhältnis von einbehaltener zu vom Dienstleister gezahlter Steuer – nichts davon ist bei einem einzelnen Dokument sichtbar. Diese Werte entstehen erst, wenn der gesamte Batch in einer Tabelle liegt.

Hier geht es nicht darum, den Einzeldokument-Workflow schneller auszuführen. Es geht darum, etwas zu tun, was der Einzeldokument-Workflow überhaupt nicht kann.

Was die NFS-e-Verarbeitung über Gemeindegrenzen hinweg grundlegend von Standard-Rechnungsstapeln unterscheidet

Die Standardverarbeitung von Rechnungsstapeln – 50 PDFs von 50 Lieferanten aus den USA oder Europa – ist in erster Linie ein Mengenproblem. Die Rechnungen sehen unterschiedlich aus, aber die zugrunde liegende Steuerlogik ist konsistent: MwSt. zum nationalen Satz, Umsatzsteuer je nach Bundesstaat, und die Felder befinden sich in weitgehend vorhersehbaren Positionen mit weitgehend vorhersehbaren Bezeichnungen.

Die brasilianische NFS-e-Stapelverarbeitung fügt eine strukturelle Ebene hinzu, die Standard-Rechnungsstapel nicht haben. Da die ISS eine kommunale Steuer ist, die durch das Ergänzungsgesetz 116/2003 geregelt wird, und da jede Gemeinde ihr eigenes Steuersystem betreibt, kann dasselbe logische Feld – „der ISS-Steuersatz“ – für jedes Dokument im Stapel einen anderen Wert tragen, und dieser Wert bestimmt, ob die Steuer für dieses Dokument korrekt berechnet wurde.

Hier wird die vorlagenbasierte Extraktion – der Ansatz, den die meisten Dokumentextraktionstools verwenden – strukturell unpraktikabel. Eine Vorlage definiert einen rechteckigen Bereich für jedes Feld: „Der CNPJ des Dienstleisters befindet sich an Pixelposition (x=150, y=320).“ Das funktioniert für eine Gemeinde. Für die nächste bricht es. Eine Vorlagenbibliothek für jede Stadt, in der Ihre Anbieter zufällig tätig sind, zu pflegen, ist nicht praktikabel, wenn die Anzahl der möglichen Städte 5.570 beträgt und die Anzahl der Städte, die ihre Layouts aktiv aktualisieren – São Paulo hat im August 2025 Version 3.2 seines NFS-e-Handbuchs veröffentlicht – ständig wächst.

Die Alternative ist die semantische Extraktion: Statt zu definieren, wo ein Feld auf der Seite sitzt, sagen Sie der Extraktionsengine, wonach Sie suchen – „der 14-stellige CNPJ mit der Bezeichnung Prestador“ – und sie liest das Dokument, um es zu finden. Die Position spielt keine Rolle, weil die Engine den Inhalt des Dokuments versteht, nicht seine Koordinaten. Eine NFS-e aus São Paulo und eine NFS-e aus Porto Alegre im selben Stapel werden mit denselben Spaltendefinitionen verarbeitet, weil die KI nach Bedeutung sucht und nicht nach einer Position.

Eine vollständige Aufschlüsselung, wie die semantische Extraktion einzelne NFS-e-Felder behandelt – CNPJ-Abgleich, LC-116-Dienstleistungscode-Klassifizierung, die ISS-Steueraufschlüsselung – finden Sie im Leitfaden zur Einzel-NFS-e-Extraktion. Der Stapelworkflow übernimmt all das und fügt die Mehrebenen-Dokumentebene hinzu.

Wie die semantische Extraktion 10 Städte-NFS-e in einem Batch verarbeitet

Der Extraktionsworkflow für die Batch-NFS-e-Verarbeitung konzentriert sich auf die benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen in Ihre Ausgabe ein – „CNPJ des Ausstellers“, „Dienstleistungscode (LC 116)“, „ISS-Satz“, „ISS-Betrag“, „ISS einbehalten (Retido na Fonte)“, „NFS-e-Nummer“ – und die KI findet jeden Wert auf jedem Dokument, indem sie die Bedeutung der Bezeichnung versteht. Diese Spaltennamen werden zu Ihren Tabellenkopfzeilen. Sie definieren sie einmal. Sie funktionieren für jede Gemeinde im Batch.

Die Batch-NFS-e-Verarbeitung profitiert jedoch von mehr als nur der direkten Extraktion. Zwei zusätzliche Spaltenmodi ermöglichen die städteübergreifende Abstimmung bereits zum Zeitpunkt der Extraktion, nicht in einer separaten Tabellenkalkulation:

Berechnete Spalten ermöglichen es Ihnen, Validierungslogik zu definieren, die während der Extraktion ausgeführt wird. Für die NFS-e-Batchverarbeitung ist die nützlichste berechnete Spalte eine ISS-Überprüfung: „ISS-Satz × ISS-Bemessungsgrundlage = ISS-Betrag?“ Wenn der berechnete Gesamtbetrag mit dem extrahierten ISS-Betrag übereinstimmt, gibt die Spalte „OK“ aus. Wenn nicht, gibt sie die Abweichung aus – und kennzeichnet auf Batchebene, welche Dokumente vor dem Import der Daten in Ihr ERP-System noch einmal überprüft werden müssen. Bei einem einzelnen Dokument dauert diese Prüfung 30 Sekunden. Bei 50 Dokumenten erledigt eine berechnete Spalte dies automatisch – und Sie sehen das Ergebnis in derselben Tabelle wie die extrahierten Daten.

Abgeleitete Spalten ermöglichen es der KI, Dokumente anhand ihres Inhalts zu klassifizieren oder zu kennzeichnen. Fügen Sie eine Spalte mit dem Namen „Gemeinde (aus Dokument extrahiert)“ ohne spezifischen Feldverweis hinzu, und die KI liest die Kennung der Prefeitura (Rathaus) aus der NFS-e und füllt den Stadtnamen ein. Jetzt hat Ihre Batch-Ausgabe eine sortierbare Gemeindespalte – und die ISS-Gesamtsummen pro Stadt sowie die Steuerberichterstattung pro Stadt sind nur noch eine Pivot-Tabelle entfernt, anstatt einer manuellen Querverweis-Übung.

Diese drei Spaltentypen – direkte Extraktion, berechnet und abgeleitet – arbeiten in einem einzigen Batch-Durchlauf zusammen. Sie extrahieren nicht zuerst und validieren später. Die Validierung erfolgt während der Extraktion, und die Ergebnisse landen in derselben Tabelle.

Schritt für Schritt: Vom Multi-Stadt-NFS-e-Stapel zur Tabelle

So funktioniert der praktische Workflow für die Stapelverarbeitung von NFS-e-Dokumenten aus mehreren brasilianischen Gemeinden in eine einzige Excel-Datei. Sie richten dies einmal pro Stapel ein – dieselben Spaltendefinitionen verarbeiten jedes Dokument, unabhängig von der Herkunftsstadt.

Städteübergreifender ISS-Abgleich: Die Batch-Perspektive

Das wertvollste Ergebnis der NFS-e-Batch-Verarbeitung ist nicht die Zeitersparnis – auch wenn der Sprung von 3 Minuten pro Dokument auf 5–10 Sekunden pro Seite eine 18-fache Verbesserung bedeutet. Das wertvollste Ergebnis ist die Abgleichsansicht, die nur existiert, wenn alle Dokumente in einer Tabelle zusammengeführt sind.

Hier sehen Sie, was diese Ansicht ermöglicht, was die Einzeldokument-Verarbeitung nicht kann:

ISS-Gesamtbeträge pro Stadt

Gruppieren Sie die Ausgabe nach Gemeinde und summieren Sie den ISS-Betrag. Das Ergebnis ist die gesamte ISS, die auf Ihre Dienstleistungskäufe in jeder Stadt angewendet wurde – Daten, die aus zwei Gründen wichtig sind. Erstens zeigt es Ihnen, ob die gesamte ISS aller Anbieter in einer bestimmten Stadt mit Ihrer internen Kostenzuordnung für diese Gerichtsbarkeit übereinstimmt. Zweitens: Wenn Sie bei einer dieser Rechnungen der ISS-Einbehaltungsverpflichtete sind, ist der Gesamtbetrag pro Stadt die Zahl, die Sie mit Ihren kommunalen Steuerüberweisungsunterlagen abgleichen müssen. Dentons' globaler Steuerleitfaden weist darauf hin, dass „Konflikte zwischen verschiedenen Gemeinden, die beide ISS beanspruchen, recht häufig vorkommen" – eine Batch-Ansicht ist Ihr Prüfpfad, falls eine zweite Gemeinde nachfragt.

Verfolgung einbehaltener ISS

Wenn eine NFS-e das Kennzeichen „ISS Retido na Fonte = Sim" (einbehaltene ISS an der Quelle) trägt, ist Ihr Unternehmen – nicht der Dienstleister – für die Überweisung der ISS an die Gemeinde des Dienstleisters verantwortlich. Dies ist keine Dateneingabeanmerkung; es ist ein steuerlicher Compliance-Punkt mit einer Frist und einem Zahlungssystem, das sich je nach Stadt unterscheidet. In einer Batch-Ausgabe erhalten Sie durch Sortieren nach der Spalte „Einbehaltene ISS" eine vollständige Einzelansicht aller Rechnungen, die Ihr Handeln erfordern. Kein Durchsuchen von 30 einzelnen PDFs, um die drei mit dem Kennzeichen zu finden.

Der rechtliche Rahmen für den ISS-Einbehalt wurde vor Brasiliens höchstem Gericht geprüft. Im Jahr 2020 entschied der brasilianische Oberste Bundesgerichtshof (STF) in RE 1167509, dass Gemeinden Dienstleistungsempfängern keine ISS-Einbehaltungspflichten auferlegen können, wenn der Anbieter nicht in dieser Gemeinde registriert ist – und hob damit die CPOM-Registrierungspflicht von São Paulo auf. Einbehaltungspflichten, die durch Bundesgesetz festgelegt sind und bei denen die Kombination aus Dienstleistungsart und Gemeinde eine legitime Einbehaltung auslöst, bleiben jedoch in Kraft. Zu wissen, welche Rechnungen eine gültige Einbehaltungspflicht tragen, erfordert die Betrachtung des Batches.

Erkennung von ISS-Steuersatzabweichungen

Das Ergänzungsgesetz 116/2003 legt ISS-Steuersätze zwischen 2 % und 5 % je Gemeinde und Dienstleistungsart fest. Doch Gemeinden konkurrieren bei den Sätzen um Unternehmen – die UNDP-Diagnoseprüfung des brasilianischen Steuersystems spricht von einem „räuberischen Wettbewerb bei ICMS- und ISS-Steueranreizen“. Ein Dienstleister könnte für einen Dienstleistungscode, den São Paulo mit 5 % besteuert, einen Satz von 2 % anwenden, weil er in einer Gemeinde registriert ist, die ihren Satz gesenkt hat, um Unternehmen anzuziehen. Ob dieser Satz gültig ist, ist eine Steuerentscheidung Ihres Buchhaltungsteams. Aber das Erkennen erfordert den Blick auf die gesamte Charge. Ein einzelnes Dokument mit 2 % wirkt normal. Zehn Dokumente mit 5 % und eines mit 2 %, alle für denselben Dienstleistungscode – das ist eine Abweichung, die eine Untersuchung wert ist.

Was der nationale NFS-e-Standard für die Batch-Verarbeitung bedeutet

Das SNNFS-e (Nationales NFS-e-System) ist Brasiliens Versuch, die Formate für Dienstleistungsrechnungen über alle Gemeinden hinweg zu vereinheitlichen. Bis August 2025 hatten sich 1.463 Gemeinden angeschlossen – doch die Teilnahme ist freiwillig, und Großstädte wie São Paulo haben öffentlich bestätigt, dass sie ihre eigenen Systeme behalten werden. Das Ergebnis ist eine hybride Landschaft: Einige Ihrer Dienstleister stellen NFS-e im nationalen XML-Standard aus, andere über das eigene System ihrer Stadt – und Sie haben keine Kontrolle darüber, welches verwendet wird.

Aus Sicht der Batch-Verarbeitung unterstreicht diese hybride Landschaft den Wert der formatunabhängigen Extraktion. Vorlagenbasierte Tools benötigen nun Vorlagen sowohl für die alten städtischen Layouts als auch für den SNNFS-e-Standard – plus Aktualisierungspfade, wenn Gemeinden von einem zum anderen migrieren. Semantische Extraktion liest, was auf dem Dokument steht, unabhängig davon, welcher Standard es erzeugt hat. Eine NFS-e im nationalen Standard und eine NFS-e im benutzerdefinierten Format aus São Paulo landen in derselben Charge, definieren dieselben Spalten und erzeugen dieselbe Ausgabe. Der Standardisierungsprozess ändert den Dokumentinhalt, nicht den Extraktionsansatz.

Die Steuerreform 2026 – die ISS bis 2033 schrittweise durch IBS (Steuer auf Waren und Dienstleistungen) ersetzen wird – fügt eine weitere Ebene hinzu. Während des Übergangs können NFS-e-Dokumente sowohl alte ISS-Felder als auch neue IBS/CBS-Felder enthalten. Der Extraktionsansatz passt sich an, indem neue Spaltennamen – „IBS-Betrag“, „CBS-Betrag“ – neben den bestehenden ISS-Spalten hinzugefügt werden. Keine Vorlagenüberarbeitung erforderlich.

Wenn Ihr Unternehmen auch brasilianische Warenrechnungen verarbeitet, wird der NF-e-XML-Extraktionsworkflow im NF-e-Extraktionsleitfaden behandelt. Beide Dokumenttypen können in derselben Charge koexistieren, wenn Ihre Spaltendefinitionen breit genug sind – auch wenn NFS-e-spezifische Felder wie der LC-116-Code bei NF-e-Dokumenten leer bleiben, was erwartet wird und keine Fehler verursacht.

FAQ: Stapelverarbeitung von NFS-e

Kann ich NFS-e-Dokumente von Dienstleistern aus verschiedenen Städten zusammen stapelverarbeiten?

Ja – das ist der Hauptanwendungsfall. Die semantische Extraktion liest jedes Dokument unabhängig, indem sie den Inhalt versteht, nicht das Layout einer bestimmten Stadt. Eine NFS-e aus São Paulo (ISS 5 %), eine aus Belo Horizonte (ISS 3 %) und eine aus Curitiba (ISS 4 %) werden im selben Stapel mit denselben Spaltendefinitionen verarbeitet. Die KI findet die CNPJ do Prestador, die ISS-Bemessungsgrundlage und weitere Felder in jedem Dokument, unabhängig davon, wo sie auf der Seite erscheinen.

Wie wird ISS Retido na Fonte in der Stapelausgabe behandelt?

Das Feld „ISS einbehalten" wird als eigene Spalte extrahiert – typischerweise mit „Sim" (Ja) oder „Não" (Nein). In der Stapelausgabe-Tabelle erhalten Sie durch Sortieren nach dieser Spalte eine vollständige Liste aller Rechnungen, bei denen Ihr Unternehmen der Steuerabzugsverpflichtete ist. Daraus berechnen Sie den abzuführenden Betrag (ISS-Satz × Bemessungsgrundlage jeder gekennzeichneten Rechnung) und leiten ihn an das Zahlungssystem der jeweiligen Stadtverwaltung weiter. Das Extraktionstool liefert die Daten. Die Steuerabführung selbst bleibt ein separater Compliance-Schritt, den Ihre Buchhaltung über das Zahlungsportal jeder Gemeinde durchführt.

Was passiert, wenn ein Dienstleister eine NFS-e mit Layoutfehlern oder fehlenden Feldern ausstellt?

Die Extraktionsengine liest, was auf dem Dokument steht. Fehlt ein Pflichtfeld – z. B. die CNPJ – oder ist es unleserlich, bleibt die entsprechende Zelle in der Ausgabe leer. Das ist sogar nützlich: Eine leere Zelle in der Stapelausgabe zeigt sofort, welches Dokument eine Nachverfolgung beim Dienstleister benötigt, während bei manueller Eingabe von 30 Dokumenten ein leeres Feld leicht übersehen werden kann. Die Stapelansicht macht Auslassungen sichtbar.

Kann ich NFS-e-Dokumente mit internationalen Dienstleistungsrechnungen im selben Stapel mischen?

Ja. Wenn Ihre Spaltendefinitionen beide Dokumenttypen abdecken – z. B. „Rechnungsnummer", „Lieferantenname", „Gesamtbetrag", „Steuerbetrag" – können internationale Rechnungen und NFS-e-Dokumente im selben Stapel koexistieren. NFS-e-spezifische Spalten wie „LC 116 Service Code" oder „ISS-Satz" bleiben bei nicht-brasilianischen Dokumenten leer, und internationale Spalten wie „VAT-Nummer" bleiben bei NFS-e-Dokumenten leer. Beides ist erwartetes Verhalten und verursacht keine Fehler.

Verarbeitet die Extraktions-Engine die Felder der Steuerreform 2026 (IBS/CBS) auf NFS-e-Dokumenten?

Ja — wenn eine Gemeinde ihr NFS-e-Layout um IBS- oder CBS-Felder erweitert, fügen Sie die entsprechenden Spaltennamen (z. B. „IBS-Betrag“, „CBS-Betrag“) zu Ihrer Batch-Definition hinzu. Die Extraktions-Engine findet diese neuen Felder, indem sie den Dokumentinhalt versteht, genauso wie sie bestehende ISS- und CNPJ-Felder findet. Keine Vorlagen-Neukonfiguration erforderlich. Während der Übergangsphase bis 2033 können Sie Batches mit NFS-e-Dokumenten ausführen, die sowohl ISS- als auch IBS-Felder enthalten — definieren Sie Spalten für beide, und die Ausgabe füllt die Felder, die auf jedem Dokument vorhanden sind.

Wie schneidet die Batch-Verarbeitung im Vergleich zur direkten API-Integration jeder Gemeinde ab?

Die Integration kommunaler APIs erfordert den Aufbau und die Pflege einer separaten Verbindung für jede Stadt, in der Ihre Dienstleister tätig sind — jeweils mit eigener Authentifizierungsmethode, eigenem Schema und eigenem Aktualisierungsplan. Der nationale Standard SNNFS-e vereinfacht dies für teilnehmende Gemeinden, aber Großstädte wie São Paulo haben sich dagegen entschieden. Die semantische Batch-Extraktion verarbeitet die Dokumente, die Sie bereits erhalten — PDFs, XMLs, DANFSE-Ausdrucke — ohne API-Zugriff auf kommunale Systeme. Sie ist kein Ersatz für die API-Integration bei der Ausstellung von NFS-e. Sie ist die Lösung für die Empfängerseite, wenn Sie der Dienstleistungsempfänger (Tomador) sind, nicht der Aussteller.

Für einen breiteren Blick auf die Batch-Dokumentextraktion über NFS-e hinaus, sehen Sie, wie Batch-Rechnungsextraktion nach Excel über Dokumenttypen und Währungen hinweg funktioniert.

Von der Eingabe pro Gemeinde zur Abstimmung pro Batch

Die NFS-e wurde entwickelt, um die Steuererhebung für die Regierung effizient zu gestalten — und das tut sie. Jede Service-Rechnung, die Sie erhalten, wurde von einer kommunalen Steuerbehörde validiert, bevor sie in Ihrem Posteingang ankam. Der CNPJ wurde geprüft. Der ISS-Steuersatz wurde gegen den Servicecode verifiziert. Die Rechnungsnummer wurde vergeben. Diese Daten existieren. Sie sind korrekt. Sie haben einen staatlichen Validierungsschritt durchlaufen, den die meisten internationalen Rechnungen nie sehen.

Die Ineffizienz liegt vollständig auf der Empfängerseite: das erneute Abtippen validierter Felder aus Dokumenten, die je nach Stadt variieren, in eine Tabelle, die für die SPED-Abstimmung korrekt sein muss. Die semantische Batch-Extraktion schließt diese Lücke nicht, indem sie das Tippen beschleunigt, sondern indem sie es überflüssig macht — und gibt Ihnen dadurch die gemeindeübergreifende Sicht, die manuelle Eingabe nie erzeugen könnte.

Wenn Sie das nächste Mal einen Stapel NFS-e von Dienstleistern aus São Paulo, Rio, Belo Horizonte und darüber hinaus erhalten, versuchen Sie, sie als einen Batch zu verarbeiten. Definieren Sie Ihre Spalten einmal. Lassen Sie die Extraktion laufen. Sortieren Sie dann nach Gemeinde und prüfen Sie die ISS-Summen. Sehen Sie, ob die Batch-Ansicht etwas zeigt, das die einzelnen Dokumente nicht gezeigt haben.