Multi-City NFS-e, Eine Tabelle:
Stapelverarbeitung ohne Gemeinde-Vorlagen

Warum die Stapelverarbeitung von NFS-e ein anderes Problem ist als die Einzelbelegextraktion

Wenn Sie den Leitfaden zur Einzel-NFS-e-Extraktion gelesen haben, kennen Sie den Kernmechanismus: Die semantische Extraktion liest eine NFS-e, indem sie die Bedeutung jedes Feldes versteht – die 14-stellige CNPJ do Prestador (Steuernummer des Dienstleisters) neben der Bezeichnung "Prestador" lokalisiert, die ISS base de cálculo (Bemessungsgrundlage) im ISS-Abschnitt, die alíquota ISS (ISS-Satz) dort, wo die Gemeinde sie gedruckt hat. Ein Dokument, eine Reihe von Spaltendefinitionen, eine Ausgabezeile. Das Problem der kommunalen Unterschiede wird auf Dokumentebene gelöst.

Die Stapelverarbeitung bringt eine andere Art von Herausforderungen mit sich, die bei der Einzelbelegextraktion 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 denselben Dienst), Belo Horizonte (ISS 3 %), Curitiba (ISS 4 %) und sechs weiteren Städten in eine Verarbeitungswarteschlange geben, passieren drei Dinge, die bei einem einzelnen Dokument nie passieren:

Erstens wird eine städteübergreifende ISS-Satzprüfung erforderlich. Eine einzelne NFS-e mit 3 % ISS sieht isoliert betrachtet in Ordnung aus. Aber wenn Sie sehen, dass derselbe Dienstleistungscode (Punkt 1.01 — Análise e desenvolvimento de sistemas, oder IT-Analyse und -Entwicklung) im selben Stapel mit 5 % aus São Paulo, 5 % aus Rio und 3 % aus Belo Horizonte erscheint, 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. Eine Ansicht auf Stapelebene ist die einzige Möglichkeit, dies zu erkennen.

Zweitens wird die Nachverfolgung von ISS Retido na Fonte (einbehaltener ISS) zu einer Compliance-Aufgabe auf Stapelebene. Wenn eine NFS-e mit "ISS Retido na Fonte = Sim" gekennzeichnet ist, geht die Verpflichtung zur Abführung des ISS vom Dienstleister auf den Dienstleistungsempfänger – Sie – über. Jedes Vorkommnis erfordert eine separate Zahlung an die jeweilige Prefeitura (Gemeinde), jede mit eigenem Fälligkeitsdatum und eigenem Zahlungssystem. Bei 10 Dokumenten aus mehreren Städten ist die Nachverfolgung, welche Rechnungen diese Verpflichtung auslösen und welche nicht, als manuelle Checkliste nicht handhabbar.

Drittens sind die Daten in ihrer Gesamtheit wertvoller. ISS-Gesamtsummen pro Dienstleister, Dienstleistungsausgaben pro Stadt, das Verhältnis von einbehaltener zu vom Dienstleister gezahlter Steuer – nichts davon ist aus einem einzelnen Dokument auf einmal ersichtlich. Sie treten erst zutage, wenn der gesamte Stapel in einer Tabelle vorliegt.

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

Was die verarbeitung von NFS-e über Gemeindegrenzen hinweg grundlegend von Standard-Rechnungssammelverarbeitung unterscheidet

Die Standard-Sammelverarbeitung von Rechnungen – 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: Mehrwertsteuer zum nationalen Satz, Umsatzsteuer nach Bundesstaat, und die Felder befinden sich an grob vorhersagbaren Positionen mit grob vorhersagbaren Bezeichnungen.

