Brasilianische NF-e Nota Fiscal
XML zu Excel Extraktion

Die DANFE-Falle: Warum die meisten internationalen AP-Teams das falsche Dokument verarbeiten

Wenn eine Lieferung von einem brasilianischen Lieferanten eintrifft, übergibt der Fahrer ein ausgedrucktes Dokument mit einem Barcode und einer 44-stelligen Nummer in der oberen rechten Ecke. Dies ist die DANFE — Documento Auxiliar da Nota Fiscal Eletrônica — und das Wort „Hilfsdokument“ in ihrem Namen ist nicht dekorativ. Sie dient genau einem Zweck: die physische Ware während des Transports zu begleiten, damit die Finanzbehörden an Autobahnkontrollpunkten den Barcode scannen und die Sendung überprüfen können. Sie war nie als vollständige Rechnung konzipiert.

Dennoch ist die DANFE für die überwältigende Mehrheit der internationalen AP-Teams, die brasilianische Waren erhalten, die Rechnung. Sie wird gescannt, per OCR erfasst oder manuell in das ERP eingegeben. Der 44-stellige Zugangsschlüssel wird kopiert – pflichtbewusst, alle 44 Stellen – in ein Feld mit der Bezeichnung „Rechnungsnummer“. Und dann arbeitet der AP-Sachbearbeiter das nächste Dokument ab, ohne zu wissen, dass für jeden Lieferanten, für jede Sendung die vollständige Rechnung bereits in einem maschinenlesbaren XML-Format existiert, das die brasilianische Regierung vom Verkäufer verlangt – erstellt, digital mit einem ICP-Brasil-Zertifikat signiert und an SEFAZ (die staatliche Steuerbehörde) übermittelt, bevor die Ware das Lager legal verlassen darf.

Das Ausmaß des Datenverlusts ist nicht marginal. Die DANFE druckt eine komprimierte Zusammenfassung – Lieferantenname, Käufername, Datum, Positionen mit Mengen und Einzelpreisen sowie eine Gesamtsumme. Die NF-e-XML, die von über 400 automatischen Validierungsregeln gesteuert wird, die SEFAZ zum Zeitpunkt der Autorisierung ausführt, enthält unter der aktuellen Layoutversion 4.0, definiert durch Nota Técnica 2016/002, mehr als 500 strukturierte Tags. Der Unterschied zwischen den beiden Dokumenten ist der Unterschied zwischen einem Kassenbon und dem vollständigen steuerlichen Nachweis einer Transaktion – einem, der Ihre Vorsteuerabzüge, Ihre Zollabstimmung und Ihre Prüfungsspur für die nächsten fünf Jahre bestimmt.

Die Unterscheidung zwischen DANFE und XML ist keine nebensächliche technische Feinheit. Sie ist das mit Abstand wichtigste Konzept für jede AP-Abteilung, die brasilianische Lieferantenrechnungen bearbeitet, und hat eine direkte finanzielle Konsequenz: Wenn Ihr Team Daten aus der DANFE erfasst, tippen Sie manuell einen Bruchteil von Informationen nach, die bereits in strukturierter, maschinenlesbarer Form vorliegen – und verpassen die Steuerdetails, die bestimmen, ob Sie bei jeder Transaktion die richtige Höhe von ICMS, IPI, PIS und COFINS zurückfordern.

Was in einer NF-e-XML steckt – und warum das für die Kreditorenbuchhaltung wichtig ist

Eine NF-e-XML ist nicht einfach eine Rechnung in spitzen Klammern. Es handelt sich um ein rechtlich verbindliches Steuerdokument mit der digitalen Signatur des Verkäufers, das gegen über 400 SEFAZ-Regeln validiert wurde und Steuerdaten in einer Granularität speichert, die jeden anderen E-Rechnungsstandard außerhalb Brasiliens übertrifft. Zum Vergleich: Der europäische Peppol-BIS-Standard verwendet etwa 100 Elemente. Eine NF-e enthält fünfmal so viele – und jedes Element ist maschinenlesbar.

Bevor Sie einen Extraktionsworkflow entwerfen können, müssen Sie verstehen, was Sie extrahieren. Hier sind die wichtigsten Elementgruppen in jeder NF-e-XML und warum sie für die Kreditorenbuchhaltung relevant sind:

Der 44-stellige Zugangsschlüssel (chave de acesso) ist die universelle Kennung der NF-e. Er kodiert das Bundesland des Ausstellers (erste 2 Ziffern, nach IBGE-Code — 35 für São Paulo, 33 für Rio de Janeiro, 31 für Minas Gerais), 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 Kollisionsvermeidungscode (8) und eine Modulo-11-Prüfziffer (1). Jede NF-e-XML trägt diesen Schlüssel im Attribut <infNFe Id="NFe...>, und Sie können ihn verwenden, um direkt bei der SEFAZ die Echtheit zu prüfen, nach Stornierungen zu suchen oder die vollständige XML herunterzuladen, wenn Ihr Lieferant nur das DANFE gesendet hat.

Einrichten Ihres NF-e-XML-Extraktionsworkflows

Es gibt drei verschiedene Ansätze, um NF-e-XML-Daten in eine Excel-Tabelle zu bekommen, die sich in Kosten und Komplexität stark unterscheiden. Welcher für Sie geeignet ist, hängt von Ihrem Volumen, Ihrer ERP-Umgebung und davon ab, ob Ihre brasilianische Tochtergesellschaft bereits ein Lokalisierungsmodul einsetzt.

Methode 1: ERP-Importmodul (SAP TDF, Oracle EBS Brazil, Dynamics 365 Finance)

Wenn Ihr Unternehmen SAP, Oracle EBS oder Microsoft Dynamics 365 mit aktiviertem Brasilien-Lokalisierungsmodul betreibt, kann das ERP selbst NF-e-XML-Dateien direkt importieren. SAPs TDF (Nota-Fiscal-Modul) verarbeitet eingehende NF-e-XMLs über die Transaktion J1BNFE und ordnet jedes XML-Element der entsprechenden SAP-Tabelle zu. Die Oracle EBS-Brasilien-Lokalisierung (verfügbar ab 12.2.6+) verwendet das Programm XML Generator SEFAZ (P76B601) für Importe. Dynamics 365 Finance bietet einen dedizierten Import-Workflow unter Kreditoren > Brasilianische Lokalisierung > NF-e-XML importieren.

Dies ist der Goldstandard – er validiert in Echtzeit gegen die SEFAZ, bucht auf die korrekten Steuerkonten und führt automatisch einen Drei-Wege-Abgleich durch. Er hat jedoch seinen Preis. Die Brasilien-Lokalisierungsmodule von SAP und Oracle sind separate Lizenzkosten, und TOTVS – das dominierende ERP unter brasilianischen mittelständischen Unternehmen mit einem Marktanteil von 33 % laut der aktuellsten Umfrage der Fundação Getúlio Vargas (FGV) – ist vollständig auf Brasilien ausgerichtet und außerhalb des Landes unüblich. Wenn Ihr globales Kreditorenteam keine brasilianische ERP-Lokalisierung hat, steht dieser Ansatz nicht zur Verfügung.

Methode 2: XML-zu-Excel-Konvertierung

Im einfachsten Fall ist eine NF-e-XML-Datei eine XML-Datei, und jede XML-Datei kann in ein Tabellenformat konvertiert werden. Tools wie der integrierte XML-Import von Microsoft Excel (Daten > Daten abrufen > Aus Datei > Aus XML), Online-Konverter oder Python-Skripte mit Bibliotheken wie xml.etree.ElementTree können die XML-Struktur in Zeilen und Spalten aufteilen.

Die Herausforderung bei generischer XML-Konvertierung liegt in der Tiefe des NF-e-Schemas. Eine einzelne NF-e-XML-Datei verschachtelt Positionsdaten in <det>-Elementen, die jeweils einen eigenen <imposto>-Teilbaum mit separaten ICMS-, IPI-, PIS- und COFINS-Gruppen enthalten. Eine naive XML-zu-CSV-Konvertierung erzeugt daraus eine einzige Zeile mit Hunderten von Spalten, von denen viele identisch benannt sind (jede Position hat ein vProd-Feld, jede Steuergruppe ein vBC-Feld). Die Ausgabe ist technisch gesehen „in Excel", aber ohne erhebliche Nachbearbeitung nicht nutzbar.

Pythons xml.etree oder lxml mit expliziten XPath-Abfragen bieten präzise Kontrolle – Sie extrahieren genau die benötigten Elemente und ordnen sie benannten Spalten zu. Das funktioniert gut, wenn Entwicklerressourcen verfügbar sind, erfordert aber die Pflege von XPath-Zuordnungen, die bei jeder Aktualisierung des NF-e-Schemas brechen. Mit der Steuerreform 2026, die neue CBS/IBS-Elementgruppen zum Schema hinzufügt (siehe unten), müssen diese Zuordnungen aktualisiert werden.

