Warum eine XML-Rechnung
die manuelle AP-Datenextraktion nicht beendet

Die Blackbox: Was passiert, nachdem eine XML-Rechnung in Ihrem Posteingang landet

Eine E-Rechnung ist nicht nur ein digitales Dokument. Sie ist eine Datenladung – eine strukturierte XML- oder UBL-Datei, die Rechnungsinformationen in maschinenlesbaren Feldern gemäß der europäischen Norm EN 16931 enthält, die 2017 vom Europäischen Komitee für Normung (CEN/TC 434) veröffentlicht wurde. Die Norm definiert über 160 semantische Datenfelder: Rechnungsnummer, Ausstellungsdatum, Steueridentifikationsnummern von Verkäufer und Käufer, Positionsmengen, Einzelpreise, Mehrwertsteuerkategorien, Zahlungsbedingungen, Lieferadressen und vieles mehr. Theoretisch sollte diese strukturierte Datenladung direkt vom System des Lieferanten in das ERP des Käufers fließen – ohne menschliche Augen, ohne Tastatur, ohne Kopieren und Einfügen.

Die Theorie scheitert am ersten Schritt: Ihrem ERP.

Die meisten ERP-Systeme – SAP, Oracle NetSuite, Microsoft Dynamics 365, Workday – verarbeiten rohe EN 16931 XML nicht nativ. Sie erwarten Rechnungsdaten in ihrem eigenen internen Format, abgebildet auf ihre eigenen Feldnamen, über ihre eigene API oder Importvorlage. Eine Peppol BIS 3.0-Rechnung kommt als UBL 2.1 XML mit einer Tag-Struktur wie <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>. Ihr ERP erwartet ein Feld namens Rechnungstyp mit dem Wert Handelsrechnung. Jemand – oder etwas – muss übersetzen. Diese Übersetzungsschicht wird in der E-Rechnungs-Erzählung als gelöstes Problem behandelt. Für viele AP-Teams ist sie nicht gelöst. Hierhin verlagert sich die manuelle Arbeit, nicht wo sie endet.

Laut dem Billentis/EESPA-Marktbericht für 2019-2025 senden weniger als 20 % der Unternehmen strukturierte elektronische Rechnungen über EDI oder vergleichbare Netzwerke. Etwa zwei Drittel versenden PDF-Rechnungen per E-Mail. Selbst bei den Unternehmen, die XML-Rechnungen empfangen, erreichen die Daten das ERP selten ohne einen Zwischenschritt: eine Middleware-Plattform, einen Peppol-Zugangspunkt, eine Integrationsschicht oder – im Fall der 66 % der AP-Teams, die noch manuelle Eingaben vornehmen – ein Paar menschlicher Augen, die eine visuelle Darstellung der XML lesen und in einen Bildschirm tippen. Die E-Rechnung ist strukturiert. Die letzte Meile ist es nicht.

Eine Rechnung, 164 Felder, 6 brauchen Sie wirklich

EN 16931 legt fest, was eine elektronische Rechnung enthalten muss oder darf – und die Liste ist umfangreich: Verkäufer- und Käuferdaten, Steuervertreter, Zahlungsempfänger, Lieferinformationen, Zahlungsanweisungen, Rabatte und Zuschläge, Steueraufschlüsselung auf Positionsebene, Rechnungszeitraum, Bestellreferenz, Vertragsreferenz, Projektreferenz und mehr. Eine vollständig befüllte EN-16931-Rechnung enthält weit über 100 einzelne Datenpunkte auf mehreren hierarchischen Ebenen.

Ihre Kreditorenbuchhaltung braucht sechs davon.

Die Felder, die Ihr ERP tatsächlich für die Buchung benötigt – Lieferantenname, Rechnungsnummer, Rechnungsdatum, Nettobetrag, Umsatzsteuerbetrag, Fälligkeitsdatum – sind eine kleine Teilmenge dessen, was die XML-Datei enthält. Die anderen 150+ Felder sind Rauschen. Sie dienen der Prüfung durch die Steuerbehörden, der Routing-Logik des Peppol-Netzwerks und der Archivierungspflicht des Lieferanten. Sie sind nicht für Sie da. Aber jede Integration, die einen vollständigen XML-Import durchführt, zieht alle mit ein, und jemand muss diese Zuordnungen für jeden Lieferanten, jedes Land und jede XML-Schema-Variante abbilden, validieren und pflegen.

