50 brasilianische NF-e-XMLs, eine Tabelle
Wie die Batch-Verarbeitung mehrerer Lieferanten die manuelle Steuerabstimmung überflüssig macht

Wenn 50 NF-e-XMLs eintreffen — warum Batch nicht „einzeln, 50-mal wiederholt" ist

Die brasilianische NF-e-Verarbeitung ist in einer Hinsicht ungewöhnlich: Die Quelldaten sind bereits strukturiert. Anders als bei Papierrechnungen von US-amerikanischen oder europäischen Lieferanten, die eine OCR-Digitalisierung erfordern, kommt jede NF-e als XML-Datei an, 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 Kreditorenbuchhaltung ist nicht die Genauigkeit der Datenerfassung — sondern die Datenkonsistenz über alle 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:

Fragmentierung der ICMS-Sätze. Brasiliens ICMS ist eine Mehrwertsteuer auf Bundesstaatsebene mit Sätzen, die sich nach dem Bundesstaat des Lieferanten, Ihrem Bundesstaat, der Transaktionsrichtung (innerstaatlich vs. zwischenstaatlich) und — in einigen Fällen — der NCM-Produktklassifizierung richten. 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 % sowie zwischenstaatliche Sätze von 4 %, 7 % oder 12 % enthalten, abhängig von den Ursprungs- und Zielkombinationen. Eine Spalte „ICMS-Betrag" in Ihrer Tabellenkalkulation ist bedeutungslos, es sei denn, Sie kennen auch den Satz, den anwendbaren Bundesstaat und ob die Transaktion innerstaatlich oder zwischenstaatlich ist — denn derselbe ICMS-Betrag von R$1.000 kann einen Satz von 17 % auf einer Basis von R$5.882 oder einen Satz von 12 % auf einer Basis von R$8.333 bedeuten. Das Steuermodul Ihres ERP-Systems benötigt die Unterscheidung.

Lücken in der CFOP-Konsistenz. Jede NF-e-Position trägt einen 4-stelligen CFOP-Code (Código Fiscal de Operações e Prestações), der die steuerliche Natur der Transaktion klassifiziert — 1.101 für Einkauf zur Weiterverarbeitung innerhalb desselben Bundesstaates, 2.102 für zwischenstaatlichen Einkauf zum Weiterverkauf, 3.101 für Import. Die erste Ziffer kodiert, 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. Aber wenn Lieferant C CFOP 1.101 für eine Lieferung verwendet, die in Rio de Janeiro ihren Ursprung hat — eine zwischenstaatliche Transaktion —, stimmt der CFOP nicht mit den Bundesstaatdaten in den <ide>- und <emit>-Blöcken der XML überein. Diese Diskrepanz erzeugt ein Prüfungsflag in SPED EFD (Escrituração Fiscal Digital), dem bundesweiten digitalen Buchhaltungssystem, das CFOP-Codes über die gesamte Lieferkette hinweg abgleicht. In einem Batch von 50 Rechnungen sind 3–5 Diskrepanzen üblich — und sie manuell zu finden bedeutet, den CFOP jeder XML gegen ihr Ursprungs-Ziel-Bundesstaatspaar zu prüfen.

Fehlgeschlagene Duplikaterkennung anhand der Rechnungsnummer allein. In den meisten Kreditorenbuchhaltungssystemen basiert die Duplikaterkennung auf Lieferant + Rechnungsnummer. Diese Logik versagt bei brasilianischen NF-e, da die Rechnungsnummer (número da nota) nur innerhalb einer einzelnen Serie eines Lieferanten eindeutig ist. Lieferant A kann NF-e #1523 in Serie 001 ausstellen, während Lieferant B ebenfalls NF-e #1523 in ihrer Serie 001 ausstellt. Sogar derselbe Lieferant kann identische Rechnungsnummern in verschiedenen Serien ausstellen. Der global eindeutige Identifikator 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 verschiedene Rechnungen von zwei verschiedenen Lieferanten mit derselben Rechnungsnummer als Duplikate markiert und eine wird unterdrückt — oder schlimmer, eine erneut eingereichte Rechnung mit einer korrigierten Chave de Acesso (die ein CCe-Korrekturereignis anzeigt) wird nicht als Ersatz erkannt.