Methode 3: KI-gestützte Dokumentenextraktion

Ein dritter Ansatz – der sowohl die Kosten einer ERP-Lokalisierung als auch die Fragilität von XPath-Skripten vermeidet – ist die KI-basierte Dokumentenextraktion. Anstatt XML direkt zu parsen, laden Sie den DANFE (oder die als PDF gerenderte NF-e-XML-Datei Ihres Anbieters) in ein Extraktionstool hoch, geben an, welche Spalten die Ausgabetabelle enthalten soll – „CNPJ", „Rechnungsnummer", „ICMS-Basis", „ICMS-Betrag", „NCM-Code", „CFOP" – und die KI liest das Dokument, um jeden Wert zu lokalisieren, unabhängig davon, wo er auf der Seite erscheint.

Dieser Ansatz – manchmal auch benutzerdefinierte Spaltenextraktion genannt – funktioniert anders als die templatebasierte OCR. Herkömmliche OCR erfordert die Definition einer Vorlage für jedes Rechnungslayout des Lieferanten, die dem System mitteilt: „Die Rechnungsnummer befindet sich immer an den Koordinaten (x,y)." Wenn sich das Layout ändert, bricht die Vorlage. Die spaltenbasierte Extraktion arbeitet stattdessen mit semantischem Verständnis: Sie benennen die gewünschten Felder, und die KI lokalisiert die entsprechenden Werte überall im Dokument, indem sie versteht, was das Feld bedeutet, nicht wo es sitzt. Dies ist besonders relevant für die NF-e-Verarbeitung, da die DANFE-Layouts brasilianischer Lieferanten stark variieren – es gibt keine standardisierte visuelle Vorlage, nur das standardisierte XML-Schema darunter.

Die Einschränkung – und sie ist ehrlich – ist, dass Sie immer noch aus dem visuellen Layout des DANFE extrahieren, nicht aus der maschinenlesbaren XML-Datei. Sie erhalten die 10 % der Daten, die der DANFE anzeigt, nicht die 500+ Felder in der XML-Datei. Für viele AP-Anwendungsfälle – Kopfdaten, Positionen, Summen – ist dies ausreichend und deutlich schneller als die manuelle Eingabe. Wenn Sie jedoch die vollständigen PIS/COFINS-Berechnungen pro Zeile, CFOP-Codes oder CST-Steuersituationscodes benötigen, die nur in der XML-Datei existieren, kann die KI-Extraktion aus dem DANFE keine Daten wiederherstellen, die nicht auf der Seite gedruckt sind.

NF-e-Felder Ihrer Tabelle zuordnen: Was extrahieren und warum

Ob Sie XPath-Abfragen für die XML-Analyse schreiben oder Spaltennamen für die KI-Extraktion definieren – die gewählten Spalten bestimmen den Nutzen der Ausgabe. Hier ist eine praktische Feldzuordnung, die die drei Kern-Workflows der Kreditorenbuchhaltung abdeckt – Lieferantenprüfung, Drei-Wege-Abgleich und Steuergutschriftenbuchung – unter Verwendung der tatsächlichen XML-Elementpfade.

Ein entscheidendes Detail: Der ICMS-Elementpfad hängt von der Steuersituation ab. Das NF-e-Schema verwendet unterschiedliche XML-Untergruppen für verschiedene ICMS-Regime – ICMS00 für standardmäßig besteuerte Vorgänge, ICMS40 für steuerbefreite, ICMS60 für bereits besteuerte mit Steuersubstitution. Ihre Extraktionslogik muss diese verzweigte Struktur navigieren: Prüfen Sie, welche Untergruppe unter <ICMS> existiert, bevor Sie versuchen, deren Kinder zu lesen.

Umgang mit Brasiliens Steuerkomplexität in extrahierten Daten

Die Datenextraktion ist der erste Schritt. Die Validierung ist der Punkt, an dem die eigentliche Arbeit beginnt – und an dem die meisten Fehler entstehen, die bei einer Steuerprüfung ans Licht kommen. Brasiliens Steuersystem operiert auf drei Regierungsebenen (Bundesstaat, Bundesland, Gemeinde) mit Sätzen, die je nach Produktklassifikation, Ursprungs-Ziel-Paar und rechtlicher Natur der Transaktion variieren. Hier sind die Validierungsprüfungen, die Teil jedes NF-e-Datenextraktions-Workflows sein sollten:

ICMS-Satzvalidierung nach Bundesland-Paar

ICMS-Sätze sind nicht einheitlich. Bei grenzüberschreitenden Transaktionen wird der Satz durch das Ursprungs- und Zielland bestimmt:

Bei internen (innerstaatlichen) Transaktionen liegen die Sätze je nach Bundesland zwischen 17% und 22%. Stand 2024 erhebt Pernambuco 20,5%, Bahia 20,5%, Maranhão 22%, Rio de Janeiro 20%, São Paulo 18%, Santa Catarina 17%. Diese Sätze änderten sich 2024 allein in 11 Bundesländern – Bahias Satz stieg am 7. Februar von 19% auf 20,5%, Maranhão am 19. Februar von 20% auf 22% – und Ihre Extraktionsvalidierungslogik muss mit der aktuellen Satztabelle für jedes brasilianische Bundesland, von dem Sie Rechnungen erhalten, Schritt halten.

CFOP-Code-Interpretation

Der CFOP (Código Fiscal de Operações e Prestações) ist ein 4-stelliger Code, der die steuerliche Art der Transaktion klassifiziert. Er wird von der SEFAZ vorgegeben – kein Freitext – und die erste Ziffer zeigt an, ob es sich um einen Wareneingang oder -ausgang handelt und aus welchem Bundesstaat die Waren stammen:

Für den Empfänger bestimmt der CFOP auf einer Eingangsrechnung (1xxx, 2xxx oder 3xxx), ob ICMS- und IPI-Gutschriften verfügbar sind und unter welchen Regeln. Ein CFOP 1101 (innerstaatlicher Einkauf zur Weiterverarbeitung) berechtigt in der Regel zur vollen ICMS-Gutschrift zum internen Satz. Ein CFOP 1102 (innerstaatlicher Einkauf zum Weiterverkauf) kann anders behandelt werden. Dies interagiert mit dem CST (Código de Situação Tributária) – dem 2-stelligen Code, der angibt, ob der Artikel besteuert (00), befreit (40), der Steuersubstitution unterliegt (60) oder einer Sonderregelung unterfällt. Der CFOP sagt Ihnen, welche Art von Vorgang dies ist; der CST sagt Ihnen, wie er besteuert wird. Beide müssen extrahiert und kreuzvalidiert werden.

NCM-Klassifikation und ihre Auswirkungen auf die nachgelagerten Prozesse

Der NCM (Nomenclatura Comum do Mercosul) ist ein 8-stelliger Code, der auf dem internationalen Harmonisierten System basiert und um zwei Mercosur-spezifische Ziffern ergänzt wird. Er erscheint auf jeder Position und bestimmt den IPI-Satz für dieses Produkt (veröffentlicht in der TIPI-Tabelle, einem über 400-seitigen PDF, das von der Receita Federal aktualisiert wird), etwaige Einfuhrzollsätze und – entscheidend – ob das Produkt für Steuervergünstigungen (ermäßigte Sätze, angenommene Gutschriften oder Befreiungen) in Frage kommt, die die Standardsteuerberechnung außer Kraft setzen.

Ein NCM-Code, der unter ein Steuervergünstigungsregime fällt, bedeutet, dass der auf der Rechnung ausgewiesene reguläre ICMS- oder IPI-Satz möglicherweise nicht der Satz ist, den Sie als Gutschrift verbuchen. Ihr Extraktionsworkflow sollte jede Position kennzeichnen, deren NCM mit bekannten Vergünstigungskategorien übereinstimmt, damit Ihre Steuerabteilung die Gutschriftsberechnung überprüfen kann – anstatt einfach davon auszugehen, dass der Bruttosatz korrekt ist.

Die Steuerreform 2026 und was sie für Ihren Extraktionsworkflow bedeutet

Die brasilianische Steuerreform – verabschiedet durch Verfassungszusatz 132/2023 und geregelt durch Ergänzungsgesetz 214/2025 – restrukturiert das indirekte Steuersystem des Landes grundlegend. Fünf bestehende Steuern (PIS, COFINS, ICMS, ISS und IPI) werden schrittweise durch ein duales Mehrwertsteuermodell ersetzt: CBS (Contribuição sobre Bens e Serviços) auf Bundesebene und IBS (Imposto sobre Bens e Serviços) auf Staats- und Gemeindeebene, plus eine Selektivsteuer (IS) auf Waren, die als gesundheits- oder umweltschädlich gelten.

