Kann KI Daten aus NF-e-XML extrahieren? Ja — intelligentes Parsing, keine OCR

Ja. KI kann Daten aus brasilianischen NF-e-XML-Dateien (Nota Fiscal Eletrônica) extrahieren — Lieferanten-CNPJ, Produkt-NCM-Codes, ICMS/IPI-Steuerwerte und Positionsdetails. Aber NF-e ist ein Sonderfall: Die Daten sind im XML bereits strukturiert. Extraktion bedeutet hier, das XML-Schema intelligent zu parsen und Felder lesbaren Tabellenspalten zuzuordnen — nicht OCR. Jede Lieferanten-NF-e folgt demselben staatlichen Schema, enthält aber unterschiedliche optionale Felder, Steuerkonfigurationen und versionsspezifische Elemente, die die manuelle Konsolidierung über Dutzende Lieferanten hinweg zu einem wiederkehrenden Kopfschmerz machen.

So funktioniert die NF-e-XML-Extraktion – und warum Sie sie trotzdem brauchen

Wenn NF-e-Daten bereits als XML vorliegen, warum nicht einfach ein XSLT-Stylesheet schreiben und fertig? Weil Sie nie nur ein einziges NF-e-Format erhalten.

Das brasilianische NF-e-System – geschaffen durch Ajuste SINIEF 07/05 und heute für praktisch alle B2B-Transaktionen verpflichtend – definiert ein staatliches XML-Schema (aktuell Version 4.0). Jede elektronische Rechnung hat die gleiche Grundstruktur: Aussteller-CNPJ und Firmenname, Empfängerdaten, Positionen mit NCM-Klassifikation und CFOP-Codes sowie vier separate Steuerblöcke für ICMS (Mehrwertsteuer), IPI (Bundesverbrauchsteuer), PIS und COFINS.

Das Problem zeigt sich, wenn Sie in einem Monat XML von 30 Lieferanten erhalten. Jeder verwendet ein anderes ERP – TOTVS, Sankhya, Omie, SAP Business One – und jeder befüllt andere optionale Felder. Einer enthält Frachtdetails, ein anderer lässt sie weg. Einer nutzt NF-e 4.0 mit erweiterter Summierung, ein anderer arbeitet noch mit 3.10.

Traditionelle XML-Parsing-Ansätze – XSLT, Python-Skripte, Power-Query-Importe – scheitern, wenn Felder fehlen oder sich Namespaces verschieben. KI liest das XML semantisch und identifiziert Felder nach ihrer Bedeutung, nicht nach ihrer Position im Baum. Dies ist Custom Column Extraction auf strukturierte Daten angewendet – Sie definieren die gewünschten Ausgabespalten („Lieferanten-CNPJ“, „NCM-Code“, „ICMS-Wert“), und die KI findet passende Daten unabhängig von optionalen Feldern oder Versionsunterschieden.

Was KI bei NF-e-XML richtig macht

Die strukturierte Natur von NF-e-XML führt zu einer höheren Extraktionsgenauigkeit als bei bildbasierten Dokumenten – oft über 99 % bei standardisierten Kernfeldern. Die Formatvorgaben kommen der KI auf drei Arten zugute.

CNPJ- und CPF-Steuer-IDs

Jedes NF-e-XML enthält den CNPJ des Ausstellers (Cadastro Nacional da Pessoa Jurídica – die 14-stellige Bundessteuernummer) an einer festen Position im <emit>-Block. Das starre Format XX.XXX.XXX/XXXX-XX und der vorhersagbare XML-Pfad machen die Extraktion praktisch fehlerfrei. Die CNPJ-Extraktionsgenauigkeit bei NF-e 3.10- und 4.0-XML übersteigt 99,5 % – das strukturierte Format eliminiert die Zeichenerkennungs-Unschärfe, die gescannte Papierrechnungen plagt.

NCM-Codes

