Faktor-X Das Hybridformat erklärt

Was Factur-X ist und warum es als Hybridformat bezeichnet wird

Factur-X ist ein deutsch-französischer Standard für elektronische Rechnungen, der gemeinsam von FNFE-MPE in Frankreich und FeRD in Deutschland entwickelt wurde. Das deutsche Pendant heißt ZUGFeRD. Die beiden Formate sind technisch identisch, lediglich die Bezeichnung variiert je nach Ausstellungsland.

Der Begriff „Hybrid“ bezieht sich auf eine besondere Eigenschaft: Eine Factur-X-Datei enthält gleichzeitig zwei vollständige Darstellungen derselben Rechnung. Die erste ist ein PDF-Dokument, das mit jedem gängigen E-Book-Reader geöffnet, gelesen und gedruckt werden kann. Die zweite ist eine strukturierte XML-Datei, die in das PDF eingebettet ist und von Buchhaltungssoftware, ERP-Systemen und zugelassenen Plattformen automatisch gelesen und verarbeitet werden kann.

Diese beiden Ebenen sind nicht einfach Kopien voneinander. Sie existieren im selben Container und erfüllen jeweils einen eigenen Zweck. PDF gewährleistet die Kontinuität der Arbeitsabläufe: Ein Manager, ein Buchhalter oder ein Kunde kann die Rechnung ohne spezielle Tools visuell prüfen. XML hingegen wird direkt in Informationssysteme eingespeist, ohne dass eine erneute Dateneingabe, OCR oder das Risiko von Übertragungsfehlern erforderlich ist.

Genau diese doppelte Fähigkeit führte dazu, dass Factur-X neben UBL und reinem CII als eines der drei Mindeststandardformate für die französische Reform ausgewählt wurde. Es erfüllt zwei gleichzeitig bestehende Anforderungen, die reine XML-Formate allein nicht erfüllen können: die maschinelle Verarbeitbarkeit und die Lesbarkeit für Menschen ohne spezielle Software.

Wie wird eine Factur-X-Datei erstellt?

Eine Factur-X-Datei basiert auf einer Architektur aus drei untrennbaren Elementen. Fehlt eines davon oder ist es falsch formatiert, lehnen die zugelassenen Plattformen das Dokument ab, noch bevor sie dessen Daten lesen können.

Das erste Element ist der PDF/A-3-Container. Dies ist eine archivierbare Variante des PDF-Formats, definiert durch die Norm ISO 19005-3. Im Vergleich zu früheren Versionen des PDF/A-Formats ermöglicht Version 3 die Integration von Anhängen beliebigen Typs in das Dokument. Diese Funktionalität macht die hybride Architektur möglich: Die XML-Datei wird in das PDF eingebettet, nicht daneben. Ein Standard-PDF kann diese Funktion nicht erfüllen, selbst wenn es umbenannt oder elektronisch signiert wird.

Das zweite Element ist die eingebettete XML-Datei, die den Namen tragen muss. factur-x.xmlDiese Datei entspricht der UN/CEFACT CII-Syntax (Cross Industry Invoice). Sie strukturiert die Rechnungsdaten in einer präzisen Hierarchie: Kopfzeile mit Nummer, Datum und Dokumenttyp; Abschnitte mit den vollständigen Angaben zu Verkäufer und Käufer, deren Umsatzsteuer-Identifikationsnummern und SIREN-Nummern; Rechnungspositionen mit Mengen, Einzelpreisen und Mehrwertsteuersätzen; Summen; und Zahlungsbedingungen. Die Semantik dieser Daten ist in der europäischen Norm EN 16931 des Europäischen Komitees für Normung definiert.

Das dritte Element ist ein in die PDF-Datei eingebetteter XMP-Metadatenblock. Diese Metadaten deklarieren das Konformitätsprofil der Datei über ein bestimmtes Feld. Eine Inkonsistenz zwischen diesem Feld und dem tatsächlich im XML-Dokument deklarierten Profil wird von den Validatoren erkannt und führt zur Ablehnung der Datei. Daher müssen alle drei Elemente konsistent sein: ein gültiger PDF/A-3-Container, korrekt benanntes und strukturiertes XML-Dokument sowie mit dem XML-Profil übereinstimmende XMP-Metadaten.