Die brasilianische NFS-e-Sammelverarbeitung fügt eine strukturelle Ebene hinzu, die die Standard-Rechnungssammelverarbeitung nicht hat. Da die ISS eine kommunale Steuer ist, die durch Lei Complementar 116/2003 geregelt wird, und da jede Gemeinde ihr eigenes Steuersystem betreibt, kann dasselbe logische Feld – „der ISS-Satz“ – für jedes Dokument im Stapel einen anderen Wert haben, 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 undurchführbar. Eine Vorlage definiert einen rechteckigen Bereich für jedes Feld: „CNPJ do Prestador befindet sich an Pixelposition (x=150, y=320).“ Das funktioniert für eine Gemeinde. Für die nächste bricht es. Die Pflege einer Vorlagenbibliothek für jede Stadt, in der Ihre Anbieter zufällig tätig sind, 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: Anstatt zu definieren, wo ein Feld auf der Seite sitzt, teilen Sie der Extraktions-Engine mit, wonach Sie suchen – „die 14-stellige CNPJ mit der Bezeichnung Prestador“ – und sie liest das Dokument, um es zu finden. Die Position spielt keine Rolle, da 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, da die KI nach Bedeutung sucht, nicht nach einer Position.

Für die vollständige Aufschlüsselung, wie die semantische Extraktion einzelne NFS-e-Felder verarbeitet – CNPJ-Abgleich, LC 116-Dienstleistungscode-Klassifizierung, die ISS-Steueraufschlüsselung – siehe die Anleitung zur Extraktion einzelner NFS-e. Der Stapel-Workflow erbt all dies und fügt die Multi-Dokument-Ebene 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.

Stadtübergreifender ISS-Abgleich: Die Batch-Ansicht

Der größte Mehrwert der Batch-NFS-e-Verarbeitung liegt nicht in der Zeitersparnis – auch wenn der Sprung von 3 Minuten pro Dokument auf 5–10 Sekunden pro Seite eine 18-fache Verbesserung bedeutet. Der größte Mehrwert ist die Abgleichsansicht, die es nur gibt, wenn alle Dokumente in einer Tabelle zusammengefasst sind.

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

ISS-Summen pro Stadt

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

ISS Retido na Fonte Tracking

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 Abführung der ISS an die Gemeinde des Dienstleisters verantwortlich. Dies ist kein bloßer Datenvermerk, sondern ein steuerlicher Pflichtenpunkt mit Frist und einem je nach Stadt unterschiedlichen Zahlungssystem. In einer Batch-Ausgabe erhalten Sie durch Sortieren nach der Spalte „ISS Retido“ eine vollständige, einheitliche Liste 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 dem höchsten Gericht Brasiliens geprüft. Im Jahr 2020 entschied der Oberste Bundesgerichtshof Brasiliens (STF) im Fall RE 1167509, dass Gemeinden Dienstleistungsnehmern keine ISS-Einbehaltspflicht auferlegen können, wenn der Dienstleister nicht in dieser Gemeinde registriert ist – und hob damit die CPOM-Registrierungspflicht (Cadastro de Prestadores de Outros Municípios) von São Paulo auf. Einbehaltspflichten, die durch Bundesgesetz festgelegt sind und bei denen die Kombination aus Dienstleistungsart und Gemeinde einen rechtmäßigen Einbehalt auslöst, bleiben jedoch in Kraft. Um zu wissen, welche Rechnungen eine gültige Einbehaltspflicht tragen, muss man den Batch sehen.

ISS-Satzvarianz-Erkennung

Das LC 116/2003 legt ISS-Sätze zwischen 2 % und 5 % pro Gemeinde und Dienstleistungsart fest. Doch Gemeinden konkurrieren mit den Sätzen um Unternehmen – der Diagnosebericht des UNDP zum brasilianischen Steuersystem stellt „einen räuberischen Wettbewerb um ICMS- und ISS-Steueranreize“ fest. 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 steuerliche Entscheidung Ihrer Buchhaltung. Aber ihn zu erkennen erfordert, den Batch zu sehen. Ein einzelnes Dokument mit 2 % wirkt normal. Zehn Dokumente mit 5 % und eines mit 2 %, alle für denselben Dienstleistungscode – das ist eine Varianz, die eine Untersuchung wert ist.

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