NCM-Codes (Nomenclatura Comum do Mercosul) – die 8-stellige Produktklassifikation der Mercosur-Länder – stehen in einem eigenen <NCM>-Tag innerhalb jeder Position. Für Unternehmen, die SPED Fiscal (Sistema Público de Escrituração Digital – Brasiliens digitales Steuerbuchhaltungssystem) einreichen, ist die korrekte NCM-Extraktion aus eingehenden Kauf-NF-e entscheidend: Falsche Codes lösen Prüfungsflags aus. KI erreicht 98–99 % Genauigkeit, da der Code einem starren 8-stelligen Zahlenmuster in einem dedizierten XML-Tag folgt.

Steuerwerte (ICMS, IPI, PIS, COFINS)

Eine einzelne NF-e kann vier separate Steuern enthalten, jede mit eigener Berechnungsgrundlage, eigenem Satz und Endwert – ungewöhnlich steuerlastig im Vergleich zu Rechnungen aus anderen Ländern. Die Steuerabschnitte sind sauber getrennte XML-Blöcke, und KI ordnet jeden mit hoher Zuverlässigkeit der entsprechenden Ausgabespalte zu. Bei NF-e, in denen alle Steuerabschnitte befüllt sind, erreicht die ICMS-Wertgenauigkeit 99 %+ – höher als bei manueller Dateneingabe, die Übertragungsfehler verursacht.

Wo KI bei NF-e-XML an Grenzen stößt

Die Struktur, die die NF-e-Extraktion genau macht, erzeugt auch Randfälle. Drei Szenarien verringern die Zuverlässigkeit.

Schemaunterschiede zwischen Versionen

NF-e hat mehrere Versionen durchlaufen – 1.0, 2.0, 3.10 und 4.0 (aktuell). Jede Überarbeitung hat XML-Tags hinzugefügt, entfernt oder umbenannt. Wenn KI auf eine ältere NF-e 2.0-XML stößt, in der ein Feld schlicht nicht existiert, lässt sie die Zelle korrekt leer – aber diese leere Zelle kann nachgelagerte Tabellenkalkulationsformeln stören, die einen Wert erwarten. Die Lösung: Ältere XML-Versionen separat verarbeiten und eine Post-Extraktionsvalidierung anwenden, um fehlende Felder zu kennzeichnen.

Optionale Felder und reine Dienstleistungs-NF-e

Viele NF-e-Felder sind optional. Dienstleistungsrechnungen lassen produktbezogene Felder komplett weg – keine NCM-Codes, kein IPI. Wenn KI einen gemischten Stapel verarbeitet, lässt sie nicht anwendbare Spalten korrekt leer. Wenn Ihre Tabelle jedoch in jeder Zeile einen NCM-Code erwartet, wirken Dienstleistungszeilen unvollständig. Definieren Sie Spalten, die beide Szenarien abdecken – „NCM-Code (nur Produkt-NF-e)“ – um Erwartungen zu setzen.

XML + DANFE – gemischte Workflows

Der DANFE (Documento Auxiliar da NF-e) ist das gedruckte PDF-Begleitdokument. Viele kleinere brasilianische Lieferanten versenden nur den DANFE, nicht die zugrunde liegende XML. DANFE-PDFs erfordern eine bildbasierte KI-Extraktion mit 90–95 % Genauigkeit – niedriger als die 99 %+ bei direkter XML-Analyse. Best Practice: Fordern Sie von jedem Lieferanten die XML an und behandeln Sie DANFE-Dateien als separates Batch mit geringerer Vertrauenswürdigkeit.

So erzielen Sie die besten Ergebnisse bei der NF-e-XML-Extraktion

Fünf Schritte, die bei brasilianischen elektronischen Rechnungen einen messbaren Unterschied machen.

Semantische Spaltennamen statt XML-Pfade definieren. Verwenden Sie „Lieferanten-CNPJ“, „NCM-Code“, „ICMS-Wert“ – nicht XPath-Strings wie /nfeProc/NFe/infNFe/emit/CNPJ. Die KI löst diese semantisch auf und findet den CNPJ, egal ob an Position NF-e 4.0 oder einer leicht abweichenden NF-e-3.10-Stelle. Dies ist Custom Column Extraction angewendet auf strukturierte Daten.

XML anfordern, nicht DANFE-PDFs. Diese einzelne Gewohnheitsänderung bringt eine Genauigkeitssteigerung von 5–10 Prozentpunkten. Brasilianisches Recht verpflichtet Lieferanten zur Bereitstellung der XML – senden Sie neuen Lieferanten: „Por favor, enviar o arquivo XML da NF-e juntamente com o DANFE.“