Diese Realität weist auf ein kontraintuitives wirtschaftliches Problem hin, das die meisten ROI-Modelle für E-Rechnungen übersehen. Die Kosten für die Einrichtung und Pflege vollständiger XML-Schema-Zuordnungen für Dutzende oder Hunderte von Lieferanten können die Kosten übersteigen, die sechs benötigten Felder einfach aus jedem Dokumentenformat – XML, PDF oder Bild – zu extrahieren. Die E-Rechnungs-Infrastruktur wurde gebaut, um die Informationslücke der Steuerbehörden zu schließen. Sie wurde nicht gebaut, um die Datenextraktionslücke Ihrer Kreditorenbuchhaltung zu schließen. Das sind zwei verschiedene Probleme, und die Lösung des ersten löst nicht automatisch das zweite.

Der E-Rechnungs-Forschungsbericht von Vertex 2025 befragte Unternehmen in Märkten mit E-Rechnungspflicht und stellte fest, dass die Technologieintegration für 55 % der Befragten das größte Problem darstellt – bei Unternehmen, die in mehreren Ländern tätig sind, steigt dieser Wert auf 63 %. Die Hälfte aller Befragten nannte Datenverwaltung als erhebliches Problem. Dies sind keine Unternehmen, die die Einführung der E-Rechnung verpasst haben. Es sind Unternehmen, die sie eingeführt haben und nun mit den Folgen umgehen.

Vier Länder, vier XML-Dialekte, ein AP-Posteingang

EN 16931 ist ein Standard, kein Format. Er definiert die semantische Bedeutung von Rechnungsfeldern und erlaubt zwei Syntaxen: UBL 2.1 und UN/CEFACT Cross Industry Invoice (CII). Jedes Land veröffentlicht dann eine CIUS – eine Core Invoice Usage Specification –, die den Standard an nationale Steuervorschriften anpasst, indem sie Feldanforderungen ergänzt oder verschärft. Das Ergebnis ist eine Landschaft, in der vier strukturell unterschiedliche XML-Schemata im selben Posteingang landen können, alle „EN 16931-konform“ sind, aber untereinander inkompatibel hinsichtlich ihrer Import-Mappings.

Wenn Ihr Unternehmen in Deutschland, Frankreich, Italien und Polen tätig ist – eine Präsenz, die Tausende mittelständische europäische Unternehmen beschreibt –, landen in Ihrem AP-Posteingang vier strukturell unterschiedliche XML-Schemata, die sich alle E-Rechnung nennen. Sie benötigen vier separate Import-Mappings, vier Sätze Validierungsregeln und vier Wartungspipelines, die brechen, sobald eine nationale Steuerbehörde ihr Schema aktualisiert. Der Aktualisierungsrhythmus ist nicht theoretisch. Polens KSeF-Migration von FA(2) auf FA(3) erforderte von jedem integrierten System eine Neuzuordnung seiner Felddefinitionen. Frankreich aktualisierte seine PPF-Anforderungen zwischen der Pilotphase 2025 und dem Produktivstart 2026. Deutschlands XRechnung-Spezifikation ist seit Anfang 2026 in Version 3.0.1.

Das ist kein Argument gegen E-Rechnungen. Es ist ein Argument gegen die Annahme, dass der Erhalt strukturierter Daten bedeutet, Daten in Ihrer Struktur zu erhalten. Der Standard EN 16931 wurde für die Interoperabilität zwischen Steuerbehörden entwickelt, nicht zwischen dem ERP Ihres Lieferanten und Ihrem.

Das PDF, das nicht verschwindet

Der Zeitplan für die E-Rechnungspflicht beschleunigt sich. Belgien startete im Januar 2026 mit nahezu universellem Geltungsbereich. Polen folgte im Februar für Großunternehmen. Frankreich aktiviert die Pflicht im September 2026 für große und mittlere Unternehmen. Deutschlands B2B-Pflicht wird bis 2028 schrittweise eingeführt. Eine detaillierte Aufschlüsselung aller Fristen und ihrer Rechtsgrundlagen finden Sie in unserem Zeitplan für die E-Rechnungspflicht in Europa.

