Warum die brasilianische NFS-e-Verarbeitung
teurer ist, als Finanzteams denken

Die einfachste Steuer, der zersplittertste Prozess

ISS hat eine Aufgabe: Steuerdienstleistungen zu 2 % bis 5 % und die Einnahmen an die Stadt senden, in der der Anbieter ansässig ist. Es gibt kein Kreditsystem, keine zwischenstaatliche Steuertabelle, keine Debatte über Bestimmungs- vs. Ursprungsort in drei Vierteln der Fälle. Dennoch ist die Verarbeitung einer NFS-e – das Extrahieren ihrer Daten in eine Tabelle, der Abgleich mit einem Lieferantenstamm, die Prüfung des Steuerbetrags – eine Operation, die die vorlagenbasierte Automatisierung in 5.570 Gemeinden sprengt.

Die meisten AP-Teams entdecken diese Zersplitterung nach und nach. Es beginnt mit einer einzelnen NFS-e von einer IT-Beratung in São Paulo. Die Felder sind klar: CNPJ do Prestador (Steuer-ID des Dienstleisters), NFS-e-Nummer, ISS base de cálculo (Bemessungsgrundlage), alíquota ISS (Steuersatz), valor ISS (Steuerbetrag). Jemand trägt sie in eine Tabelle ein. Es funktioniert. Dann kommt eine weitere NFS-e von einer Anwaltskanzlei in Rio de Janeiro. Dieselben Felder existieren, aber sie sind anders angeordnet – die CNPJ des Anbieters steht in einer Seitenleiste, die ISS-Aufschlüsselung ist auf zwei Felder verteilt, der Dienstleistungscode ist anders bezeichnet. Und dann kommt eine dritte aus Belo Horizonte. Und eine vierte aus Porto Alegre. Jedes Dokument enthält denselben Typ von Daten. Keines präsentiert sie auf dieselbe Weise.

Das Problem ist nicht, dass NFS-e-Daten unlesbar sind. Es ist, dass die Daten sich weigern, in ein einziges Format zu konvergieren – und sie wurden rechtlich so konzipiert, dass sie das nicht tun.

Hier liegt der Fehler der meisten Analysen zur Komplexität brasilianischer Rechnungen. Sie behandeln die NFS-e-Zersplitterung als technisches Problem – eine Interoperabilitätslücke, die eine Middleware-API oder ein nationaler XML-Standard irgendwann schließen wird. Das ist nicht der Fall. Es ist ein jurisdiktionelles Problem, verwurzelt in der brasilianischen Bundesverfassung von 1988, die jeder Gemeinde die steuerliche Autonomie über ihre eigene Dienstleistungssteuer gewährte. Die Zersplitterung der NFS-e ist keine vorübergehende Unannehmlichkeit. Sie ist die beabsichtigte Struktur des brasilianischen Steuerföderalismus und existierte bereits zwei Jahrzehnte vor der digitalen Rechnung.

LC 116/2003: Das Gesetz, das 5.570 Steuersysteme schuf

Um zu verstehen, warum NFS-e-Layouts von Stadt zu Stadt variieren, muss man vom Dokument zum ermächtigenden Gesetz zurückgehen. 2003 erließ Brasilien das Lei Complementar 116/2003 (Ergänzungsgesetz 116) – das definitive Bundesgesetz zur Regelung der ISS. LC 116 tat zwei Dinge gleichzeitig. Erstens schuf es einen nationalen Rahmen: eine Liste von etwa 40 Dienstleistungskategorien, einen Mindestsatz von 2 %, einen Höchstsatz von 5 % und allgemeine Regeln, welche Stadt in welchem Szenario die Steuer erhebt. Zweitens – und das ist der operative Punkt für AP-Teams – überließ es jeder Gemeinde, innerhalb dieses Rahmens eigene Gesetze zu erlassen.