Gemischte Formatquellen. In einem Batch von 50 brasilianischen Lieferantenrechnungen erhalten Sie selten 50 saubere XMLs. Einige Lieferanten – typischerweise kleinere Hersteller oder landwirtschaftliche Erzeuger – senden nur den gedruckten DANFE als PDF oder Scan. Einige senden das XML, fügen aber einen gescannten DANFE mit handschriftlichen Anmerkungen bei. 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 dies in einem Durchgang 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 existieren nicht bei einer einzelnen Rechnung. Bei 50 feuern alle vier gleichzeitig – und ihre Lösung ist das, was einen Batch-Verarbeitungsworkflow von „Einzelextraktion, 50-mal wiederholt" unterscheidet.

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

Die internen ICMS-Sätze in Brasilien haben sich 2024 erheblich verschoben, teilweise in Erwartung der Steuerreform, die ICMS zwischen 2029 und 2033 schließlich durch die neue IBS (Imposto sobre Bens e Serviços) ersetzen wird. Elf brasilianische Bundesstaaten haben ihre Standard-ICMS-Sätze im letzten Jahr geändert:

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

Zwischenstaatliche Sätze fügen eine zweite Dimension hinzu, geregelt im brasilianischen Steuerrecht:

Kombinieren Sie diese zwischenstaatlichen Steuersatzstufen mit den 11 oben genannten Änderungen auf Landesebene, und ein Batch von NF-e-XMLs von Lieferanten aus 7 Bundesstaaten kann leicht 5 verschiedene ICMS-Sätze enthalten — jeder davon muss identifiziert, nach Typ getrennt und im richtigen Steuerkonto in Ihrem ERP verbucht werden. Tools, die ICMS als einzelne Zahl extrahieren, ohne den Satz, den Ursprungsstaat und die Transaktionsart aus dem XML zu erfassen, erzeugen eine Tabelle, die mehr Abstimmungsaufwand verursacht, als sie einspart.

Hier zahlt sich die direkte Extraktion aus der Struktur der NF-e-XML — nicht das OCR des DANFE — in großem Umfang aus. Der <imposto>-Block der XML enthält separate Elementgruppen für ICMS, IPI, PIS und COFINS, jeweils mit der Besteuerungsgrundlage (vBC), dem Satz (pICMS, pIPI usw.) und dem Betrag (vICMS, vIPI usw.) auf Positionsebene. Eine Extraktion auf Basis von Spaltennamen, 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 ohne manuelle Neuberechnung auf seinen Satz und seine Basis zurückgeführt werden kann. 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 Audit-Flag, das im Batch niemand prüft

CFOP-Codes sind vierstellige Klassifikationen für steuerliche Vorgänge, die in jeder NF-e-Position enthalten sind. Es gibt über 500 CFOP-Codes, die von den brasilianischen Steuerbehörden definiert und nach der ersten Ziffer organisiert werden:

Bei einer einzelnen NF-e ist eine CFOP-Diskrepanz leicht zu erkennen: Wenn der Lieferant in Minas Gerais sitzt und Ihr Unternehmen in São Paulo, sollte jeder CFOP-Code mit 2 beginnen (zwischenstaatlicher Eingang). Wenn eine Position CFOP 1.101 – innerstaatlich – aufweist, liegt ein Datenfehler vor. Im großen Maßstab, über 50 Rechnungen von mehreren Lieferanten hinweg, wird diese Art der Validierung unerlässlich und anspruchsvoll. Ein Lieferant mag CFOP 1.101 korrekt für seine lokalen Sendungen (an seine eigenen Kunden) verwenden, sollte aber 2.101 verwenden, wenn er über Staatsgrenzen hinweg an Sie liefert. Wenn sein ERP den falschen CFOP automatisch befüllt hat, erben Sie ein Audit-Risiko, das SPED EFD erkennen wird – denn das digitale Buchhaltungssystem gleicht Käufer- und Verkäufer-CFOP-Datensätze für jede Transaktion ab. Eine Abweichung zwischen Ihrem eingehenden CFOP-Datensatz und dem entsprechenden ausgehenden Datensatz des Lieferanten erzeugt automatisch ein Audit-Flag.

Batch-CFOP-Validierung bedeutet, für jede Position im Batch drei Beziehungen zu prüfen:

