50 brasilianische NF-e-XMLs, eine Tabelle
Wie Multi-Lieferanten-Stapelverarbeitung die manuelle Steuerabstimmung überflüssig macht

Wenn 50 NF-e-XMLs eintreffen – Warum Batch nicht „Einzelbeleg, 50-fach wiederholt“ ist

Die brasilianische NF-e-Verarbeitung ist in einer Hinsicht ungewöhnlich: Die Quelldaten sind bereits strukturiert. Anders als Papierrechnungen von US-amerikanischen oder europäischen Lieferanten, die zur Digitalisierung eine OCR benötigen, liegt jede NF-e als XML-Datei vor, die bereits gegen über 400 SEFAZ-Regeln validiert und mit einem ICP-Brasil-Zertifikat digital signiert wurde. Die Datenqualität einer einzelnen NF-e-XML ist nahezu perfekt. Das Batch-Problem in der brasilianischen AP ist nicht die Erfassungsgenauigkeit – es ist die Datenkonsistenz über Lieferanten hinweg.

Wenn Sie 50 NF-e-XMLs von 14 Lieferanten in einem einzigen Batch verarbeiten, treten vier strukturelle Probleme auf, die die Einzelrechnungsverarbeitung nie offenlegt:

ICMS-Satz-Fragmentierung. Brasiliens ICMS ist eine Mehrwertsteuer auf Bundesstaatsebene mit Sätzen, die je nach Bundesstaat des Lieferanten, Ihrem Bundesstaat, der Transaktionsrichtung (innerstaatlich vs. zwischenstaatlich) und – in einigen Fällen – der NCM-Produktklassifikation variieren. Ein Batch von 50 NF-e-XMLs von Lieferanten aus 7 Bundesstaaten kann innerstaatliche Sätze von 17 %, 18 %, 19 %, 19,5 %, 20 % und 20,5 % enthalten, plus zwischenstaatliche Sätze von 4 %, 7 % oder 12 %, je nach Herkunfts- und Zielpaarungen. Eine Spalte „ICMS-Betrag“ in Ihrer Tabelle ist bedeutungslos, wenn Sie nicht auch den Satz, den anwendbaren Bundesstaat und kennen, ob die Transaktion innerstaatlich oder zwischenstaatlich ist – denn derselbe ICMS-Betrag von R$1.000 kann einen Satz von 17 % auf eine Basis von R$5.882 oder einen Satz von 12 % auf eine Basis von R$8.333 bedeuten. Das Steuermodul Ihres ERP benötigt diese Unterscheidung.

CFOP-Konsistenzlücken. Jede NF-e-Position enthält einen 4-stelligen CFOP-Code (Código Fiscal de Operações e Prestações), der die steuerliche Art der Transaktion klassifiziert – 1.101 für Einkauf zur Industrialisierung im selben Bundesstaat, 2.102 für Einkauf zwischen Bundesstaaten zum Weiterverkauf, 3.101 für Import. Die erste Ziffer gibt an, ob die Transaktion innerstaatlich (1), zwischenstaatlich (2) oder internationaler Import (3) ist. Wenn Lieferant A CFOP 1.101 für eine Lieferung von São Paulo an Ihr Lager in São Paulo verwendet und Lieferant B CFOP 2.102 für eine zwischenstaatliche Lieferung aus Minas Gerais, ist das korrekt und beabsichtigt. Wenn Lieferant C jedoch CFOP 1.101 für eine Lieferung aus Rio de Janeiro verwendet – eine zwischenstaatliche Transaktion –, stimmt der CFOP nicht mit den Bundesstaatsdaten in den XML-Blöcken <ide> und <emit> überein. Diese Diskrepanz erzeugt ein Prüfungsflag in SPED EFD (Escrituração Fiscal Digital), dem bundesstaatlichen digitalen Buchhaltungssystem, das CFOP-Codes über die gesamte Lieferkette hinweg abgleicht. In einer Charge von 50 Rechnungen sind 3–5 Abweichungen üblich – und sie manuell zu finden bedeutet, den CFOP jedes XML gegen das Ursprungs-Ziel-Bundesstaatspaar zu prüfen.