Der Übergangszeitplan ist:

Die unmittelbare operative Herausforderung für AP-Teams ist die Doppelschema-Phase von 2026 bis 2033. In diesen Jahren enthalten NF-e-XML-Dateien gleichzeitig sowohl alte als auch neue Steuerelementgruppen. Ein Extraktionsworkflow, der Feldzuordnungen fest auf das Schema vor 2026 codiert (nur vICMS, vPIS, vCOFINS liest), ignoriert die neuen CBS/IBS-Felder stillschweigend. Dies ist kein Zukunftsproblem – es beginnt jetzt. Ab 1. August 2026 werden NF-e-XMLs ohne CBS/IBS-Felder von SEFAZ abgewiesen. Die Schemaänderung ist verpflichtend, nicht optional.

Wenn Sie XML-Parsing-Skripte schreiben, planen Sie Schema-Verzweigungen ein: Erkennen Sie, welche Steuergruppen im Dokument vorhanden sind, extrahieren Sie die jeweils vorhandenen und normalisieren Sie sie in einen konsistenten Ausgabespaltensatz. Wenn Sie KI-basierte Extraktion aus dem DANFE verwenden, klären Sie mit Ihrem Anbieter, ob CBS/IBS-Felder erkannt werden, sobald sie auf der gedruckten Darstellung erscheinen.

Häufig gestellte Fragen

Kann ich die vollständigen XML-Daten allein aus dem DANFE erhalten?

Nein. Der DANFE ist eine gedruckte Zusammenfassung, die mehr als 90 % der Daten im XML auslässt. Er wurde für die physische Inspektion während des Transports entwickelt, nicht für die Finanzverarbeitung. Die vollständigen Steueraufschlüsselungen, CFOP-Codes, NCM-Klassifikationen, CST-Steuersituationscodes und Transportdetails existieren nur im XML. Wenn Ihr Anbieter nur den DANFE gesendet hat, fordern Sie das XML an – er ist gesetzlich zur Bereitstellung verpflichtet, und Sie können es auch von SEFAZ mit dem auf dem DANFE aufgedruckten 44-stelligen Zugangsschlüssel abrufen.

Wie erfahre ich, welcher ICMS-Satz für eine bestimmte Rechnung gilt?

Der ICMS-Satz auf einer NF-e wird bestimmt durch den Ursprungsstaat (aus der staatlichen Registrierung des Ausstellers in <emit>), den Zielstaat (Staat Ihres Unternehmens in <dest>) und ob die Ware mehr als 40 % importierte Bestandteile enthält (was unabhängig vom Staatspaar den Satz von 4 % auslöst). Das XML selbst führt den vom Verkäufer angewandten Satz in pICMS, aber Sie sollten ihn anhand der korrekten Satztabelle validieren, anstatt anzunehmen, dass der Verkäufer ihn richtig angewandt hat – Satzfehler sind ein häufiger Prüfungsbefund.

Kann KI CFOP-Codes automatisch korrekt interpretieren?

CFOP-Codes werden unverändert aus dem Dokument extrahiert – die 4-stellige Nummer erscheint auf der DANFE und in der XML-Datei. Ob das Tool den Code interpretieren kann (z. B. als „Einkauf im Inland zum Weiterverkauf“ vs. „Einkauf zwischen Bundesstaaten zur Industrialisierung“), hängt von seinen Funktionen ab. Manche KI-Extraktionstools können CFOP-Codes mithilfe einer Referenztabelle ihren Beschreibungen zuordnen. Wenn die Interpretation für Ihren Workflow entscheidend ist, klären Sie mit Ihrem Tool-Anbieter, ob CFOP-Zuordnung unterstützt wird, oder pflegen Sie eine separate Nachschlagetabelle in Excel, um die extrahierten Codes zu entschlüsseln.

Unser Unternehmen hat keine brasilianische ERP-Lokalisierung. Können wir trotzdem NF-e-Daten extrahieren?

Ja. Die XML-Datei selbst hat ein Standardformat, das jedes Unternehmen mit der XML-Datei parsen kann. Sie benötigen weder SAP TDF noch Oracle Brazil-Lokalisierung, um sie zu lesen. Python-Skripte, Online-XML-zu-Excel-Konverter oder KI-Extraktionstools können die Daten alle in eine Tabelle überführen. Das ERP-Lokalisierungsmodul bietet Integration (automatische Buchung, SEFAZ-Validierung, Steuerkontenzuordnung), ist aber für die Extraktion nicht erforderlich.