Doch jedes Mandat enthält Ausnahmen, und diese Ausnahmen erzeugen einen PDF-Restbestand, den keine kommende Frist beseitigen wird. Das Muster ist über alle Rechtsräume hinweg konsistent:

• Grenzüberschreitende Lieferanten sind ausgenommen. Ein deutsches Unternehmen, das Rechnungen von einem US-amerikanischen oder chinesischen Lieferanten erhält, unterliegt keiner EU-E-Rechnungspflicht. Diese Lieferanten werden auf unbestimmte Zeit weiterhin PDFs, E-Mail-Anhänge und Papierrechnungen versenden.
• B2C-Transaktionen sind ausgeschlossen. Verbraucherrechnungen, Quittungen und Einzelhandelstransaktionen fallen vollständig aus dem Anwendungsbereich strukturierter E-Rechnungen heraus – und dennoch landen diese Dokumente häufig in Kreditoren-Workflows zur Spesenabrechnung.
• Kleine Unternehmen erhalten verlängerte Fristen oder dauerhafte Ausnahmen. Frankreich verschiebt die Ausstellungspflicht für Kleinstunternehmen auf September 2027. Deutschlands schwellenwertbasierte Einführung bedeutet, dass Unternehmen unter bestimmten Umsatzgrenzen überhaupt keine Verpflichtung haben. Dies sind oft genau die Long-Tail-Lieferanten, deren Rechnungen bereits die meiste Bearbeitungszeit in Anspruch nehmen.
• Bestehende Lieferantenbeziehungen wechseln nicht über Nacht. Ein Lieferant, der 2015 für EDI integriert wurde, hat möglicherweise keinen Anreiz, auf Peppol BIS 3.0 zu migrieren. Sein PDF-Workflow funktioniert. Ihr Mandat ändert nicht seine Systeme – es ändert Ihre Meldepflicht, nicht seine Formatierungspflicht.

Die Daten von Ardent Partners bestätigen das Ausmaß: Nur 51,4 % der Rechnungen treffen elektronisch ein, und diese Zahl spiegelt zwei Jahrzehnte Fortschritt bei der E-Rechnung wider. Die verbleibenden 48,6 % – PDF-Anhänge, gescanntes Papier, E-Mail-Text, Faxe – stellen einen strukturellen Anteil des Rechnungsvolumens dar, den kein Mandatszeitplan auf null bringen wird. Selbst in Italien, wo das SdI-System seit 2019 verpflichtend ist und jährlich über 2 Milliarden E-Rechnungen verarbeitet, treffen weiterhin täglich grenzüberschreitende PDF-Rechnungen ein. Das Mandat garantiert die Meldung an die Behörden. Es garantiert keinen sauberen Kreditoren-Posteingang.

Der 2026 State of Invoice Automation Report von Gennai beziffert den Anteil der vollständig automatisierten Finanzteams auf 8 %. Acht Prozent. Nach zwei Jahrzehnten E-Rechnungsentwicklung, nach Milliarden an Marktinvestitionen, nach dreizehn aktiven europäischen Mandaten. Die Lücke ist keine vorübergehende Unannehmlichkeit. Sie ist der dauerhafte Betriebszustand einer globalen Kreditorenbuchhaltung.

Eine Pipeline für beide Welten

Wenn Ihr AP-Team einen Workflow für XML-Rechnungen und einen anderen für PDF-Rechnungen betreibt, haben Sie die Rechnungsverarbeitung nicht automatisiert. Sie haben die Anzahl der Workflows verdoppelt, die Ihr Team warten muss – jeder mit eigenen Bruchstellen, eigener Integrationsfläche und eigenem Schulungsbedarf. Die Alternative ist nicht, die E-Rechnungspflicht aufzugeben. Es geht darum, eine einzige Extraktions-Pipeline zu betreiben, die sowohl strukturierte XML- als auch unstrukturierte PDF-Rechnungen durch dieselbe Linse verarbeitet und dasselbe Ausgabeschema liefert, unabhängig vom eingehenden Format.