Fehler bei Duplikaterkennung allein anhand der Rechnungsnummer. In den meisten AP-Systemen basiert die Duplikaterkennung auf Lieferant + Rechnungsnummer. Diese Logik versagt bei brasilianischen NF-e, da die Rechnungsnummer (número da nota) nur innerhalb einer Serie eines Lieferanten eindeutig ist. Lieferant A kann NF-e #1523 in Serie 001 ausstellen, während Lieferant B ebenfalls NF-e #1523 in seiner Serie 001 ausstellt. Sogar derselbe Lieferant kann identische Rechnungsnummern in verschiedenen Serien vergeben. Das global eindeutige Merkmal ist die 44-stellige chave de acesso – aber die meisten Batch-Extraktionstools extrahieren sie nicht oder extrahieren sie, ohne ihre Rolle als Deduplizierungsschlüssel zu verstehen. Ohne die chave de acesso werden zwei unterschiedliche Rechnungen von zwei verschiedenen Lieferanten mit derselben Rechnungsnummer als Duplikate markiert und eine wird unterdrückt – oder schlimmer noch, eine erneut eingereichte Rechnung mit einer korrigierten chave de acesso (was auf ein CCe-Korrekturereignis hinweist) wird nicht als Ersatz erkannt.

Gemischte Quellenformate. In einem Batch von 50 brasilianischen Lieferantenrechnungen erhält man selten 50 saubere XMLs. Einige Lieferanten – typischerweise kleinere Hersteller oder landwirtschaftliche Erzeuger – senden nur den ausgedruckten DANFE als PDF oder Scan. Einige senden das XML, hängen aber einen gescannten DANFE mit handschriftlichen Anmerkungen an. Ein mittelgroßer Industrielieferant sendet möglicherweise das XML für die Haupt-NF-e, aber den Fracht-CT-e (Conhecimento de Transporte Eletrônico) als PDF. Der Batch-Verarbeitungsworkflow muss all diese in einem Durchlauf verarbeiten – strukturierte Daten aus XML extrahieren, wo verfügbar, und das visuelle Dokument lesen, wo das XML fehlt – und alles in konsistente Spalten zusammenführen.

Diese vier Probleme treten nicht bei einer einzelnen Rechnung auf. Bei 50 treten alle vier gleichzeitig auf – und ihre Lösung unterscheidet einen Batch-Verarbeitungsworkflow von „einmaliger Extraktion, 50-mal wiederholt".

Die ICMS-Steuermatrix über 7 Bundesstaaten – Warum eine einzige „Steuer"-Spalte scheitert

Die internen ICMS-Sätze in Brasilien haben sich 2024 deutlich verändert, auch im Vorfeld der Steuerreform, die den ICMS zwischen 2029 und 2033 durch die neue IBS (Imposto sobre Bens e Serviços) ersetzen wird. Elf brasilianische Bundesstaaten haben im vergangenen Jahr ihre regulären ICMS-Sätze geändert:

Die praktische Konsequenz für die Stapelverarbeitung: Wenn Ihre Lieferantenbasis mehr als zwei brasilianische Bundesstaaten umfasst, muss Ihre Batch-Tabelle den ICMS auf der Ebene Satz × Bundesstaat × Transaktionsart erfassen – nicht in einer einzigen Spalte, die alle ICMS-Werte summiert. Eine NF-e eines Lieferanten aus Pernambuco (20,5 % innerstaatlich) und eine NF-e eines Lieferanten aus São Paulo (18 % innerstaatlich) werden in Ihrem ERP unterschiedlich behandelt, selbst wenn die ICMS-Betragsspalte denselben Wert anzeigt.

Die zwischenstaatlichen Sätze fügen eine zweite Dimension hinzu, die im brasilianischen Steuerrecht kodifiziert ist:

Kombinieren Sie diese zwischenstaatlichen Steuersätze mit den 11 Änderungen auf Bundesstaatsebene oben, und eine Charge von NF-e-XMLs von Lieferanten aus 7 Bundesstaaten kann leicht 5 verschiedene ICMS-Sätze enthalten – jeder muss identifiziert, nach Typ getrennt und im ERP dem richtigen Steuerkonto zugeordnet werden. Tools, die ICMS als einzelne Zahl extrahieren, ohne den Satz, den Ursprungsstaat und die Transaktionsart aus dem XML zu erfassen, erstellen eine Tabelle, die mehr Abstimmungsarbeit verursacht als sie einspart.