Deckt die NF-e-Extraktion die SPED-Berichtsanforderungen ab?

Nein. SPED (Sistema Público de Escrituração Digital) ist Brasiliens digitales Buchhaltungssystem, das separate Meldungen erfordert – EFD-ICMS/IPI für die staatliche Steuer, EFD-Contribuições für PIS/COFINS und ECD für digitale Buchhaltungsbücher. Die NF-e-Extraktion überführt die Rechnungsdaten in Excel; sie erzeugt keine SPED-konformen Dateien. SPED-Meldungen erfordern die Zuordnung der extrahierten Daten zu den spezifischen SPED-Layout-Codes und die Übermittlung durch staatlich validierte Software – ein separater Workflow, der von Ihrem brasilianischen Buchhaltungsteam oder Steuer-Compliance-Anbieter durchgeführt wird.

Was passiert, wenn ein Lieferant eine NF-e storniert, nachdem ich die Daten bereits extrahiert habe?

Eine NF-e kann vom Aussteller innerhalb von 24 Stunden nach Autorisierung storniert werden, wenn die Ware noch nicht versandt wurde. Die Stornierung erzeugt ein Ereignis (Stornierungsereignis) im SEFAZ-System, das mit demselben 44-stelligen Zugangsschlüssel verknüpft ist. Jede Abfrage dieses Schlüssels gibt den Status „storniert“ zurück. Ihr Extraktions-Workflow sollte Zugangsschlüssel regelmäßig gegen SEFAZ validieren – insbesondere bei Rechnungen in Zahlungsnähe –, um Buchungen gegen stornierte Dokumente zu vermeiden. Nach der Reform 2026 zieht eine Stornierung nach dem steuerpflichtigen Ereignis eine Strafe von 66 % der fälligen Steuer nach sich, was die Häufigkeit verspäteter Stornierungen reduzieren sollte, aber die Überprüfung bleibt eine notwendige Kontrolle.

Wie verarbeite ich mehrere NF-e-XML-Dateien im Batch?

Bei XML-basierten Methoden verwenden Sie ein Skript, das einen Ordner mit XML-Dateien durchläuft, aus jeder Datei dieselben XPath-Abfragen extrahiert und die Ergebnisse in einer fortlaufenden Tabelle zusammenfasst. Für die KI-gestützte Extraktion aus DANFE-PDFs nutzen Sie die Stapelverarbeitung – laden Sie mehrere DANFE-Dateien gleichzeitig hoch, definieren Sie Ihre Spalten einmal, und das Tool extrahiert die Daten aus jedem Dokument und führt sie in einer einzigen Excel-Datei zusammen. Dieser Ansatz verarbeitet auch gemischte Formate: Wenn einige Lieferanten DANFE-PDFs senden und andere das XML als Ausdruck bereitstellen, extrahiert die Stapelverarbeitung beide Formate in einem Durchlauf.

Wie genau ist die NF-e-Datenextraktion im Vergleich zur manuellen Eingabe?

Bei der XML-basierten Extraktion liegt die Genauigkeit für die abgefragten Felder praktisch bei 100 % – Sie lesen strukturierte Daten aus einer maschinenlesbaren Datei, ohne ein visuelles Layout interpretieren zu müssen. Bei der KI-gestützten Extraktion aus dem DANFE kann die Genauigkeit von gedrucktem Text bis zu 99 % erreichen. Bei komplexen Feldern wie dem 44-stelligen Zugangsschlüssel, bei dem bereits eine vertauschte Ziffer den Schlüssel ungültig macht, hängt die Genauigkeit jedoch von der Verarbeitung langer Zahlenfolgen durch das Tool ab. Der tatsächliche Genauigkeitsgewinn gegenüber der manuellen Eingabe liegt nicht nur in der zeichengenauen Präzision – es geht um Vollständigkeit. Eine Person, die Daten aus einem DANFE erfasst, erfasst typischerweise 8–12 Felder pro Rechnung. Die automatisierte Extraktion erfasst jedes von Ihnen festgelegte Feld in jedem Dokument und vermeidet so die Datenauslassungen, die den häufigsten und am wenigsten sichtbaren Fehler bei der manuellen Eingabe darstellen.