Kann KI Daten aus NF-e-XML extrahieren?
Ja — intelligentes Parsen, nicht 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. NF-e ist jedoch ein Sonderfall: Die Daten liegen bereits strukturiert in XML vor. Extraktion bedeutet hier, das XML-Schema intelligent zu parsen und Felder in lesbare Tabellenspalten zu überführen – nicht OCR. Jeder Lieferant folgt demselben staatlichen Schema, verwendet aber unterschiedliche optionale Felder, Steuerkonfigurationen und versionsspezifische Elemente, was die manuelle Konsolidierung über Dutzende Lieferanten hinweg zu einem wiederkehrenden Kopfschmerz macht.
Wichtige Erkenntnisse
- Staatlich standardisierte NF-e-XML-Daten sollten trivial maschinenlesbar sein – doch die meisten brasilianischen Finanzteams verbringen immer noch zwei Tage pro Monat damit, Felder von 30 Lieferanten, die jeweils ein anderes ERP nutzen, manuell zu konsolidieren.
- Ein NF-e-Parsing-Skript, das mit Version 4.0 einwandfrei funktioniert, scheitert still an Version 2.0, weil dasselbe Feld schlicht nicht existiert – das XML ist gültig, aber das Feld fehlt, und das Skript kann nicht melden, was es nicht findet.
- Semantische Extraktion liest Felder nach ihrer Bedeutung – Lieferanten-CNPJ oder ICMS-Wert – nicht nach ihrer Position im XML-Baum. So extrahiert ein Satz Spaltendefinitionen dieselben Daten aus jeder NF-e, unabhängig von Lieferant oder Version.
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.
/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.<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
Multi-Lieferanten-NF-e-Konsolidierung für SPED Fiscal
Ein mittelständischer Hersteller in São Paulo erhält monatlich 30–50 NF-e-XMLs von Rohstofflieferanten – Stahl von Gerdau, Elektrokomponenten von WEG, Verpackungen von lokalen Anbietern. Jede NF-e hat unterschiedliche ICMS-Sätze (7 % bis 18 % je nach Ursprungsstaat) und variierende Feldvollständigkeit. Die manuelle Erfassung kostete einen Buchhalter zwei volle Tage pro Monat.
Mit KI-Extraktion erzeugt das Hochladen aller XML-Dateien in einen Batch eine konsolidierte Tabelle mit Spalten: Lieferanten-CNPJ, NF-e-Nummer, Ausstellungsdatum, NCM-Code, Produktbeschreibung, Menge, Einzelpreis, ICMS-Basis, ICMS-Wert, NF-e-Gesamtsumme – bereit für den Import in das TOTVS-ERP. Zwei Tage Arbeit werden zu drei Minuten, und ICMS-Werte werden gegen den XML-Gesamtbetragsblock validiert, sodass Fehler vor der SPED-Meldung erkannt werden.
NCM-Extraktion für Einfuhrabgaben
Ein Logistikunternehmen, das Importe abwickelt, benötigt NCM-Codes und Produktwerte aus Lieferanten-NF-e zur Berechnung von Einfuhrabgaben. Jede NF-e enthält 5–20 Positionen mit unterschiedlichen Klassifikationen. Die KI extrahiert in Sekunden eine Zeile pro Position – formatiert für die Zollanmeldevorlage des Spediteurs.
FAQ
Kann KI zwischen ICMS, IPI, PIS und COFINS auf derselben NF-e unterscheiden?
Ja. Jede Steuer hat einen eigenen XML-Block mit eindeutigen Kindelementen – ICMS hat <orig> und <CST>, IPI hat <clEnq>. Die KI ordnet sie sauber getrennten Ausgabespalten zu, da die XML-Struktur sie eindeutig unterscheidet. Das ist für KI einfacher als bildbasierte Extraktion, wo Steuern als undifferenzierte Zahlenreihen erscheinen.
Funktioniert KI mit NF-e aus verschiedenen brasilianischen Bundesstaaten mit unterschiedlichen ICMS-Sätzen?
Ja. Der ICMS-Satz (Alíquota) ist in jeder NF-e im <ICMS>-Block angegeben. Ob eine NF-e São Paulos 18 % oder Rio de Janeiros 19 % trägt, die KI liest den Satz direkt aus dem XML. Auch grenzüberschreitende 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 (Portugiesisch) in eine englischsprachige Tabelle extrahieren?
Ja. Definieren Sie Ausgabespalten auf Englisch – „Supplier CNPJ", „Invoice Total" – und die KI ordnet portugiesische XML-Felder den englischen Kopfzeilen zu. XML-Tags sind sprachneutral, und die semantische Zuordnung funktioniert sprachübergreifend. Mehr dazu 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 kommunales Dokument – jede Stadt (prefeitura) hat ihr eigenes Schema. Anders als die bundesweite Standardisierung der NF-e variieren die NFS-e-Formate je nach Gemeinde. KI kann auch aus NFS-e-XML extrahieren, aber die schemabedingten Unterschiede pro Stadt erfordern mehr Prüfung. NF-e (bundesweit, für Waren) ist zuverlässig; NFS-e (kommunal, für Dienstleistungen) bringt mehr Variablen mit sich.
Ist die KI-Extraktion aus NF-e-XML konform mit brasilianischen Steueraufzeichnungspflichten?
Extraktion ist ein Datentransformationsschritt – sie verändert nicht das originale XML, das Ihre rechtliche Steueraufzeichnung bleibt. Die brasilianischen Steuerbehörden verlangen die Aufbewahrung der digital signierten NF-e-XML für 5 Jahre (prazo decadencial, CTN Art. 173). KI-Extraktion erstellt eine abgeleitete Tabelle; das originale, digital signierte XML bleibt unverändert.
Wie groß ist der Genauigkeitsunterschied zwischen NF-e-XML- und DANFE-PDF-Extraktion?
Das sind völlig unterschiedliche Kategorien. NF-e-XML-Extraktion erreicht 99 %+ bei Kernfeldern, da die Daten in eindeutigen XML-Tags vorliegen. DANFE-PDF-Extraktion – das Lesen der gedruckten Darstellung – fällt auf 90–95 %, da es zu einem Bildverständnisproblem wird: Schriftarten, Druckqualität und Spaltenausrichtungen verursachen dieselben Fehler wie bei jedem gescannten Dokument. Bevorzugen Sie immer XML gegenüber DANFE, wenn beides verfügbar ist.
Fazit
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 täuschen: „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 hinweg – 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. Sondern ob Sie Ihren Nachmittag damit verbringen möchten, <ICMS><ICMSSN102><orig>-Pfade durch 200 Dateien zu verfolgen – oder ob Sie KI in unter einer Minute CNPJ, NCM-Codes und ICMS-Werte in eine Tabelle eintragen lassen.