Dies war kein Versehen. Die Verfassung von 1988 verteilte die Steuerhoheit bewusst auf drei Regierungsebenen: Bund, Bundesstaaten und Gemeinden. Die Bundesstaaten erhielten die ICMS (Waren). Die Gemeinden erhielten die ISS (Dienstleistungen). Jeder der 26 Bundesstaaten Brasiliens hat seine eigene ICMS-Verordnung, was 27 verschiedene Steuerregime ergibt (einschließlich des Bundesdistrikts). Für die NFS-e ist der Maßstab jedoch zwei Größenordnungen größer: 5.570 Gemeinden, jede mit der rechtlichen Befugnis, ihren eigenen ISS-Satz, ihren eigenen Compliance-Kalender, ihren eigenen Webservice zur Rechnungsvalidierung und – entscheidend für die Datenverarbeitung – ihr eigenes Dokumentenlayout festzulegen.

Das praktische Ergebnis ist etwas, das kein vorlagenbasiertes Extraktionstool überlebt. Eine in São Paulo ausgestellte Dienstleistungsrechnung platziert die base de cálculo ISS (ISS-Bemessungsgrundlage) an einer Stelle; eine Rechnung aus Campinas – einer 100 Kilometer entfernten Stadt – platziert sie an einer anderen. Das ISS-Satzfeld könnte in einer Gemeinde mit „Alíquota", in einer anderen mit „Alíquota ISS" beschriftet und in einer dritten in eine Tabellenzeile eingebettet sein. Eine Vorlage, die für São Paulo funktioniert, versagt in Campinas, was in Guarulhos versagt, was in den 5.567 anderen Städten versagt. Die Pflege einer Vorlagenbibliothek selbst für die 20 Städte, in denen Ihre Lieferanten zufällig ansässig sind, bedeutet 20 Vorlagen, die beim nächsten Layout-Update einer Prefeitura (Rathaus) versagen.

Der NF-e-Kontrast: Wie ein einheitlicher nationaler Standard aussieht

Brasilien hat dieses Fragmentierungsproblem bereits einmal gelöst – für Waren. Die NF-e (Nota Fiscal Eletrônica / Elektronische Warenrechnung), eingeführt 2006, wird auf Bundesstaatsebene von der SEFAZ (Secretaria da Fazenda Estadual / Staatliches Finanzministerium) nach einem einheitlichen nationalen XML-Schema verwaltet – Layoutversion 4.0. Eine NF-e aus Amazonas verwendet dieselbe Feldstruktur, dieselben XML-Tags und dieselben Validierungsregeln wie eine NF-e aus Rio Grande do Sul. Eine einzige Extraktionsvorlage funktioniert für alle 27 Bundesstaaten. Die NF-e führt ICMS, PIS, COFINS und IPI – vier Steuern, jede komplexer als ISS – und dennoch ist die Verarbeitung eines Stapels NF-e-Dokumente aus mehreren Bundesstaaten ein gelöstes technisches Problem, weil die Datenstruktur bundesweit standardisiert ist.

Betrachten Sie dann die NFS-e. Die Datenstruktur ist kommunal fragmentiert – weil die Steuer kommunal verwaltet wird – und die Steuer, die sie führt (ISS, ein Satz, eine Stadt, keine Vorsteuerkette), ist die einfachste im brasilianischen System. Das ist das Paradoxon im Kern des NFS-e-Problems: Je einfacher die Steuer, desto fragmentierter das Dokument. Die NF-e führt vier Steuern in 27 Bundesstaaten, und ein XML-Schema bewältigt alle. Die NFS-e führt eine Steuer in 5.570 Städten, und es gibt – Stand Mitte 2026 – kein einziges Layout, das alle Gemeinden abdeckt.

Wenn AP-Teams sagen: „Brasilianische Rechnungen sind komplex“, meinen sie meist die NF-e – Steuercodes, die sie noch nie gesehen haben, unbekannte Berechnungsketten, ein Freigabemodell, das eine staatliche Genehmigung vor dem Warentransport erfordert. Aber die NF-e ist auf strukturierte Weise komplex. Die NFS-e ist auf fragmentierte Weise einfach – und letzteres ist teurer in der Verarbeitung.