Für diesen Ansatz wurde das Spaltennamen-Extraktionsmodell entwickelt. Statt länderspezifischer XML-Schema-Mappings definieren Sie einmal die Felder, die Ihr ERP tatsächlich benötigt – Lieferant, Rechnungsnr., Datum, Netto, USt., Fälligkeitsdatum. Diese sechs Spaltennamen werden zum Extraktionsziel für jedes Dokument, das in die Pipeline gelangt – sei es eine Peppol BIS 3.0 XML eines belgischen Lieferanten, eine Factur-X-Hybrid-PDF eines französischen Anbieters, eine gescannte Papierrechnung eines chinesischen Herstellers oder eine per E-Mail versandte PDF eines inländischen KMU, das noch nicht von der Pflicht erfasst wird.

Der Mechanismus ist entscheidend. Anders als beim schema-basierten Import, der genaue Kenntnis jeder XML-Tag-Struktur erfordert, liest die benutzerdefinierte Spaltenextraktion den Inhalt des Dokuments – die eigentlichen Rechnungsdaten – und findet die Werte, die Ihren Spaltendefinitionen entsprechen, indem sie versteht, was jedes Feld bedeutet, nicht wo es in einer XML-Hierarchie sitzt. Eine UBL-Rechnung, die die Rechnungsnummer als <cbc:ID>INV-2026-0451</cbc:ID> schreibt, und eine PDF, die „Rechnung INV-2026-0451" oben rechts druckt, liefern dasselbe Extraktionsergebnis in Ihre Spalte Rechnungsnr.. Kein Schema-Mapping. Keine länderspezifische Konfiguration. Eine Pipeline.

Für einen tieferen Einblick, wie dieser Ansatz mit verschiedenen Rechnungsformaten, Sprachen und Zahlenkonventionen funktioniert, lesen Sie unseren Leitfaden zum Extrahieren von Daten aus Rechnungen mit unterschiedlichen Formaten in eine einheitliche Tabelle.

FAQ

Macht E-Rechnung die Datenextraktion nicht völlig überflüssig?

Sie macht eine Kategorie der Datenextraktion überflüssig – die, bei der ein Mensch eine PDF liest und Werte in ein ERP eingibt. Sie macht jedoch keine Datenübersetzungsschicht zwischen dem XML-Schema des Lieferanten und der Feldstruktur Ihres ERPs überflüssig. Für Unternehmen, die diese Übersetzungsschicht für alle Lieferanten und alle Betriebsländer aufgebaut haben und pflegen, ermöglicht die E-Rechnung eine durchgängige Verarbeitung. Die Daten von Ardent Partners zeigen, dass nur 8 % der Finanzteams diesen Zustand erreicht haben. Für die anderen 92 % ersetzt eine Extraktionsschicht, die sowohl XML als auch PDF über denselben Mechanismus liest, zwei separate manuelle Arbeitsabläufe durch einen automatisierten.

Kann ich nicht einfach einmalig XML-Import-Mappings pro Land erstellen und fertig?

Das ist möglich, und einige Organisationen tun es. Die Wartungskosten werden in den meisten ersten Schätzungen unterschätzt. Nationale Steuerbehörden aktualisieren ihre Schemata – Polen migrierte von FA(2) auf FA(3), Deutschlands XRechnung-Spezifikation ist auf Version 3.0.1, Frankreichs PPF-Anforderungen entwickelten sich zwischen Pilot und Live-Gang. Jede Änderung erfordert Regressionstests über die gesamte Lieferantenbasis. Für ein Unternehmen, das in vier Ländern mit 200 Lieferanten tätig ist, ist das Mapping-Wartungsprogramm ein wiederkehrender operativer Aufwand, kein einmaliges IT-Projekt. Ein visueller Extraktionsansatz umgeht dies, indem er nicht von einer XML-Tag-Struktur abhängt – er liest die Daten selbst, nicht das Schema, das sie geliefert hat.

Was ist mit Lieferanten, die sowohl XML- als auch PDF-Versionen derselben Rechnung senden?