Hier zeigt sich der Vorteil der direkten Extraktion aus der NF-e-XML-Struktur (statt OCR des DANFE) bei der Massenverarbeitung. Der <imposto>-Block im XML enthält separate Elementgruppen für ICMS, IPI, PIS und COFINS, jeweils mit Bemessungsgrundlage (vBC), Steuersatz (pICMS, pIPI usw.) und Betrag (vICMS, vIPI usw.) auf Positionsebene. Eine spaltenbasierte Extraktion, die diese strukturierten Felder – „ICMS-Basis", „ICMS-Satz (%)", „ICMS-Betrag", „IPI-Betrag", „PIS-Betrag", „COFINS-Betrag" – in separate Tabellenspalten überführt, erzeugt eine Tabelle, in der jeder Steuerbetrag auf seinen Satz und seine Basis zurückgeführt werden kann – ohne manuelle Nachberechnung. Eine detaillierte Aufschlüsselung der NF-e-XML-Struktur und Feldzuordnung finden Sie in der vollständigen Anleitung zur NF-e-XML-Extraktion.

CFOP-Code-Konsistenz über Lieferanten hinweg – das Prüfkriterium, das im Batch niemand kontrolliert

CFOP-Codes sind vierstellige steuerliche Vorgangsklassifikationen, die in jeder NF-e-Position enthalten sind. Es gibt über 500 von den brasilianischen Steuerbehörden definierte CFOP-Codes, geordnet nach der ersten Ziffer:

Bei einer einzelnen NF-e fällt ein CFOP-Fehler sofort auf: Wenn der Lieferant aus Minas Gerais kommt und Ihr Unternehmen in São Paulo sitzt, muss jeder CFOP-Code mit 2 beginnen (grenzüberschreitender Eingang). Zeigt eine Position CFOP 1.101 – innerstaatlich – liegt ein Datenfehler vor. Im großen Maßstab, bei 50 Rechnungen von mehreren Lieferanten, wird diese Prüfung essenziell und anspruchsvoll. Ein Lieferant mag CFOP 1.101 korrekt für lokale Sendungen (an seine eigenen Kunden) verwenden, sollte aber bei Lieferungen an Sie über Bundesstaatsgrenzen hinweg 2.101 nutzen. Wenn sein ERP den falschen CFOP automatisch befüllt hat, übernehmen Sie ein Prüfungsrisiko, das SPED EFD aufdeckt – denn das digitale Buchhaltungssystem gleicht für jede Transaktion die CFOP-Einträge von Käufer- und Verkäuferseite ab. Eine Abweichung zwischen Ihrem eingehenden CFOP-Eintrag und dem entsprechenden ausgehenden Eintrag des Lieferanten löst automatisch eine Prüfungsmarkierung aus.

Die Batch-CFOP-Validierung prüft für jede Position im Batch drei Beziehungen:

1. Erstes Ziffer vs. Bundesstaat-Paar. Die erste Ziffer des CFOP muss übereinstimmen, ob Lieferant und Käufer im selben Bundesstaat (1/5) oder in verschiedenen Bundesstaaten (2/6) sind. Extrahieren Sie den IBGE-Bundesstaatcode aus den Blöcken <emit> und <dest> — Codes 35 (SP), 33 (RJ), 31 (MG), 41 (PR) usw. — und validieren Sie das CFOP-Präfix anhand der Bestimmung „gleicher/verschiedener Bundesstaat".
2. CFOP-Suffix-Konsistenz bei ähnlichen Vorgängen. Wenn Lieferant A den CFOP 2.102 (zwischenstaatlicher Kauf zum Weiterverkauf) und Lieferant B den CFOP 2.101 (zwischenstaatlicher Kauf zur Industrialisierung) für denselben Produkttyp verwendet, ist mindestens einer davon falsch — das CFOP-Suffix muss den tatsächlichen Geschäftszweck der Transaktion widerspiegeln.
3. Kein CFOP-NCM-Widerspruch. Der CFOP kodiert die Art des Vorgangs, das NCM die Produktklassifikation. Ein CFOP, der auf einen industriellen Einsatzstoff hindeutet, gepaart mit einem NCM für ein fertiges Konsumprodukt, ist ein Warnsignal — das bedeutet, dass entweder der CFOP oder das NCM falsch ist, und beide beeinflussen die steuerliche Behandlung.