Die Konsistenzregel zwischen den beiden Ebenen ist asymmetrisch: Alle im XML enthaltenen Daten müssen im sichtbaren PDF erscheinen. Das PDF kann jedoch zusätzliche Informationen (Logo, AGB, Kommentare) anzeigen, die nicht im XML enthalten sind, sofern es sich nicht um obligatorische, prüfungspflichtige Informationen handelt. Bei Abweichungen in Beträgen oder Steuerdaten hat das XML für die automatisierte Verarbeitung Vorrang.

Warum wurde dieses Format für die französische Reform gewählt?

Die französische Reform der elektronischen Rechnungsstellung sieht vor, dass ab dem 1. September 2026 alle umsatzsteuerpflichtigen Unternehmen elektronische Rechnungen über eine zugelassene Plattform empfangen können müssen. Die Pflicht zur Ausstellung elektronischer Rechnungen wird stufenweise eingeführt: Große Unternehmen und mittelständische Betriebe (KMU) stellen am 1. September 2026 um, während für KMU, Kleinstunternehmen und Kleinstunternehmen ab 2027 ein per Dekret festgelegter Zeitplan gilt.

Factur-X wurde aufgrund mehrerer konkreter Gründe für die Erfüllung der Mindestanforderungen ausgewählt. Erstens ermöglicht es einen reibungslosen Übergang. Unternehmen, die eine Factur-X-Datei erhalten, können diese wie ein normales PDF öffnen, falls ihre Software noch nicht für die XML-Wiedergabe konfiguriert ist, und die Verarbeitung dann schrittweise automatisieren, sobald die vorhandenen Tools weiterentwickelt sind. Diese Flexibilität ist besonders wertvoll für Kleinstunternehmen und KMU, die ihre Anbindung an eine zugelassene Plattform noch nicht abgeschlossen haben.

Der zweite Grund ist die deutsch-französische Interoperabilität. Da Factur-X und ZUGFeRD technisch identisch sind, kann ein Unternehmen, das Kunden in Frankreich und Deutschland Rechnungen stellt, für beide Märkte dasselbe Format verwenden, ohne zusätzliche Konvertierung.

Der dritte Grund ist die bereits weite Verbreitung des Formats. Factur-X wird von mehr als 130 zugelassenen Plattformen und einer Vielzahl von Rechnungs- und Finanzmanagement-Softwarelösungen unterstützt, wodurch das Risiko von Ablehnungen aufgrund technischer Inkompatibilitäten zwischen Sender und Empfänger verringert wird.

Es ist wichtig zu beachten, dass Factur-X nicht per se verpflichtend ist. Die Reform schreibt die Übermittlung strukturierter elektronischer Rechnungen über eine zugelassene Plattform vor. Factur-X ist neben UBL und reinem CII eines der drei möglichen Formate im Kernsystem. Zugelassene Plattformen müssen alle drei Formate konvertieren können. Das bedeutet, dass ein Factur-X-Absender Rechnungen an einen Empfänger im UBL-Format senden kann und umgekehrt.

Die Unterschiede zwischen Factur-X, UBL und CII

Die drei Formate des Mindeststandards vermitteln dieselbe, in der Norm EN 16931 definierte Semantik. Sie unterscheiden sich weder durch den Umfang der enthaltenen Daten noch durch ihre regulatorische Gültigkeit. Der Unterschied liegt in der Beschaffenheit der Datei, ihrer Lesbarkeit für Menschen und den Systemen, in die sie eingebettet ist.

Der entscheidende Faktor bei der Wahl zwischen diesen drei Formaten ist oft die Lesbarkeit. Ein Empfänger, der noch keine kompatible Software besitzt, kann eine Factur-X-Datei öffnen und wie jede andere PDF-Rechnung lesen. Eine reine UBL- oder CII-Datei hingegen lässt sich in einem Standard-Reader nicht anzeigen: Ohne ein entsprechendes Anzeigeprogramm erscheint sie als eine Reihe unlesbarer XML-Tags. Dieses Kriterium erklärt die Dominanz von Factur-X bei kleinen Unternehmen während der Übergangsphase.

Für Unternehmen, die große Datenmengen mit vollautomatisierten Systemen verarbeiten, sind reine UBL- oder CII-Dateien möglicherweise die bessere Wahl: Die Datei ist kleiner, die Verarbeitung erfolgt vollständig maschinell, und es gibt keine PDF-Ebene, die den Datenaustausch zusätzlich verkompliziert. Da zertifizierte Plattformen die Konvertierung zwischen den drei Formaten übernehmen, hat der Empfänger keine Einschränkungen hinsichtlich des Sendeformats.