Dies ist bei hybriden ZUGFeRD/Factur-X-Formaten üblich, die eine XML-Datenschicht in einem PDF/A-3-Container einbetten. Die PDF-Schicht und die XML-Schicht können voneinander abweichen – die PDF kann eine vollständige Positionsaufschlüsselung enthalten, während das XML ein MINIMUM-Profil ohne Positionen ist, oder das XML spiegelt eine korrigierte Version wider, während die PDF das Original zeigt. Ein visueller Extraktionsansatz liest den tatsächlich gerenderten Inhalt, also die Version, die Ihr AP-Team sehen und prüfen würde. Er erkennt auch Abweichungen, die ein blinder XML-Import übersehen würde.

Wie funktioniert die Stapelverarbeitung bei einer Mischung aus XML- und PDF-Rechnungen?

Mit einer einheitlichen Extraktions-Pipeline behandelt die Stapelverarbeitung XML und PDF als zwei Eingabeformate für denselben Vorgang. Laden Sie einen Ordner mit 20 Peppol-XMLs von belgischen Lieferanten, 15 per E-Mail zugesandten PDFs von inländischen Anbietern und 5 eingescannten Papierrechnungen von grenzüberschreitenden Lieferanten hoch – definieren Sie Ihre Spalten einmal, verarbeiten Sie den gesamten Stapel in einem Durchlauf und erhalten Sie eine einzige Tabelle mit allen 40 Rechnungen in einheitlichen Spalten. Keine Vorsortierung nach Format, keine separaten Workflows, keine manuelle Neueingabe für den PDF-Anteil des Stapels.

Funktioniert dieser Ansatz speziell mit Peppol?

Ja. Peppol ist ein Transportnetzwerk, kein Rechnungsformat. Das eigentliche Dateiformat ist UBL 2.1 XML, strukturiert nach Peppol BIS Billing 3.0. Ein visueller Extraktionsansatz liest die Rechnungsdaten aus der Inhaltsebene, unabhängig davon, ob die Rechnung über Peppol, E-Mail, Lieferantenportal oder einen anderen Kanal eingegangen ist. Das Peppol-Netzwerk löst das Zustellungsproblem – die Rechnung vom Lieferanten zu Ihnen zu bringen. Die Extraktionsebene löst das Datenproblem – die Rechnungsdaten in der von Ihrem ERP erwarteten Struktur in Ihr ERP zu überführen.

Die entscheidende Kennzahl

Die E-Rechnungsbranche misst den Fortschritt an der Mandatsabdeckung: wie viele Länder, wie viele Unternehmen, wie viele Rechnungen über staatliche Plattformen laufen. Diese Kennzahlen messen die Steuerkonformität – ein legitimes und wichtiges Ziel. Sie messen nicht, worauf AP-Teams wirklich achten: wie viele Rechnungen heute ohne menschlichen Eingriff im ERP verbucht wurden.

Wenn diese zweite Zahl nach Ihrer E-Rechnungsinvestition niedriger ist als erwartet, liegt das Problem nicht darin, dass Sie die falsche E-Rechnungsplattform gewählt haben. Es liegt daran, dass E-Rechnungsplattformen entwickelt wurden, um ein anderes Problem zu lösen. Ihre Lücke ist nicht die zwischen Papier und digital. Es ist die Lücke zwischen „im richtigen Format angekommen" und „in den richtigen Feldern angekommen". Das sind zwei getrennte Lücken. Die Schließung der ersten würde die zweite nie schließen.

Die Extraktionsebene zwischen Ihrer E-Rechnungsplattform und Ihrem ERP ist keine temporäre Brücke in eine vollautomatische Zukunft. Sie ist die dauerhafte Infrastruktur einer Welt, in der Lieferantenrechnungen in mehreren Formaten aus mehreren Jurisdiktionen unter mehreren Regulierungsregimen eingehen – und das immer tun werden. Die Frage ist, ob diese Extraktionsebene ein Mensch, eine Sammlung brüchiger länderspezifischer XML-Mappings oder eine einzige Pipeline ist, die das liest, was auf der Rechnung steht, unabhängig davon, wie sie dorthin gelangt ist.

Testen Sie es mit Ihren eigenen Rechnungen. XML und PDF, im selben Stapel, gegen die Spalten, die Ihr ERP tatsächlich benötigt. Sehen Sie, ob die Lücke zwischen „erhalten" und „verbucht" auf das schrumpft, was das E-Rechnungsmandat immer versprochen hat.