Das NF-e-System wurde mit dem Empfänger im Blick entwickelt: Der DANFE (Documento Auxiliar da NF-e / Hilfsdokument der NF-e), die druckbare Version, lässt die meisten XML-Daten weg, aber das vollständige XML ist stets über das SEFAZ-Portal mit dem 44-stelligen Zugangsschlüssel auf jedem DANFE abrufbar. Das NFS-e-System hingegen wurde mit dem Aussteller und der Gemeinde im Blick entwickelt. Der Empfänger erhält ein PDF – den DANFSE (Documento Auxiliar da NFS-e) – und soll sich selbst um alles Weitere kümmern. Kein einheitliches Zugangsschlüsselportal über Gemeinden hinweg. Keine Garantie, dass das gedruckte PDF alle XML-Felder enthält. Kein nationaler Standard dafür, was auf das gedruckte Dokument kommt und was in der kommunalen Datenbank bleibt.

Steuerwettbewerb im Verborgenen

Der ISS-Steuersatz von 2 % bis 5 % ist kein technisches Detail. Er ist der Motor eines kommunalen Steuerwettbewerbs, der das Problem der Datenfragmentierung noch verschärft. Da jede Stadt ihren eigenen Satz festlegt, nutzen Städte die ISS, um um Unternehmen zu konkurrieren. São Paulo erhebt einen allgemeinen Satz von 5 %. Alphaville – ein geplantes Geschäftsviertel 30 Kilometer von São Paulo entfernt – verlangt für die meisten Dienstleistungskategorien 2 %. Ein Unternehmen, das seinen Firmensitz von São Paulo nach Alphaville verlegt, senkt seine Dienstleistungssteuer um drei Fünftel, ohne seinen tatsächlichen Betrieb zu verlegen.

Dieser „guerra fiscal“ (Steuerkrieg) zwischen Gemeinden wurde vom IWF, der OECD und der brasilianischen Bundessteuerbehörde als anhaltende Belastung für die Steuereffizienz dokumentiert. Das UNDP schätzte 2023, dass die entgangenen Einnahmen aus dem kommunalen Steuerwettbewerb – bei ISS, IPTU und anderen lokalen Steuern – mehrere Prozentpunkte des BIP erreichen könnten. Die unmittelbare Folge für die Kreditorenbuchhaltung ist jedoch: Stellt Ihr IT-Dienstleister aus São Paulo eine Rechnung von einer in Alphaville registrierten Firma, beträgt der ISS-Satz auf der NFS-e 2 %, nicht 5 %. Ihr ERP erwartet 5 % basierend auf dem physischen Standort des Dienstleisters. Die Diskrepanz löst eine Abgleichsmarkierung aus. Jemand in der Kreditorenbuchhaltung muss herausfinden, warum der Satz falsch ist – oder ob er überhaupt falsch ist.

Dies ist keine hypothetische Situation. ISS-Konflikte zwischen der Gemeinde des Dienstleisters und der Gemeinde des Leistungsempfängers sind so häufig, dass einige Unternehmen die ISS doppelt zahlen – an beide Städte – anstatt den Streit zu verhandeln. Wie BPC Partners in ihrer Analyse der brasilianischen Dienstleistungssteuer dokumentierte, ist die ISS die Haupteinnahmequelle der Gemeinden und das wichtigste Instrument des zwischengemeindlichen Steuerwettbewerbs. Für ein Kreditorenbuchhaltungsteam, das einen Stapel von 50 NFS-e-Dokumenten aus 15 Städten verarbeitet, bedeutet dies, dass Sie den ISS-Satz auf der Rechnung nicht als geprüften Steuerbetrag für die ERP-Buchung behandeln können. Sie müssen ihn validieren – pro Dokument, pro Stadt, pro Dienstleistungscode.