Der 44-stellige Chave de Acesso — Brasiliens eingebauter Deduplizierungsschlüssel, den die meisten Batch-Tools ignorieren

Die chave de acesso ist eine 44-stellige Zeichenkette, die jede in Brasilien ausgestellte NF-e eindeutig und dauerhaft identifiziert. Sie ist nicht nur eine Referenznummer – sie ist eine strukturierte Kennung, die den Bundesstaat des Ausstellers (erste 2 Ziffern, nach IBGE-Code), das Ausstellungsjahr und den Monat (nächste 4), die CNPJ des Ausstellers (nächste 14), das Dokumentenmodell (2), die Serie (3), die fortlaufende Nummer (9), die Emissionsart (1), einen zufälligen Kollisionscode (8) und eine Modulo-11-Prüfziffer (1) kodiert. Jede NF-e-XML trägt diesen Schlüssel im Attribut <infNFe Id="NFe[chave]"> und im Element <chNFe>. Er ist das, was einem global eindeutigen Rechnungsbezeichner in jedem Steuersystem der Welt am nächsten kommt.

Doch die meisten Batch-Tools extrahieren lediglich eine Spalte „Rechnungsnummer“ und belassen es dabei. In Brasilien reicht diese Spalte nicht aus:

• Lieferant A kann NF-e #1523 in Serie 001 und NF-e #1523 in Serie 002 ausstellen – gleiche Rechnungsnummer, zwei völlig unterschiedliche Steuerdokumente, nur unterscheidbar durch Serie und chave de acesso.
• Lieferant B kann NF-e #1523 in seiner eigenen Serie 001 ausstellen – gleiche Rechnungsnummer wie Lieferant A, anderer Lieferant, andere Transaktion – und eine einfache Prüfung auf doppelte Lieferanten+Rechnungsnummern unterdrückt eine davon fälschlich als Duplikat.
• Das SEFAZ-Stornierungs- und Korrektursystem basiert auf der chave de acesso. Wenn ein Lieferant eine Carta de Correção (CCe) zur Korrektur eines Tippfehlers in der ursprünglichen NF-e ausstellt, bleibt die ursprüngliche chave de acesso gültig – aber der an diese chave angehängte Ereignisverlauf zeichnet die Korrektur auf. Ein Batch-Tool, das die chave nicht verfolgt, kann nicht zwischen der Original- und der korrigierten Version unterscheiden.

Extrahieren Sie in einem Batch von 50 NF-e-XMLs die chave de acesso als eigene Spalte. Führen Sie dann drei Prüfungen durch:

1. Eindeutigkeit innerhalb des Stapels. Keine zwei Zeilen dürfen dieselbe chave de acesso haben. Ist dies der Fall, wurde dieselbe NF-e zweimal hochgeladen – die doppelte Zeile unterdrücken und das Vorkommen kennzeichnen.
2. Eindeutigkeit der Rechnungsnummer innerhalb von Lieferant × Serie. Nach CNPJ + Serie + Rechnungsnummer gruppieren. Tritt dieselbe Kombination zweimal mit unterschiedlichen chave de acessos auf, handelt es sich wahrscheinlich um eine Korrektur – die chave mit dem späteren Ausstellungszeitstempel hat Vorrang.
3. SEFAZ-Prüfung für Rechnungen mit hohem Wert. Bei Rechnungen über einer Wesentlichkeitsgrenze die chave de acesso verwenden, um über das öffentliche Konsultationsportal der SEFAZ oder eine Drittanbieter-API wie TF Fiscal's NF-e-Abfrage den Autorisierungsstatus (Autorizada/Cancelada/Denegada) zu prüfen. Eine stornierte NF-e im Stapel bedeutet, dass der Lieferant sie neu ausgestellt hat – und Sie benötigen die Ersatz-chave.

Die 44 Ziffern wirken auf nicht-brasilianische AP-Mitarbeiter einschüchternd. Aber sie sind der mit Abstand zuverlässigste Deduplizierungsschlüssel, der in jedem E-Rechnungs-System weltweit verfügbar ist. Sie in der Stapelverarbeitung nicht zu nutzen, ist, als hätte man eine Sozialversicherungsnummer und würde Personen nur mit ihrem Vornamen identifizieren.