Factur-X-Profile und was jedes einzelne beinhaltet

Factur-X definiert fünf Profile, die den Detaillierungsgrad des eingebetteten XML-Codes festlegen. Die Profile bauen aufeinander auf: Jede Ebene umfasst die Felder der darunterliegenden Ebene und erweitert diese. Durch die Auswahl eines Profils wird der Detaillierungsgrad bestimmt, den der Empfänger automatisch aus der Rechnung extrahieren kann.

Profil MINIMUM Die XML-Datei enthält lediglich die Rechnungsdaten: Rechnungsnummer, Datum, Verkäufer- und Käuferdaten sowie Gesamtbetrag. Detaillierte Positionen sind nicht enthalten. Der Empfänger muss die PDF-Datei lesen, um den Rechnungsinhalt zu verstehen. Dieses Format ist für B2B-Transaktionen im Rahmen der Reform unzureichend.

Profil BASIC WL (Ohne Zeilen) fügt Kopf- und Fußzeileninformationen für Rechnungen sowie die aggregierte Mehrwertsteueraufschlüsselung und die Zahlungsbedingungen hinzu, jedoch weiterhin ohne Einzelhandelszeilen. Dies wird zu Beginn der Reform übergangsweise toleriert, ist aber nicht als langfristiges Produktionsziel vorgesehen.

Profil BASIC ist das erste Format, das Rechnungspositionen in die XML-Datei aufnimmt: Artikelname, Menge, Einzelpreis, Nettobetrag und Umsatzsteuerkategorie pro Position. Obwohl es technisch gesehen eine Teilmenge von EN 16931 ist, wird es im Rahmen der französischen Reform nicht als meldepflichtiges Profil akzeptiert: Eine konforme BASIC-Rechnung muss gemäß EN 16931 gemeldet werden.

Profil EN 16931 Es deckt den gesamten europäischen semantischen Kern ab, d. h. alle im Standard definierten Pflichtfelder und bedingten Felder. Dazu gehören Rabatte und Gebühren auf Dokumentebene, Auftragsreferenzen, Abrechnungszeiträume und eine vollständige Mehrwertsteueraufschlüsselung. Dies ist das empfohlene Profil für die überwiegende Mehrheit der B2B-Transaktionen.

Profil VERLÄNGERTDie französische Variante EXTENDED-CTC-FR erweitert die Norm EN 16931 um logistische, zollrechtliche und branchenspezifische Daten. Sie ist relevant für Unternehmen, deren Rechnungen komplexe Strukturen aufweisen: mehrere Bestellungen, mehrere Lieferungen, Incoterms und Unterpositionen für Bausätze oder zusammengesetzte Artikel.

Was unterscheidet eine Factur-X-Rechnung von einer einfachen, per E-Mail versendeten PDF-Datei?

Die Verwechslung zwischen einer Standard-PDF-Datei und einer Factur-X-Datei ist die am weitesten verbreitete und kostspieligste. Eine gewöhnliche PDF-Datei, selbst wenn sie elektronisch signiert ist und über einen zuverlässigen Prüfpfad verfügt, ist keine Factur-X-Rechnung. Die beiden Dateien mögen beim Öffnen ähnlich aussehen, aber ihre technische Natur ist grundlegend verschieden.

Ein Standard-PDF ist ein Präsentationsdokument. Es enthält Grafiken, formatierten Text und gegebenenfalls eine digitale Signatur. Ohne OCR (optische Zeichenerkennung) oder manuelle Eingabe kann keine Software automatisch Rechnungsdaten daraus extrahieren. OCR birgt Fehlerrisiken, insbesondere bei Beträgen, Umsatzsteuer-Identifikationsnummern und Referenzen. Ein gescanntes PDF verstärkt diese Risiken.

Eine Factur-X-Datei ist ein PDF/A-3-Container, der eine strukturierte XML-Datei enthält. Die Daten liegen direkt in einem Format vor, das Software ohne visuelle Interpretation lesen kann. Buchhaltungssoftware kann die Rechnung importieren, die Summen prüfen, die Positionen mit den Bestellungen abgleichen und sie ohne menschliches Eingreifen im Hauptbuch erfassen.