Das „Por Dentro“-Problem: Wenn eine Steuerberechnung einfach aussieht, es aber nicht ist

Es gibt einen zweiten Grund, warum der ISS-Betrag auf einer NFS-e die automatisierte Prüfung in die Irre führen kann. Die ISS in Brasilien wird „por dentro“ (von innen nach außen) berechnet – das bedeutet, die Steuer ist im Bruttopreis enthalten und wird nicht oben draufgeschlagen. Beträgt der Nettowert der Dienstleistung R$100 und der ISS-Satz 5 %, so beträgt der Bruttobetrag nicht R$105, sondern R$100 ÷ 0,95 = R$105,26. Die ISS beträgt dann R$105,26 × 0,05 = R$5,26, nicht R$5,00.

Bei einem einzelnen Beleg beträgt der Unterschied R$0,26 – vernachlässigbar. Bei 50 Belegen pro Monat über 12 Monate, mit ISS-Sätzen zwischen 2 % und 5 % und Dienstleistungswerten zwischen R$5.000 und R$250.000, kann die kumulierte Abweichung zwischen einer naiven „Satz × Netto“-Berechnung und dem tatsächlichen „por dentro“-ISS-Betrag wesentliche Schwellenwerte überschreiten. Noch wichtiger: Wenn Ihr Extraktions-Workflow oder Ihr ERP so konfiguriert ist, dass die ISS durch Multiplikation von Satz × Basis ohne Berücksichtigung der Por-dentro-Berechnung geprüft wird, scheint jeder Beleg einen Fehler zu haben – und Ihr Team wird Stunden damit verbringen, Fehler zu untersuchen, die gar keine sind, sondern nur eine Diskrepanz zwischen der Extraktionslogik und der Steuerberechnungskonvention.

Die Por-dentro-Methode gilt in ganz Brasilien für ICMS und ISS und ist gut dokumentiert – sie wird in den PwC Worldwide Tax Summaries for Brazil und im offiziellen Text des LC 116/2003 beschrieben. Die meisten internationalen AP-Teams stoßen jedoch in ihrem Inlandsgeschäft nicht auf die „Por-dentro“-Besteuerung. Eine US-amerikanische oder europäische Rechnung schlägt Steuern oben drauf; eine brasilianische Rechnung rechnet sie ein. Ohne diesen Kontext sieht der ISS-Betrag auf einer erhaltenen NFS-e wie ein Berechnungsfehler aus. Das ist er nicht. Es ist eine andere arithmetische Konvention, die auf eine Steuer angewendet wird, deren Satz von einer Stadt festgelegt wurde, deren Layout sich von der letzten Stadt unterscheidet.

Das Steuerreform-Paradoxon 2026: Eine Heilung, die die Symptome zunächst verschlimmert

Brasiliens umfassendste Konsumsteuerreform seit Jahrzehnten soll dieses Problem lösen. Gemäß Verfassungszusatz 132/2023, geregelt durch das Ergänzungsgesetz 214/2025, werden fünf bestehende Steuern (PIS, COFINS, ICMS, ISS, IPI) schrittweise durch zwei ersetzt: CBS (Contribuição sobre Bens e Serviços / Beitrag auf Waren und Dienstleistungen) auf Bundesebene und IBS (Imposto sobre Bens e Serviços / Steuer auf Waren und Dienstleistungen) auf Staats- und Gemeindeebene. Der kombinierte CBS + IBS-Regelsatz wird auf etwa 26,5 % geschätzt. Langfristig – bis 2033 – wird dies die Konsumsteuerbemessungsgrundlage vereinheitlichen, die kommunale Zersplitterung der ISS beseitigen und vermutlich die Formate von Dienstleistungsrechnungen landesweit standardisieren.