Der gemischte XML- + DANFE-Stapel – Wenn manche Lieferanten die vollständige Rechnung senden und andere nur Papier

Größere brasilianische Lieferanten – insbesondere Industriehersteller und Distributoren mit SAP, TOTVS Protheus oder Oracle – senden das NF-e-XML routinemäßig mit. Es wird von ihrem ERP erstellt, mit ihrem ICP-Brasil-Zertifikat signiert und automatisch an die SEFAZ übermittelt. Es zusammen mit dem DANFE an den Käufer zu senden, ist ein Klick.

Kleinere Lieferanten – landwirtschaftliche Genossenschaften, lokale Dienstleister, manche Baustofflieferanten – verfügen oft nicht über die ERP-Infrastruktur für die XML-Übertragung. Sie drucken die DANFE aus, übergeben sie dem LKW-Fahrer, und das ist das einzige Dokument, das der Käufer sieht. Die Rechnung ist echt und von der SEFAZ autorisiert (das Autorisierungsprotokoll ist auf der DANFE aufgedruckt), aber die empfangende AP-Abteilung hat nur einen eingescannten PDF- oder ein Foto des Papierdokuments.

Ein Batch-AP-Workflow, der nur XML oder nur PDF verarbeitet, zwingt das AP-Team, den monatlichen Rechnungseingang in zwei separate Bearbeitungspipelines aufzuteilen – eine für strukturiertes XML, eine für gescannte DANFEs – und die Ergebnisse dann manuell in einen Hauptbuchungseintrag zusammenzuführen. Die Fragmentierungskosten sind real: separate Upload-Sitzungen, separate Prüfdurchläufe und ein Abgleichsschritt am Ende, um sicherzustellen, dass alle Rechnungen desselben Lieferanten (teils XML, teils PDF) im selben AP-Batch landen.

Benutzerdefinierte Spaltenextraktion – ImageToTable.ai extrahiert Daten nach Feldbedeutung statt nach Koordinatenvorlage – und verarbeitet beide Quellen in einem Batch-Upload. Sie definieren Ihre Spaltennamen einmal: „Chave de Acesso“, „Lieferanten-CNPJ“, „Lieferantenname“, „NF-e-Nummer“, „Serie“, „Ausstellungsdatum“, „CFOP“, „NCM“, „Positionenbeschreibung“, „Menge“, „Stückpreis“, „Positionssumme“, „ICMS-Basis“, „ICMS-Satz“, „ICMS-Betrag“, „IPI-Betrag“, „PIS-Betrag“, „COFINS-Betrag“, „Gesamtwert NF-e“. Die KI liest strukturierte Daten aus XML-Dateien, in denen die Felder maschinenlesbar sind, und extrahiert dieselben Felder aus gescannten DANFE-PDFs, indem sie erkennt, was jedes Label visuell bedeutet – unabhängig vom Layout. Beide Quellen werden in derselben Tabelle mit denselben Spalten in einem Batch zusammengeführt.

Der praktische Vorteil liegt nicht nur in der Geschwindigkeit – sondern in der Konsistenz. Die Spalte „Chave de Acesso“ aus XML-Dateien wird direkt aus dem Element <chNFe> extrahiert. Dieselbe Spalte aus einem DANFE-Scan wird aus dem 44-stelligen Barcode-Bereich oben rechts im Ausdruck gelesen. Beide Einträge landen in derselben Spalte und ermöglichen so die oben beschriebene Deduplizierungslogik. Ohne einen einheitlichen Batch-Workflow leben die Chave de Acesso aus dem XML-Batch und die Chave de Acesso aus dem gescannten DANFE-Batch in getrennten Tabellen – und die Duplikaterkennung zwischen ihnen erfolgt manuell.

Die Steuerreform 2026–2033 – Duale Compliance in einem einzigen Batch