Ab dem 1. September 2026 ist der Versand von PDF-Rechnungen per E-Mail für B2B-Transaktionen zwischen in Frankreich umsatzsteuerlich registrierten Unternehmen nicht mehr zulässig. Rechnungen müssen über eine zugelassene Plattform in einem der drei Kernformate (Factur-X, UBL oder CII) übermittelt werden. Der direkte E-Mail-Versand gilt nicht mehr als zulässige Methode zur Rechnungsstellung für diese Transaktionen, selbst wenn die angehängte Datei ein technisch gültiges Factur-X-Dokument ist.

Drei Unterschiede verdeutlichen die Diskrepanz zwischen einem Standard-PDF und einem Factur-X:

• Das klassische PDF ist nur für Menschen lesbar; Factur-X ist sowohl für Menschen als auch für Maschinen lesbar.
• Das klassische PDF kann ohne OCR nicht automatisch verarbeitet werden; Factur-X integriert sich direkt in Informationssysteme.
• Das klassische, per E-Mail versendete PDF wird ab September 2026 für inländische B2B-Geschäfte nicht mehr zulässig sein; das über eine zugelassene Plattform übermittelte Factur-X hingegen schon.

Wie man in der Praxis eine Factur-X-Rechnung erstellt und liest

Die Erstellung einer gültigen Factur-X-Datei ist kein manueller Vorgang. Das Zusammenstellen eines konformen PDF/A-3-Dokuments, das Generieren einer korrekt strukturierten CII-XML-Datei, die Überprüfung der Konsistenz der XMP-Metadaten und die Sicherstellung, dass die Summen den Schematron-Regeln entsprechen: Keiner dieser Schritte kann in einer Produktionsumgebung manuell durchgeführt werden. Abrechnungs- oder Verwaltungssoftware übernimmt diesen gesamten Prozess.

Für Kleinstunternehmen oder Freiberufler beschränkt sich der Prozess auf zwei Prüfungen: Gibt die Software ein anerkanntes Profil (EN 16931 oder EXTENDED) aus und ist sie vor Ablauf der Frist mit einer zugelassenen Plattform verbunden? Alles Weitere obliegt dem Softwareanbieter. Für Buchhalter ist der Umfang umfangreicher: Sie müssen Exporte, Gutschriften, Vorauszahlungen, Statusaktualisierungen und Archivierungsbedingungen prüfen. Für IT-Abteilungen oder Systemintegratoren beinhaltet das Projekt eine vollständige Zuordnung des internen Datenmodells zu den CII-Feldern des Zielprofils mit systematischer Validierung vor der Produktivsetzung.

Die Validierung einer Factur-X-Datei erfolgt in vier unabhängigen Schritten. Im ersten Schritt wird die Konformität des PDF/A-3-Containers geprüft. Im zweiten Schritt wird die Gültigkeit des XML-Codes anhand seines XSD-Schemas überprüft: Struktur, Datentypen und Kardinalitäten. Im dritten Schritt werden die Regeln der Schematron EN 16931 angewendet, die über 200 Geschäftsregeln umfassen. Diese decken die arithmetische Konsistenz von Summen, Bedingungen basierend auf der Umsatzsteuerkategorie und die Gültigkeit der verwendeten Codes ab. Im vierten Schritt werden zusätzliche französische Regeln angewendet. Eine Datei kann die ersten beiden Schritte bestehen, aber im dritten Schritt scheitern: Hier treten die meisten Ablehnungen im Produktivbetrieb auf.

Aus Sicht des Empfängers erfordert die Verarbeitung eines empfangenen Factur-X-Formulars das Extrahieren der im PDF eingebetteten Datei factur-x.xml und die anschließende Analyse ihres Inhalts zur Befüllung des Buchhaltungssystems. Zugelassene Plattformen führen diese Extraktion automatisch durch. Die mit einer Plattform verbundene Buchhaltungssoftware empfängt die strukturierten Daten direkt, ohne dass der Benutzer das PDF öffnen muss.

Häufige Fehler, die es zu vermeiden gilt

Unternehmen, die sich auf die Reform vorbereiten, begehen immer wieder dieselben Fehler. Wer diese Fehler im Voraus kennt, vermeidet kostspielige Ablehnungen und unnötige Zahlungsverzögerungen.