Das Problem ist der Übergangszeitplan. So sehen die Jahre zwischen heute und 2033 für die AP-Datenverarbeitung tatsächlich aus:

Für die AP-Datenverarbeitung ist dieser Übergang ein Komplexitätsmultiplikator. Zwischen 2026 und 2033 kann eine einzelne Dienstleistungsrechnung gleichzeitig ISS-Felder, CBS-Felder und IBS-Felder enthalten – jedes mit eigenem Satz, eigener Bemessungsgrundlage und eigenem Betrag, jedes aktualisiert nach einem anderen Zeitplan, abhängig von der Gemeinde. Die Stadtverwaltung von São Paulo veröffentlichte im August 2025 das NFS-e-Layout Version 3.2 zur Einführung von IBS/CBS-Feldern; andere Städte werden zu ihren eigenen Zeitplänen folgen. Eine 2028 aus einer Stadt eingehende NFS-e kann strukturell anders aussehen als eine NFS-e, die im selben Monat aus einer anderen Stadt eingeht – nicht wegen des alten Fragmentierungsproblems, sondern wegen des neuen, das darüber gelegt wird.

Die Reform wird die Zersplitterung irgendwann beheben. Aber bis dahin wird sie sie vorübergehend verschlimmern – weil der Übergang selbst zersplittert ist. Jede Stadt aktualisiert ihr Layout nach eigenem Zeitplan. Die Einhaltung des nationalen NFS-e-Standards ist für jede Stadt freiwillig. Der Zeitplan für die Einführung der IBS-Felder ist in jeder Stadt unterschiedlich. Sieben Jahre zunehmender Komplexität vor der endgültigen Vereinfachung.

Die SNNFS-e-Teillösung: 2.000 Gemeinden dabei, 3.570 noch außen vor

Brasilien baut seit 2023 einen nationalen NFS-e-Standard auf – SNNFS-e (Sistema Nacional da NFS-e). Das System bietet ein einheitliches XML-Format, ein zentrales Rechnungsportal, ein nationales Datenrepository (ADN – Ambiente de Dados Nacional) und ein einheitliches Steuerzahlungsdokument (DNA – Documento Nacional de Arrecadação), das in allen teilnehmenden Gemeinden gültig ist. Bis Januar 2026 hatten etwa 2.000 Gemeinden das System aktiviert – rund 35 % aller brasilianischen Städte –, die schätzungsweise 80 % der Steuerzahler nach Volumen abdecken, da die frühen Anwender überproportional die größeren, volumenstärkeren Gemeinden sind.

Doch was die Einführungszahlen verschleiern: São Paulo, Brasiliens größte Stadt und wirtschaftlicher Motor des Landes, hat bestätigt, dass es nicht migrieren wird auf das nationale NFS-e-System im Jahr 2026. Die Stadt behält ihre eigene NFS-e-Plattform – Nota Fiscal Paulistana – bei, die auf einem eigenen XML-Schema, eigenem Webservice, eigenem Layout-Handbuch (Version 3.2 ab August 2025) und eigenem Aktualisierungsplan basiert. São Paulo ist nicht allein. Andere Großstädte prüfen ihre Optionen, und das Gesetz schreibt die Migration nicht vor – es fördert sie durch die Androhung des Verlusts von Bundeszuweisungen, aber große Städte mit erheblichen eigenen Einnahmequellen sind weniger anfällig für diese Drohung.

Das Ergebnis ist ein auf unbestimmte Zeit zweigleisiges System: einige Städte nach nationalem Standard, andere auf eigenen kommunalen Plattformen, alle jedoch verpflichtet, Daten an das nationale ADN-Repository zu übermitteln – was Steuertransparenz gewährleistet, aber nichts zur Standardisierung des Dokumentformats beiträgt, das in Ihrem AP-Posteingang landet. Der Empfänger erhält weiterhin unterschiedliche Layouts. Das Problem der Zersplitterung bleibt bestehen.