1. Erste Ziffer vs. Bundesstaat-Paar. Die erste Ziffer des CFOP muss dazu passen, ob Lieferant und Käufer im selben Bundesstaat (1/5) oder in verschiedenen Bundesstaaten (2/6) ansässig sind. Extrahieren Sie den IBGE-Bundesstaatscode aus den Blöcken <emit> und <dest> – Codes 35 (SP), 33 (RJ), 31 (MG), 41 (PR) usw. – und validieren Sie das CFOP-Präfix gegen die Bestimmung gleicher/verschiedener Bundesstaat.
2. CFOP-Suffix-Konsistenz über ähnliche Vorgänge hinweg. Wenn Lieferant A CFOP 2.102 (zwischenstaatlicher Einkauf zum Weiterverkauf) und Lieferant B CFOP 2.101 (zwischenstaatlicher Einkauf zur Industrialisierung) für denselben Produkttyp verwendet, liegt mindestens einer falsch – das CFOP-Suffix muss den tatsächlichen geschäftlichen Zweck der Transaktion widerspiegeln.
3. Keine CFOP-NCM-Widersprüche. Der CFOP kodiert die Art des Vorgangs, der NCM die Produktklassifikation. Ein CFOP, der auf einen industriellen Einsatz hindeutet, gepaart mit einem NCM für ein fertiges Konsumprodukt, ist eine Warnung – das bedeutet, dass entweder der CFOP oder der NCM falsch ist, und beide beeinflussen die steuerliche Behandlung.

Die 44-stellige Chave de Acesso – Brasiliens eingebaute Deduplizierungsschlüssel, den die meisten Batch-Tools ignorieren

Die Chave de Acesso ist eine 44-stellige Zeichenfolge, die jede in Brasilien ausgestellte NF-e dauerhaft eindeutig identifiziert. Sie ist nicht nur eine Referenznummer – sie ist ein strukturierter Identifikator, der den Bundesstaat des Ausstellers (erste 2 Ziffern, gemäß IBGE-Code), das Ausstellungsjahr und den Monat (nächste 4), die CNPJ des Ausstellers (nächste 14), das Dokumentmodell (2), die Serie (3), die fortlaufende Nummer (9), den Emissionstyp (1), einen Zufallscode zur Kollisionsvermeidung (8) und eine Modulo-11-Prüfziffer (1) kodiert. Jede NF-e-XML-Datei trägt diesen Schlüssel im Attribut <infNFe Id="NFe[chave]"> und im Element <chNFe>. Es ist das, was einem global eindeutigen Rechnungsidentifikator am nächsten kommt, den jedes Steuersystem der Welt bietet.

Doch die meisten AP-Batch-Tools extrahieren 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 verschiedene 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 Duplikatprüfung auf Lieferant+Rechnungsnummer unterdrückt eine davon als Duplikat.
• Das SEFAZ-Stornierungs- und Korrektursystem basiert auf der Chave de Acesso. Wenn ein Lieferant eine Carta de Correção (CCe) ausstellt, um einen Tippfehler in der ursprünglichen NF-e zu korrigieren, bleibt die ursprüngliche Chave de Acesso gültig – aber der Ereignisverlauf, der an diese Chave gebunden ist, zeichnet die Korrektur auf. Ein Batch-Tool, das die Chave nicht nachverfolgt, kann nicht zwischen Original und korrigierter Version unterscheiden.

Extrahieren Sie in einem Batch aus 50 NF-e-XML-Dateien die Chave de Acesso als eigene Spalte. Implementieren Sie dann drei Prüfungen:

1. Eindeutigkeit innerhalb des Batches. Keine zwei Zeilen dürfen dieselbe Chave de Acesso aufweisen. Ist dies der Fall, wurde dieselbe NF-e zweimal hochgeladen – unterdrücken Sie die doppelte Zeile und kennzeichnen Sie das Vorkommen.
2. Eindeutigkeit der Rechnungsnummer innerhalb Lieferant × Serie. Gruppieren Sie nach CNPJ + Serie + Rechnungsnummer. Wenn dieselbe Kombination zweimal mit unterschiedlichen Chave de Acessos erscheint, handelt es sich wahrscheinlich um eine Korrektur – die Chave mit dem späteren Ausstellungszeitstempel hat Vorrang.
3. SEFAZ-Überprüfung für Rechnungen mit hohem Wert. Für Rechnungen über einer Wesentlichkeitsgrenze verwenden Sie die Chave de Acesso, um das öffentliche Konsultationsportal von SEFAZ oder eine Drittanbieter-API wie TF Fiscal's NF-e-Lookup abzufragen und den Autorisierungsstatus (Autorizada/Cancelada/Denegada) zu verifizieren. Eine stornierte NF-e in Ihrem Batch 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 zuverlässigste Deduplizierungsschlüssel, der in jedem E-Rechnungs-System weltweit verfügbar ist. Sie bei der Batch-Verarbeitung nicht zu nutzen, ist, als hätte man eine Sozialversicherungsnummer und würde Personen nur mit ihrem Vornamen identifizieren.