NF-e bei Batch-Verarbeitung nach Version gruppieren. Trennen Sie NF-e-4.0-XML von älteren 3.10- oder 2.0-Dateien. Das aktuelle Schema befüllt mehr Felder – bei gemeinsamer Verarbeitung haben ältere Versionen mehr leere Zellen, was wie Extraktionsfehler aussehen kann. Die Gruppierung nach Version ermöglicht eine Überprüfung jedes Batches mit den richtigen Erwartungen.

Berechnete Spalten für die Steuerprüfung nutzen. Brasilianische Steuern schaffen integrierte Prüfmechanismen. Definieren Sie eine berechnete Spalte, die ICMS-Wert ≈ ICMS-Basis × ICMS-Satz verifiziert – die KI kennzeichnet Abweichungen während der Extraktion, statt dass Sie sie später im Buchhaltungssystem entdecken.

Den Summenblock stichprobenartig prüfen. Der Abschnitt <total> enthält die endgültigen Summenwerte. Überprüfen Sie nach der Extraktion, ob die Positionssummen mit der deklarierten Gesamtsumme der XML übereinstimmen – eine Abweichung zeigt einen Fehler schneller an als die Prüfung jedes einzelnen Felds. Bei sauberer XML bestehen weniger als 2 % der NF-e diese Prüfung nicht.

Praxisbeispiele

Konsolidierung mehrerer NF-e-Lieferanten für SPED Fiscal

Ein mittelständischer Hersteller in São Paulo erhält monatlich 30–50 NF-e-XML-Dateien von Rohstofflieferanten – Stahl von Gerdau, Elektrokomponenten von WEG, Verpackungen von lokalen Anbietern. Jede NF-e enthält unterschiedliche ICMS-Sätze (7 % bis 18 %, je nach Ursprungsstaat) und eine unterschiedliche Feldvollständigkeit. Die manuelle Erfassung kostete einen AP-Sachbearbeiter zwei volle Arbeitstage pro Monat.

Mit KI-Extraktion erzeugt das Hochladen aller XML-Dateien in einen Batch eine konsolidierte Tabelle mit den Spalten: Lieferanten-CNPJ, NF-e-Nummer, Ausstellungsdatum, NCM-Code, Produktbeschreibung, Menge, Einzelpreis, ICMS-Basis, ICMS-Wert, NF-e-Gesamtbetrag – bereit für den Import in das TOTVS-ERP des Unternehmens. Zwei Tage Arbeit werden zu drei Minuten, und die ICMS-Werte werden gegen den XML-Summenblock kreuzvalidiert, wodurch Fehler erkannt werden, bevor sie SPED erreichen. Für den feldbezogenen Workflow und die drei im Detail verglichenen Methoden siehe unseren Leitfaden zur NF-e-XML-zu-Excel-Extraktion.

NCM-Extraktion für Einfuhrabgaben

Ein Logistikunternehmen, das Importe abwickelt, benötigt NCM-Codes und Produktwerte aus Lieferanten-NF-e, um Einfuhrabgaben zu berechnen. Jede NF-e enthält 5–20 Positionen mit unterschiedlichen Klassifizierungen. Die KI extrahiert in Sekunden eine Zeile pro Position – formatiert für die Deklarationsvorlage des Zollagenten.

FAQ

Kann die KI zwischen ICMS, IPI, PIS und COFINS auf derselben NF-e unterscheiden?

Ja. Jede Steuer hat ihren eigenen XML-Block mit eindeutigen Kindelementen – ICMS hat <orig> und <CST>, IPI hat <clEnq>. Die KI ordnet sie sauber separaten Ausgabespalten zu, da die XML-Struktur sie eindeutig unterscheidet. Das ist für die KI einfacher als bei der bildbasierten Extraktion, wo Steuern als undifferenzierte Zahlenzeilen erscheinen.

Funktioniert die KI mit NF-e aus verschiedenen brasilianischen Bundesstaaten mit unterschiedlichen ICMS-Sätzen?

