Warum XML-Rechnungen
die manuelle AP-Datenextraktion nicht beenden

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 Ladung 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 rohes 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> an. Ihr ERP erwartet ein Feld namens Rechnungstyp mit einem Wert von 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 des 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äuferrechtsperson, Steuervertreter, Zahlungsempfänger, Lieferinformationen, Zahlungsanweisungen, Rabatt- und Gebührendetails, positionsbezogene Steueraufschlüsselungen, 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 enthält. Die anderen 150+ Felder sind Rauschen. Sie dienen der Prüfung durch die Steuerbehörde, der Routing-Logik des Peppol-Netzwerks und der Archivierungskonformität 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 über Dutzende oder Hunderte von Lieferanten hinweg 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örde 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 Vertex 2025 E-Rechnungs-Forschungsbericht befragte Unternehmen in verpflichteten Märkten 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 Daten-Governance als erhebliches Problem. Dies sind keine Unternehmen, die die Einführung von E-Rechnungen versäumt 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 von mittelständischen europäischen Unternehmen beschreibt –, landen in Ihrem AP-Posteingang vier strukturell unterschiedliche XML-Schemata, die sich alle als E-Rechnungen bezeichnen. Sie benötigen vier separate Import-Mappings, vier Sätze von Validierungsregeln und vier Wartungspipelines, die jedes Mal brechen, wenn 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 hat seine PPF-Anforderungen zwischen der Pilotphase 2025 und dem Produktivstart 2026 aktualisiert. Deutschlands XRechnung-Spezifikation liegt Anfang 2026 in Version 3.0.1 vor.

Das ist kein Argument gegen E-Rechnungen. Es ist ein Argument gegen die Annahme, dass der Empfang strukturierter Daten bedeutet, Daten in Ihrer Struktur zu erhalten. Der EN-16931-Standard wurde für die Interoperabilität zwischen Steuerbehörden entwickelt, nicht zwischen Ihrem ERP und dem Ihres Lieferanten. Die nationale CIUS-Ebene existiert genau deshalb, weil jedes nationale Steuerrecht andere Felder, andere Codes und andere Validierungen erfordert. Interoperabilität auf Steuerebene bedeutet keine Interoperabilität auf AP-Workflow-Ebene – und die Lücke zwischen diesen beiden Ebenen ist der Alltag jedes AP-Teams.

Das PDF, das nicht verschwindet

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

Doch jedes Mandat enthält Ausnahmen, und diese Ausnahmen erzeugen einen PDF-Restbestand, den kein kommender Stichtag beseitigen wird. Das Muster ist über alle Rechtsordnungen hinweg konsistent:

• Grenzüberschreitende Lieferanten sind ausgenommen. Ein deutsches Unternehmen, das Rechnungen von einem US-amerikanischen oder chinesischen Lieferanten erhält, unterliegt keinem EU-E-Rechnungsmandat. 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 – und dennoch landen diese Dokumente häufig in AP-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 werden nicht über Nacht umgestellt. 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 E-Rechnungsentwicklung wider. Die restlichen 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 kein sauberes AP-Postfach.

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 kein vorübergehendes Ärgernis. Sie ist der Dauerzustand einer globalen AP-Funktion.

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 zu wartenden Workflows verdoppelt – jeder mit eigenen Bruchstellen, eigener Integrationsfläche und eigenem Schulungsbedarf. Die Alternative ist nicht, die E-Rechnungspflicht aufzugeben. Es ist, eine einzige Extraktionspipeline zu betreiben, die sowohl strukturiertes XML als auch unstrukturiertes PDF 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 ein Peppol BIS 3.0 XML eines belgischen Lieferanten, ein Factur-X-Hybrid-PDF eines französischen Anbieters, eine gescannte Papierrechnung eines chinesischen Herstellers oder ein PDF per E-Mail eines inländischen KMU, das noch nicht von der Pflicht erfasst wird.

Der Mechanismus ist entscheidend. Anders als der schema-basierte 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 ein PDF, das oben rechts „Rechnung INV-2026-0451" 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 über verschiedene Rechnungsformate, Sprachen und Zahlenkonventionen hinweg funktioniert, lesen Sie unseren Leitfaden zum Extrahieren von Daten aus Rechnungen unterschiedlicher Formate in eine einheitliche Tabelle.

FAQ

Macht E-Rechnung die Datenextraktion nicht komplett überflüssig?

Sie macht eine Kategorie der Datenextraktion überflüssig – die, bei der ein Mensch ein PDF liest und Werte in ein ERP eintippt. Nicht überflüssig wird dagegen eine Datenübersetzungsschicht zwischen dem XML-Schema des Lieferanten und der Feldstruktur Ihres ERPs. Unternehmen, die diese Übersetzungsschicht für alle Lieferanten und alle Länder, in denen sie tätig sind, aufgebaut haben und pflegen, profitieren von der E-Rechnung mit vollautomatischer 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?

Kann man, und manche Organisationen tun das. Die Wartungskosten werden jedoch meist unterschätzt. Nationale Steuerbehörden aktualisieren ihre Schemata – Polen migrierte von FA(2) auf FA(3), Deutschlands XRechnung-Spezifikation ist bei Version 3.0.1, Frankreichs PPF-Anforderungen entwickelten sich zwischen Pilot und Live-Gang weiter. 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 eine wiederkehrende Betriebsausgabe, 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 einen PDF/A-3-Container einbetten. Die PDF-Schicht und die XML-Schicht können voneinander abweichen – das 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 das 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 erhaltenen 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 konsistenten Spalten. Es gibt keine Vorsortierung nach Format, keine separaten Workflows und 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 sie über Peppol, E-Mail, Lieferantenportal oder einen anderen Kanal eingegangen sind. 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 Kennzahl, die zählt

Die E-Rechnungsbranche misst Fortschritte 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 Wert legen: wie viele Rechnungen heute ohne menschlichen Eingriff in das ERP gebucht 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 permanente 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 eine Person, 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 „gebucht" auf das schrumpft, was das E-Rechnungsmandat immer impliziert hat.