Die brasilianische Verbrauchsteuerreform – verabschiedet durch Verfassungszusatz 132 vom Dezember 2023 und geregelt durch Ergänzungsgesetz 214 vom Januar 2025 – restrukturiert das gesamte indirekte Steuersystem des Landes über einen Zeitraum von acht Jahren. Bis 2033 werden fünf bestehende Steuern (PIS, COFINS, IPI, ICMS und ISS) durch ein duales Mehrwertsteuersystem ersetzt: die bundesstaatliche CBS (Contribuição sobre Bens e Serviços) und die bundesstaatlich-kommunale IBS (Imposto sobre Bens e Serviços), plus eine selektive Verbrauchsteuer (IS) auf gesundheits- und umweltschädliche Güter. Der Übergang begann am 1. Januar 2026.

Für AP-Teams, die brasilianische NF-e-Batches verarbeiten, liegt die unmittelbare betriebliche Herausforderung in der dualen Compliance im XML-Schema. Während der Übergangsjahre werden NF-e-XMLs sowohl die alten Steuerfelder (ICMS, IPI, PIS, COFINS) als auch die neuen Steuerfelder (CBS, IBS) gleichzeitig enthalten – das bedeutet, dass das bereits komplexe NF-e-XML mit über 500 Feldern noch umfangreicher wird. Hier ist der Zeitplan, der das Batch-Extraktionsdesign beeinflusst:

Die praktische Konsequenz für die Batch-Extraktion im Jahr 2026: Wenn Sie jetzt Spaltendefinitionen erstellen, nehmen Sie CBS- und IBS-Spalten neben Ihren ICMS- und PIS/COFINS-Spalten auf – selbst mit Teststeuersätzen. Die Daten sind heute im XML enthalten. Die Extraktion kostet nichts. Wenn der Übergang 2027 an Fahrt gewinnt, enthalten Ihre historischen Batch-Daten bereits die Grundlage für die CBS-basierte Berichterstattung – ohne nachträgliche erneute Extraktion archivierter NF-e-XMLs aus dem Jahr 2026.

Ein Batch-Extraktionssystem, das Feldnamen semantisch liest – „ICMS-Basis", „ICMS-Satz", „CBS-Basis", „CBS-Satz" usw. – bewältigt diesen Übergang ohne Neu konfiguration pro Lieferant. Die Spaltendefinitionen bleiben gleich; die KI findet die Steuerfelder, die in der aktuellen XML-Schemaversion vorhanden sind. Wenn die Nota Técnica-Updates in den nächsten sieben Jahren neue Felder hinzufügen und alte entfernen, passt sich die Extraktionslogik an das eingehende XML an – nicht an eine Vorlage, die jedes Mal neu erstellt werden muss, wenn SEFAZ eine neue Layoutversion veröffentlicht.

Ein Batch-NF-e-Verarbeitungsworkflow, der den Monatsabschluss übersteht

Nachdem die strukturellen Probleme aufgezeigt wurden, folgt hier eine Batch-Verarbeitungssequenz, die für die Realität der Multi-Lieferanten-, Multi-State-Brazilian-AP ausgelegt ist:

Dieser Workflow setzt voraus, dass Ihr Batch-Extraktionstool XML- und visuelle Dokumente in derselben Upload-Sitzung verarbeiten kann – denn die brasilianische AP erhält selten nur ein Format. Wenn Ihr aktueller Prozess einen separaten Workflow für die XML-Analyse und einen separaten Workflow für die PDF-OCR erfordert, verdoppelt der Zusammenführungsschritt in Schritt 5 Ihre Verarbeitungszeit und birgt das Risiko inkonsistenter Spaltenzuordnungen zwischen den beiden Pipelines.

Häufig gestellte Fragen

Kann die Batch-Verarbeitung NF-e-XMLs und DANFE-PDFs im selben Upload verarbeiten?

Ja — wenn das Extraktionstool Semantiken liest, statt sich nur auf XML-Parsing zu verlassen. Semantische Extraktion liest die strukturierten Tags der NF-e-XML für Daten, die in beiden Formaten existieren (CNPJ, NF-e-Nummer, Summen, Steuerbeträge) und liest visuell das DANFE, wenn nur das gedruckte Dokument verfügbar ist. Die Ausgabe wird in einer Tabelle mit einheitlichen Spalten zusammengeführt. Wenn Ihr Tool nur XML parst oder nur OCR durchführt, benötigen Sie zwei separate Workflows und einen manuellen Zusammenführungsschritt.