Und für die 106 kleinen Gemeinden, die bis Anfang 2026 noch keine Vereinbarung unterzeichnet hatten, wie die brasilianische Bundessteuerbehörde berichtete, können Dienstleister in diesen Städten NFS-e weiterhin über Altsysteme ausstellen – oder in einigen Fällen über papierbasierte Prozesse, die älter sind als die digitale Rechnungsstellung. Die Receita Federal selbst räumte am 6. Januar 2026 ein, dass viele Gemeinden die Vereinbarung in letzter Minute unterzeichnet, aber die erforderliche technische Konfiguration für den Live-Betrieb noch nicht abgeschlossen hatten.

Was das für Ihren AP-Workflow bedeutet

Verarbeitet Ihr Unternehmen monatlich 30 bis 50 Service-Rechnungen brasilianischer Anbieter aus 10 verschiedenen Städten, stehen Sie nicht vor einem Datenerfassungsproblem. Sie stehen vor einem strukturellen Problem der Datenfragmentierung, verursacht durch Brasiliens Steuerföderalismus, verstärkt durch kommunalen Steuerwettbewerb, verkompliziert durch eine nicht standardisierte Steuerberechnungskonvention – und nun beginnt ein siebenjähriger Übergang, in dem jedes Dokument zwei parallele Steuerrahmenwerke trägt.

Die Standard-AP-Reaktion auf Dokumentenvielfalt – mehr Vorlagen erstellen – versagt hier. Sie können sich nicht aus 5.570 möglichen Layouts herausschablonieren. Selbst wenn Sie nur mit 10 Städten arbeiten, kann jede dieser Städte ihr NFS-e-Layout unabhängig voneinander aktualisieren – nach Zeitplänen, die Sie nicht kontrollieren. Allein die Stadt São Paulo veröffentlichte 2025 drei Versionen des NFS-e-Handbuchs. Ein Vorlagenwartungsmodell, das für 27 landesweite NF-e-Schemata funktionierte, bricht auf kommunaler Ebene zusammen.

Die Standard-AP-Reaktion auf Steuerkomplexität – der Rechnung vertrauen – versagt ebenfalls. Der ISS-Satz auf einer NFS-e aus Alphaville mag 2 % betragen, während Ihr ERP aufgrund des physischen Standorts des Anbieters in São Paulo 5 % erwartet. Der Anbieter hat möglicherweise eine legitime Alphaville-Registrierung oder betreibt eine Steueroptimierung, die Ihr Compliance-Team prüfen muss. Der ISS-Betrag könnte falsch erscheinen, weil er por dentro berechnet wurde, während Ihre Validierungslogik eine additive Arithmetik erwartet. Der Rechnung ohne Prüfung zu vertrauen, bedeutet, potenzielle Steuerfehlangaben in Ihr ERP zu importieren – ein Compliance-Risiko, das sich mit jedem Dokument vergrößert.

Bevor Sie über Tools oder Automatisierung nachdenken, müssen Sie anerkennen, was Sie verarbeiten: ein Dokumentenformat, das rechtlich darauf ausgelegt wurde, nicht zu einem Standard zu konvergieren, ausgestellt von einem Steuersystem, das verfassungsrechtlich kommunal fragmentiert ist, während einer Reformphase, die die Fragmentierung vorübergehend verschlimmert.

Das ist die Diagnose. Die Lösung ist keine bessere Vorlage. Es ist ein Extraktionsansatz, der überhaupt nicht auf Vorlagen angewiesen ist – einer, der Felder nach ihrer Bedeutung liest (CNPJ = 14-stellige Steuer-ID mit der Bezeichnung „Prestador“) und nicht nach ihrer Position auf der Seite einer bestimmten Stadt. Semantische Extraktion – unterstützt durch visuelle Sprachmodelle, die Dokumentstrukturen so verstehen, wie ein Mensch sie liest – ist die technische Antwort auf ein jurisdiktionelles Problem, für das vorlagenbasierte Tools nie entwickelt wurden. Doch der erste Schritt ist das Verständnis der Natur des Problems. Ohne das bewerten Sie Tools nach den falschen Kriterien.