Das Sistema Nacional da NFS-e (SNNFS-e, Nationales NFS-e-System) ist Brasiliens Versuch, die Formate von Dienstleistungsrechnungen landesweit zu vereinheitlichen. Bis August 2025 hatten 1.463 Gemeinden zugestimmt – die Teilnahme ist jedoch 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 Lieferanten stellen NFS-e im nationalen XML-Standard aus, andere im stadteigenen System – und Sie haben keine Kontrolle darüber.

Aus Sicht der Stapelverarbeitung unterstreicht diese hybride Landschaft den Wert layoutunabhängiger Extraktion. Vorlagenbasierte Tools benötigen nun Vorlagen sowohl für die städtischen Layouts vor der Standardisierung als auch für den SNNFS-e-Standard – plus Aktualisierungspfade, wenn Städte von einem zum anderen wechseln. Semantische Extraktion liest, was immer im Dokument steht, unabhängig vom zugrunde liegenden Standard. Eine NFS-e im nationalen Standard und eine NFS-e im benutzerdefinierten Format aus São Paulo landen im selben Batch, definieren dieselben Spalten und liefern dieselbe Ausgabe. Der Standardisierungsprozess ändert den Dokumentinhalt, nicht die Extraktionsmethode.

Die Steuerreform 2026 – die ISS schrittweise bis 2033 durch IBS (Imposto sobre Bens e Serviços) 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. Die Extraktionsmethode 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. Die beiden Dokumenttypen können im selben Batch koexistieren, wenn Ihre Spaltendefinitionen breit genug sind – allerdings bleiben NFS-e-spezifische Felder wie der LC-116-Code bei NF-e-Dokumenten leer, 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) in NFS-e-Dokumenten?

Ja — sobald 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 durch das Verständnis des Dokumentinhalts – genauso wie sie bestehende ISS- und CNPJ-Felder findet. Eine Neukonfiguration der Vorlage ist nicht erforderlich. Während der Übergangsphase bis 2033 können Sie Batches mit NFS-e-Dokumenten verarbeiten, die sowohl ISS- als auch IBS-Felder enthalten – definieren Sie Spalten für beide, und die Ausgabe befüllt die jeweils im Dokument vorhandenen Felder.

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

Die Integration kommunaler APIs erfordert den Aufbau und die Wartung einer separaten Verbindung für jede Stadt, in der Ihre Lieferanten tätig sind – jede mit eigener Authentifizierungsmethode, eigenem Schema und eigenem Aktualisierungsplan. Der nationale SNNFS-e-Standard vereinfacht dies für teilnehmende Gemeinden, aber Großstädte wie São Paulo haben den Beitritt abgelehnt. Die semantische Batch-Extraktion verarbeitet die Dokumente, die Sie bereits erhalten – PDFs, XMLs, DANFSE-Ausdrucke – ohne API-Zugriff auf ein kommunales System. 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 Leistungsempfänger (Tomador) und nicht der Aussteller sind.

Für einen breiteren Überblick über die Batch-Dokumentenextraktion über NFS-e hinaus, erfahren Sie, wie Batch-Rechnungsextraktion nach Excel über verschiedene Dokumenttypen und Währungen hinweg funktioniert.

Von der gemeindespezifischen Erfassung zur batchweisen Abstimmung

Die NFS-e wurde entwickelt, um die Steuererhebung für den Staat effizient zu gestalten – und das tut sie auch. Jede von Ihnen erhaltene Dienstleistungsrechnung wurde von einer kommunalen Steuerbehörde validiert, bevor sie in Ihrem Posteingang landete. Der CNPJ wurde geprüft. Der ISS-Satz wurde anhand des Dienstleistungscodes 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 ausschließlich 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 so die gemeindeübergreifende Sicht, die die manuelle Eingabe nie liefern könnte.

Wenn Sie das nächste Mal einen Stapel NFS-e von Lieferanten aus São Paulo, Rio, Belo Horizonte und anderen Städten erhalten, versuchen Sie, diese 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 offenbart, was die einzelnen Dokumente nicht taten.