Was passiert, wenn zwei NF-e-XMLs dieselbe Rechnungsnummer, aber unterschiedliche Chave de Acesso haben?

Dies ist ein legitimes Szenario — typischerweise eine korrigierte NF-e, die nach einem CCe-Ereignis neu ausgestellt wurde, oder zwei NF-e-Dokumente aus verschiedenen Serien mit derselben fortlaufenden Nummer. Die Chave de Acesso ist in beiden Fällen eindeutig. Ihre Batch-Validierung sollte zur Deduplizierung nach Chave de Acesso (nicht Rechnungsnummer) gruppieren und die Beziehung zwischen Rechnungsnummer, Serie und Chave für Prüfzwecke erhalten. Wenn dieselbe CNPJ + Serie + Rechnungsnummer mit zwei verschiedenen Chave de Acesso erscheint, prüfen Sie die Ausstellungszeitstempel — die spätere Chave ersetzt die frühere.

Wie gehe ich mit ICMS-ST (Steuersubstitution) in einem Batch um?

ICMS-ST erscheint in der NF-e-XML als separate Steuergruppe (<ICMSTot> im Summenblock) mit eigener Bemessungsgrundlage, Steuersatz und Betrag. Es sollte in separate Spalten extrahiert werden („ICMS-ST-Bemessungsgrundlage", „ICMS-ST-Betrag") — nicht mit regulärem ICMS vermischt. ICMS-ST stellt eine bereits vom Steuersubstitut vorab gezahlte Steuer dar, und Ihr ERP behandelt sie für Gutschriftszwecke anders als reguläres ICMS. Eine Vermischung in einer einzigen „ICMS"-Spalte würde Ihre verfügbaren Gutschriften überhöhen.

Kann ich nur bestimmte Positionen aus einer NF-e extrahieren, anstatt aller Positionen?

Ja. Wenn Sie Ihre Extraktionsspalten definieren, geben Sie die Felder an, die Sie auf Positionsebene benötigen (NCM, CFOP, Beschreibung, Menge, Stückpreis, Positionssumme und Steuern pro Position). Die KI extrahiert jede Position aus jeder NF-e, die Ihrer Spaltendefinition entspricht. Wenn Sie nur bestimmte Spalten benötigen – z. B. NCM + Menge + CFOP, ohne Stückpreis – lassen Sie die nicht benötigten Spalten einfach aus Ihrer Definition weg. Die Extraktion liefert nur das, was Sie anfordern.

Ändert die Steuerreform 2026, was ich aus NF-e-XMLs extrahieren muss?

Im Jahr 2026 enthält das NF-e-XML-Schema nun CBS- und IBS-Felder mit Testsätzen (0,9 % bzw. 0,1 %) neben den bestehenden ICMS-, PIS- und COFINS-Feldern. Diese Testsätze sind vollständig von PIS/COFINS abzugsfähig, sodass sich die Nettosteuerlast nicht ändert. Die Felder sind jedoch im XML vorhanden und sollten jetzt extrahiert werden – wenn CBS 2027 PIS/COFINS zu vollen Sätzen ersetzt, sind Ihre Batch-Extraktionsspaltendefinitionen bereits eingerichtet. Der Zeitplan der Steuerreform ist im Ergänzungsgesetz 214/2025 und der OECD-Analyse der Reform von 2025 festgelegt.

Wie lange muss ich NF-e-XMLs und Extraktionsaufzeichnungen aufbewahren?

Das brasilianische Steuerrecht verlangt, dass NF-e-XMLs und zugehörige Steuerdokumente mindestens fünf Jahre nach Ende des Geschäftsjahres, in dem die Transaktion stattfand, archiviert werden. Dies gilt sowohl für die von Lieferanten erhaltenen Original-XMLs als auch für Ihre Extraktionsaufzeichnungen. Der DANFE ist bei einer Prüfung kein rechtlich ausreichender Ersatz für das XML – wenn Sie nur den gescannten DANFE aufbewahrt und das XML verworfen haben, können Sie den vollständigen Steuerdatensatz, den SEFAZ anfordern wird, nicht rekonstruieren. Bewährte Vorgehensweise: Archivieren Sie die XMLs unverändert und führen Sie die Extraktionstabelle als separates, durchsuchbares Dokument für den internen Abgleich.