FAQ: Kommunale Variation der brasilianischen NFS-e und AP-Verarbeitung

Warum unterscheiden sich NFS-e-Formate von Stadt zu Stadt?

Weil die ISS eine kommunale und keine bundesstaatliche Steuer ist. Die brasilianische Bundesverfassung von 1988 gibt jeder der 5.570 Gemeinden das Recht, ihre eigene Dienstleistungssteuer zu erlassen und zu verwalten. Das LC 116/2003 legte nationale Richtlinien fest (Steuersatzspanne 2–5 %, 40 Dienstleistungskategorien), überließ die Umsetzung – einschließlich des elektronischen Rechnungsformats – jedoch ausdrücklich jeder Gemeinde. Im Gegensatz zur NF-e (Warenrechnung), die einem einzigen bundesweiten XML-Standard folgt, hängt die Standardisierung des NFS-e-Formats von der freiwilligen Einführung des nationalen SNNFS-e-Systems durch die Gemeinden ab. Anfang 2026 hatten etwa 2.000 Gemeinden es eingeführt; São Paulo und andere Großstädte haben sich bisher für ihre eigenen Systeme entschieden.

Wie wirkt sich die Steuerreform 2026 auf die NFS-e-Verarbeitung aus?

Die Reform führt IBS und CBS ein, um ISS und andere Verbrauchsteuern zu ersetzen, der Übergang läuft jedoch bis 2033. In dieser Zeit enthalten NFS-e-Dokumente sowohl alte ISS-Felder als auch neue IBS/CBS-Felder – was zu doppelten Steueraufschlüsselungen in einem einzigen Dokument führt. Jede Gemeinde aktualisiert ihr Format nach eigenem Zeitplan, was bedeutet, dass Sie während der Übergangsjahre NFS-e-Dokumente aus verschiedenen Städten mit unterschiedlichen Kombinationen von Steuerfeldern erhalten können. Die Reform vereinfacht das langfristige Bild (eine einheitliche Mehrwertsteuer bis 2033), erhöht aber kurzfristig die Komplexität der Verarbeitung.

Kann ich Vorlagen für die Städte meiner Lieferanten erstellen?

Ja, aber der Wartungsaufwand ist das Problem. Selbst wenn Sie NFS-e nur aus 10 Städten verarbeiten, kann jede Stadt ihr Format unabhängig aktualisieren – São Paulo veröffentlichte allein 2025 drei manuelle Versionen. Eine im Januar funktionierende Vorlage kann im August brechen, weil die Stadtverwaltung die Feldpositionen geändert hat. Auf kommunaler Ebene – 10 Städte × mehrere Formatversionen × unabhängige Aktualisierungspläne – wird die Vorlagenwartung zu einem wiederkehrenden Betriebskostenfaktor, nicht zu einer einmaligen Einrichtung. Eine Diskussion darüber, wie die vorlagenfreie semantische Extraktion dies handhabt, finden Sie in unserem Leitfaden zur NFS-e-Datenextraktion für brasilianische Betriebe.

Warum stimmt der ISS-Betrag auf meiner NFS-e nicht mit Steuersatz × Bemessungsgrundlage überein?

Die ISS in Brasilien wird „por dentro" berechnet – die Steuer ist im Bruttopreis enthalten und wird nicht aufgeschlagen. Eine Nettodienstleistung von 100 R$ bei 5 % ISS ergibt einen Bruttobetrag von 100 R$ ÷ 0,95 = 105,26 R$, nicht 105 R$. Die ISS beträgt dann 5,26 R$, nicht 5,00 R$. Wenn Ihre Prüflogik Steuersatz × Bemessungsgrundlage multipliziert, ohne diese Konvention zu berücksichtigen, weist jedes Dokument einen scheinbaren Berechnungsfehler auf. Die Formel lautet: ISS = (Bruttodienstleistungswert × Steuersatz), wobei Brutto = Nettodienstleistungswert ÷ (1 − Steuersatz).