Ja. Der ICMS-Satz (alíquota) ist im <ICMS>-Block jeder NF-e angegeben. Ob eine NF-e die 18 % aus São Paulo oder die 19 % aus Rio de Janeiro enthält, die KI liest den Satz direkt aus dem XML. Auch länderübergreifende ICMS-ST-Szenarien (Substituição Tributária) werden erfasst, da das XML ICMS-ST-Beträge explizit kennzeichnet.

Kann KI Daten aus NF-e-XML auf Portugiesisch in eine Tabellenkalkulation mit englischen Spalten extrahieren?

Ja. Definieren Sie Ausgabespalten auf Englisch – „Supplier CNPJ", „Invoice Total" – und die KI ordnet portugiesische XML-Felder englischen Kopfzeilen zu. XML-Tags sind sprachunabhängig, und die semantische Zuordnung funktioniert sprachübergreifend. Weitere Informationen finden Sie unter wie KI mehrsprachige Extraktion handhabt.

Was ist mit NFS-e (kommunale Dienstleistungsrechnungen)?

NFS-e (Nota Fiscal de Serviços Eletrônica) ist ein separates Dokument auf kommunaler Ebene – jede Stadt (Prefeitura) hat ihr eigenes Schema. Im Gegensatz zur bundesweiten Standardisierung von NF-e variieren die NFS-e-Formate je nach Gemeinde. Die KI kann auch aus NFS-e-XML extrahieren, aber die schemabedingten Unterschiede pro Stadt erfordern mehr Überprüfung. NF-e (bundesweit, für Waren) ist die zuverlässige Variante; NFS-e (kommunal, für Dienstleistungen) bringt mehr Variablen mit sich. Für den Dienstleistungsbereich finden Sie unseren Leitfaden zur NFS-e-Extraktion.

Ist die KI-Extraktion aus NF-e-XML konform mit den brasilianischen Steueraufbewahrungspflichten?

Die Extraktion ist ein Datentransformationsschritt – sie verändert das ursprüngliche XML nicht, das weiterhin Ihr rechtliches Steuerdokument bleibt. Die brasilianischen Steuerbehörden verlangen die Aufbewahrung der digital signierten NF-e-XML-Dateien für 5 Jahre (Prazo Decadencial, CTN Art. 173). Die KI-Extraktion erstellt eine abgeleitete Tabellenkalkulation; das ursprüngliche, digital signierte XML bleibt unverändert.

Wie groß ist der Genauigkeitsunterschied zwischen NF-e-XML- und DANFE-PDF-Extraktion?

Das ist eine völlig andere Kategorie. Die NF-e-XML-Extraktion erreicht bei Kernfeldern über 99 %, da die Daten in eindeutigen XML-Tags vorliegen. Die DANFE-PDF-Extraktion – das Lesen der gedruckten Darstellung – fällt auf 90–95 %, da sie zu einem Bildverständnisproblem wird: Schriftvarianten, Druckqualität und Spaltenausrichtungen führen zu denselben Fehlern wie bei jedem gescannten Dokument. Bevorzugen Sie immer XML gegenüber DANFE, wenn beides verfügbar ist.

Das Fazit

Die NF-e-XML-Extraktion ist keine Frage der KI-Fähigkeit – sondern eine Workflow-Entscheidung. Das strukturierte Format macht die Extraktion genauer als jedes bildbasierte Dokument, aber diese Struktur kann trügerisch sein: „Es ist nur XML" lässt das Konsolidierungsproblem einfacher erscheinen, als es ist. Die eigentliche Arbeit – das Zuordnen inkonsistenter Felder über 30 Lieferanten, vier NF-e-Versionen und mehrere Steuerkonfigurationen – ist repetitive Mustererkennung, die KI besser automatisiert als jedes XSLT-Skript oder Excel-Makro.

Die Frage ist nicht, ob KI NF-e-XML extrahieren kann. Es ist die Frage, ob Sie Ihren Nachmittag damit verbringen möchten, <ICMS><ICMSSN102><orig>-Pfade durch 200 Dateien zu verfolgen, oder ob die KI CNPJ, NCM-Codes und ICMS-Werte in weniger als einer Minute in eine Tabellenkalkulation überträgt.

Jetzt mit Ihren NF-e-XML-Dateien testen →