Der gemischte XML- + DANFE-Batch – wenn einige 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 die NF-e-XML routinemäßig. Sie wird von ihrem ERP erzeugt, mit ihrem ICP-Brasil-Zertifikat signiert und automatisch an SEFAZ übermittelt. Sie zusammen mit der DANFE an den Käufer zu senden, ist ein Ein-Klick-Vorgang.

Kleinere Lieferanten – landwirtschaftliche Genossenschaften, lokale Dienstleister, einige Baustofflieferanten – verfügen möglicherweise nicht über die ERP-Infrastruktur, um die XML-Übertragung zu verwalten. Sie drucken die DANFE, übergeben sie dem LKW-Fahrer, und das ist das einzige Dokument, das der Käufer sieht. Die Rechnung ist echt, sie wurde von SEFAZ autorisiert (das Autorisierungsprotokoll ist auf der DANFE aufgedruckt), aber die empfangende AP-Abteilung hat nur ein gescanntes PDF oder ein Foto des Papierdokuments.

Ein Batch-AP-Workflow, der nur XML oder nur PDF verarbeitet, zwingt das AP-Team, seinen monatlichen Rechnungseingang in zwei getrennte Verarbeitungspipelines aufzuteilen – eine für strukturierte XML, eine für gescannte DANFEs – und die Ergebnisse dann manuell in einen einzigen Hauptbuch-Eintrag zusammenzuführen. Die Fragmentierungskosten sind real: getrennte Upload-Sitzungen, getrennte Prüfungsdurchläufe und ein Abgleichsschritt am Ende, um sicherzustellen, dass alle Rechnungen desselben Lieferanten (einige XML, einige PDF) im selben AP-Batch landen.

Benutzerdefinierte Spaltenextraktion — der Ansatz von ImageToTable.ai, Daten nach Feldbedeutung statt nach Vorlagenkoordinaten zu extrahieren — 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", „Positionstext", „Menge", „Einzelpreis", „Positionssumme", „ICMS-Basis", „ICMS-Satz", „ICMS-Betrag", „IPI-Betrag", „PIS-Betrag", „COFINS-Betrag", „Gesamtwert der 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 visuell versteht, was jedes Label 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 Chave-de-Acesso-Spalte aus XML-Dateien wird direkt aus dem <chNFe>-Element extrahiert. Dieselbe Spalte aus einem DANFE-Scan wird aus dem 44-stelligen Barcode-Bereich oben rechts auf dem gedruckten Dokument gelesen. Beide Einträge landen in derselben Spalte und ermöglichen dieselbe Deduplizierungslogik wie oben beschrieben. 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 ist manuell.

Die Übergangsphase der Steuerreform 2026–2033 — Doppelte Compliance in einem einzigen Batch

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

Für AP-Teams, die brasilianische NF-e-Batches verarbeiten, ist die unmittelbare operative Herausforderung die doppelte Compliance im XML-Schema. Während der Übergangsjahre werden NF-e-XMLs sowohl alte Steuerfelder (ICMS, IPI, PIS, COFINS) als auch neue Steuerfelder (CBS, IBS) gleichzeitig enthalten — das bedeutet, dass das bereits komplexe NF-e-XML mit über 500 Feldern bald noch größer wird. Hier ist der Zeitplan, der das Design der Batch-Extraktion beeinflusst:

Die praktische Auswirkung 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 – auch zu den Testsätzen. Die Daten sind heute bereits im XML enthalten. Die Extraktion kostet nichts. Wenn die Daten in Ihrer Tabelle vorhanden sind, wenn der Übergang 2027 an Fahrt aufnimmt, enthält Ihr historischer Batch-Datenbestand bereits die Grundlage für die CBS-basierte Berichterstattung – ohne nachträgliche Re-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 XML an, das eintrifft – nicht an eine Vorlage, die jedes Mal neu erstellt werden muss, wenn SEFAZ eine neue Layout-Version veröffentlicht.

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

Nachdem die strukturellen Probleme erfasst sind, finden Sie hier eine Batch-Verarbeitungssequenz, die für die Realität der Multi-Lieferanten- und Multi-Bundesstaat-Umgebung brasilianischer Kreditorenbuchhaltung konzipiert ist:

Dieser Workflow setzt voraus, dass Ihr Batch-Extraktionstool XML- und visuelle Dokumente in derselben Upload-Sitzung verarbeiten kann — da die brasilianische AP selten nur ein Format erhält. 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 Semantik liest und sich nicht nur auf die XML-Analyse verlässt. Die semantische Extraktion liest die strukturierten Tags des NF-e-XML für Daten, die in beiden Formaten vorhanden sind (CNPJ, NF-e-Nummer, Summen, Steuerbeträge), und liest die DANFE visuell für Fälle, in denen nur das gedruckte Dokument verfügbar ist. Die Ausgabe wird in einer einzigen Tabelle mit konsistenten Spalten zusammengeführt. Wenn Ihr Tool nur XML parst oder nur OCR durchführt, benötigen Sie zwei separate Arbeitsabläufe und einen manuellen Zusammenführungsschritt.

Was passiert, wenn zwei NF-e-XMLs dieselbe Rechnungsnummer, aber unterschiedliche Chave de Acessos 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 für die Deduplizierung nach Chave de Acesso (nicht nach Rechnungsnummer) gruppieren und die Beziehung zwischen Rechnungsnummer, Serie und Chave für Prüfzwecke bewahren. Wenn dieselbe CNPJ + Serie + Rechnungsnummer mit zwei verschiedenen Chave de Acessos 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 im NF-e-XML als separate Steuergruppe (<ICMSTot> im Summenblock) mit eigener Bemessungsgrundlage, eigenem Satz und eigenem Betrag. Es sollte in separate Spalten extrahiert werden („ICMS-ST-Basis", „ICMS-ST-Betrag") — nicht mit regulärem ICMS zusammengeführt. ICMS-ST stellt eine bereits upstream von einem substituierenden Steuerpflichtigen gezahlte Steuer dar, und Ihr ERP behandelt sie für Gutschriftzwecke anders als reguläres ICMS. Wenn Sie beides in einer „ICMS"-Spalte mischen, überhöhen Sie Ihre verfügbaren Gutschriften.

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

Ja. Wenn Sie Ihre Extraktionsspalten definieren, nehmen Sie die Felder auf, die Sie auf Positionsebene benötigen (NCM, CFOP, Beschreibung, Menge, Einzelpreis, 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 — etwa NCM + Menge + CFOP ohne Einzelpreis — lassen Sie die unerwünschten Spalten aus Ihrer Definition weg. Die Extraktion erzeugt 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 abziehbar, sodass sich die Nettosteuerlast nicht ändert. Die Felder existieren jedoch im XML und sollten jetzt extrahiert werden – wenn CBS 2027 PIS/COFINS zu vollen Sätzen ersetzt, sind Ihre Batch-Extraktionsspaltendefinitionen bereits vorhanden. Der Zeitplan der Steuerreform ist im Ergänzenden Gesetz 214/2025 und in der OECD-Analyse der Reform von 2025 kodifiziert.

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 ab Ende des Steuerjahres, in dem die Transaktion stattfand, archiviert werden. Dies gilt sowohl für die ursprünglichen XMLs von Lieferanten als auch für Ihre Extraktionsaufzeichnungen. Die DANFE ist bei einer Prüfung kein rechtlich ausreichender Ersatz für das XML – wenn Sie nur die gescannte DANFE aufbewahrt und das XML verworfen haben, können Sie den vollständigen Steuerdatensatz, den SEFAZ anfordern wird, nicht rekonstruieren. Best Practice: Archivieren Sie die XMLs unverändert und führen Sie die Extraktionstabelle als separates, durchsuchbares Dokument für die interne Abstimmung.