Ist es sicher, NFS-e-ISS-Beträge ohne Prüfung direkt in mein ERP zu übernehmen?

Nicht zuverlässig, aus zwei Gründen. Erstens konkurrieren die Gemeinden in Brasilien um ISS-Sätze – ein in Alphaville (2 %) registrierter Dienstleister kann von einem Standort ausstellen, den Sie als São Paulo (5 %) kennen, was eine legitime, aber unerwartete Satzabweichung ergibt. Zweitens verschiebt das Feld „ISS Retido na Fonte" (einbehaltene Quellensteuer) auf einer NFS-e die Steuerzahlungspflicht vom Dienstleister auf Ihr Unternehmen – bei „Sim" (Ja) sind Sie für die Zahlung der ISS an die Gemeinde verantwortlich, nicht nur für die Buchung der Rechnung. Dieses Flag zu übersehen, ist ein Compliance-Risiko, nicht nur ein Datenfehler.

Warum ist die Automatisierung von NFS-e schwieriger als die von NF-e, obwohl ISS einfacher ist als ICMS?

Weil die Standardisierung der Zuständigkeit folgt. ICMS ist eine staatliche Steuer, die von 27 SEFAZ-Behörden verwaltet wird, die sich gemeinsam auf einen einzigen XML-Standard (NF-e Layout 4.0) geeinigt haben, bevor das System 2006 in Betrieb ging. ISS ist eine kommunale Steuer, die von 5.570 Präfekturen verwaltet wird, die sich nie auf ein einziges Layout geeinigt haben – und die Bundesregierung begann erst 2023, 17 Jahre nach der NF-e-Standardisierung, mit der Standardisierung durch SNNFS-e. Die Steuer ist einfacher, aber die Governance-Struktur, die das Dokument erstellt, ist fragmentierter – und die Governance bestimmt das Format.

Diagnose vor Verordnung

Das Problem der NFS-e-Verarbeitung ist nicht, dass die Dateneingabe langsam ist. Es ist, dass Ihre Eingabedokumente strukturell nicht konvergent sind – ein Merkmal des brasilianischen Fiskalföderalismus, keine vorübergehende Integrationslücke. Bis Sie die Diagnose verarbeiten, findet jede Tool-Bewertung am falschen Maßstab statt. Sie suchen nicht etwas, das das Tippen beschleunigt. Sie suchen etwas, das die Abhängigkeit von der Layout-Konsistenz beseitigt, denn in einem System mit 5.570 kommunalen Dokumentformaten existiert Layout-Konsistenz nicht.

Deshalb passt die semantische Extraktion – die Felder nach Bedeutung statt nach Position lokalisiert – auf das Problem, was template-basierte OCR nicht kann. Für eine praktische Anleitung, wie dies für einzelne NFS-e-Dokumente funktioniert, einschließlich LC-116-Dienstleistungscodes, ISS-Einbehaltungsflags und felderübergreifender Extraktion, siehe NFS-e-Daten für brasilianische Operationen extrahieren. Für das Mengenszenario – Verarbeitung von 50 oder mehr NFS-e-Dokumenten aus mehreren Städten in einem Batch – siehe Multi-Gemeinde-Batch-NFS-e-Verarbeitung.

Die strukturelle Diagnose verschreibt kein Tool. Sie definiert das Problem, das ein Tool lösen muss. Die Kluft zwischen dem Verständnis der Fragmentierung und ihrer Bewältigung mit dem richtigen Extraktionsansatz ist der Unterschied zwischen dem Reagieren auf jede Layout-Änderung einer Stadt und dem Verarbeiten jeder NFS-e, ohne zu bemerken, aus welcher Stadt sie stammt.