Der erste und häufigste Fehler ist die Annahme, ein signiertes oder gescanntes PDF reiche aus. Ein elektronisch signiertes PDF bleibt ein PDF: Es enthält kein strukturiertes XML, ist kein PDF/A-3-Container und wird von einer zugelassenen Plattform nicht als konforme elektronische Rechnung akzeptiert. Ein gescanntes PDF ist noch weniger konform: Es ist ein Bild ohne verwendbare strukturierte Daten. Die Signatur oder der Scan fügt nicht die XML-Ebene hinzu, die Factur-X ausmacht.

Der zweite Fehler besteht in der Wahl eines zu niedrigen Profils. Software, die Rechnungen mit dem Profil MINIMUM oder BASIC WL erstellt, erzeugt zwar technisch gültige Factur-X-konforme Dateien, diese reichen jedoch für den B2B-Austausch im Rahmen der Reform nicht aus. Der Empfänger kann die Rechnung aufgrund fehlender Detailzeilen nicht automatisch in seine Software integrieren, indem er nur die XML-Datei verwendet. Die Verwendung des EN-16931-Profils von Anfang an vermeidet eine spätere Migration.

Der dritte Fehler besteht darin, die technische Gültigkeit mit der Akzeptanz durch eine anerkannte Plattform zu verwechseln. Eine Datei kann die XSD-Validierung bestehen, aber die Schematron-Validierung nicht. Sie kann die EN 16931 erfüllen, aber aufgrund zusätzlicher französischer Vorschriften abgelehnt werden. Die Validierung muss alle vier Ebenen umfassen, nicht nur die Dateistruktur.

Der vierte Fehler besteht darin, die Qualität der Quelldaten zu vernachlässigen. Eine Factur-X-Datei ist nur so gut wie die darin enthaltenen Daten. Eine falsche SIREN-Nummer, eine fehlende Lieferadresse, ein fehlerhaft formatierter Währungscode oder eine Summe ohne Mehrwertsteuer, die nicht der Summe der Einzelposten entspricht, führen zur sofortigen Ablehnung. Die Einhaltung der Dateivorgaben beginnt in der Kunden- und Artikeldatenbank der Verwaltungssoftware, nicht im XML-Generator.

Der fünfte Fehler besteht in der Annahme, die Pflicht beziehe sich nur auf die Übermittlung. Ab dem 1. September 2026 ist der Empfang für alle umsatzsteuerpflichtigen Unternehmen unabhängig von ihrer Größe verpflichtend. Unternehmen, die bis zu diesem Datum nicht an eine zugelassene Plattform angeschlossen sind, riskieren Strafen, selbst wenn sie noch nicht zur Übermittlung verpflichtet sind.

Erstellen Sie Factur-X aus Ihrem Managementsystem

Das Factur-X-Format wird aus den vorhandenen Abrechnungsdaten Ihrer Buchhaltungssoftware generiert. Es handelt sich nicht um ein separat erstelltes Dokument, sondern um einen strukturierten Export der bereits in Ihrem System vorhandenen Daten. Daher hängt die Qualität der generierten Datei direkt von der Qualität Ihrer internen Daten ab.

Die Kundendatenbank ist der erste Prüfpunkt. Eine fehlende oder falsche SIREN-Nummer, eine unvollständige Rechnungsadresse oder eine falsch eingegebene innergemeinschaftliche Umsatzsteuer-Identifikationsnummer: Jeder dieser Mängel führt zur Ablehnung bei der Validierung oder bei der Übermittlung an die genehmigte Plattform. Dasselbe gilt für die Produktdatenbank: Ein Artikelcode, der nicht den offiziellen Codelisten entspricht, ein mit der angegebenen Kategorie nicht übereinstimmender Umsatzsteuersatz oder eine leere Beschreibung führen zu Schematron-Fehlern, die der Dateigenerator nicht selbstständig korrigieren kann.

Djaboo ist eine Managementlösung, die mit dem Factur-X-Format kompatibel und in die zertifizierte Super PDP-Plattform integriert ist. Die in Djaboo eingegebenen Abrechnungsdaten fließen direkt in die Erstellung der strukturierten Datei ein, wodurch die erneute Eingabe oder zusätzliche manuelle Schritte entfallen. Die Kette von der Rechnungserstellung in der Benutzeroberfläche bis zur Übertragung an die zertifizierte Plattform ist nahtlos.