E-Rechnungsformate im Vergleich: UBL, XRechnung, FatturaPA und Facturae.

MINIMUM und BASIC WL sind Profile mit reduziertem Datenumfang, ursprünglich getrieben von französischen Anforderungen (Chorus Pro) und als Buchungshilfen oder Übergangsformate gedacht. Sie erfüllen die deutschen Rechnungsanforderungen nicht und sollten dort nicht verwendet werden. Für B2B ist EN 16931 (COMFORT) der praktische Standard; B2G in Deutschland erfordert das Profil XRECHNUNG oder eine native XRechnung.

Was ist FatturaPA, und warum verwendet es nicht die EN-16931-Syntax?

FatturaPA ist Italiens eigenes XML-Schema für die elektronische Rechnungsstellung, das EN 16931 vorausgeht, und es ist das Format, das das Sistema di Interscambio (SDI) für inländische Rechnungen verlangt. UBL- und CII-Dateien sind für inländische Transaktionen kein gültiger Ersatz. Grenzüberschreitende Lieferanten, die italienischen öffentlichen Stellen Rechnungen stellen, können stattdessen CIUS-IT („FatturaEU") verwenden, ein EN-16931-konformes Profil, das das SDI auf das nationale Schema abbildet. Jede FatturaPA-Datei hat ein einziges Wurzelelement, <FatturaElettronica>, das in einen FatturaElettronicaHeader (Routing- und Parteidaten) und einen oder mehrere FatturaElettronicaBody-Abschnitte (Rechnungspositionen, Summen, Zahlungsbedingungen) aufgeteilt ist. Das Schema wird von der Agenzia delle Entrate unter fatturapa.gov.it gepflegt und regelmäßig aktualisiert.

Einige strukturelle Details heben FatturaPA von UBL- oder CII-basierten Formaten ab:

• Rechnungen an öffentliche Stellen müssen eine digitale Signatur tragen (CAdES (.p7m) oder XAdES); für B2B- und B2C-Transaktionen ist die Signatur optional, wird aber weiterhin empfohlen.
• Das Routing hängt von einem CodiceDestinatario (einem beim SDI registrierten, siebenstelligen Empfängercode) oder einer zertifizierten PEC-E-Mail-Adresse ab, wenn kein Code registriert ist.
• Das Feld TipoDocumento klassifiziert den Transaktionstyp. TD01 kennzeichnet eine Standardrechnung, TD04 eine Gutschrift und so weiter: ein Klassifizierungskonzept ohne direkte Entsprechung in gleicher Form in UBL oder CII.
• Die Dateibenennung folgt einem festen Muster: dem VAT-vorangestellten Ländercode des Absenders, der USt-IdNr. und einer fortlaufenden Nummer (zum Beispiel IT01234567890_00001.xml).

Da FatturaPA außerhalb der EN-16931-Familie steht, benötigt jedes Unternehmen, das UBL- oder CII-Rechnungen für andere EU-Märkte erzeugt, einen separaten Konvertierungspfad speziell für italienische Geschäftspartner.

Was ist Facturae, und wie unterscheidet es sich von FatturaPA?

Facturae ist Spaniens nationales XML-Schema, das seit 2015 über die Plattform FACe für die B2G-Rechnungsstellung genutzt wird, und es baut, wie FatturaPA, nicht auf der UBL- oder CII-Syntax auf. Die aktuelle Schemaversion ist 3.2.2 (die FACe-Plattform verlangt mindestens 3.2.1). Eine gültige Facturae-Datei folgt vier Hauptblöcken in fester Reihenfolge: dem Dateikopf (mit den Feldern SchemaVersion, Modality und InvoiceIssuerType), dem Parteienblock, den Rechnungs- oder Stapeldetails und den Rechnungssummen. Eine Umsortierung dieser Blöcke löst ein sofortiges Validierungsversagen aus. Das XSD-Schema von Facturae erzwingt sowohl die Feldreihenfolge als auch die Datentypen strikt.

Spaniens bevorstehendes B2B-E-Rechnungsmandat unter dem Gesetz Crea y Crece schafft Facturae nicht ab. Es fügt UBL, CII und EDIFACT als akzeptierte Formate zwischen privaten Plattformen hinzu, verlangt aber weiterhin eine „originalgetreue Kopie" jeder Rechnung im UBL-Format, die die öffentliche Plattform der AEAT erreichen muss. Das macht Spanien zu einem der wenigen EU-Märkte, in denen ein bestehendes nationales Schema und die EN-16931-Syntaxen beide ausdrücklich nebeneinander akzeptiert werden, anstatt dass eines das andere ersetzt.

Wichtigste Erkenntnisse

• Deutschland und Frankreich teilen dieselbe Formatfamilie. Die EN-16931-basierten Formate XRechnung und Factur-X decken beide Märkte ohne separates nationales Schema ab.
• Italien und Spanien brauchen eine eigene Schemalogik. Eine generische UBL-/CII-Pipeline erzeugt keine gültige FatturaPA- oder Facturae-Datei; beide erfordern eine speziell dafür gebaute Erzeugung und Validierung.
• EN 16931 (COMFORT) ist das sichere Standardprofil für Factur-X/ZUGFeRD. MINIMUM und BASIC WL tragen für den deutschen Inlandsgebrauch nicht genügend Daten und sollten nicht als mit COMFORT austauschbar behandelt werden.
• Die Verbreitung von Peppol als Transportschicht wächst, doch es beseitigt nicht die Notwendigkeit, FatturaPA oder Facturae für Märkte zu erzeugen, die UBL nicht direkt akzeptieren.
• Ein Rollout über vier oder fünf Märkte benötigt in der Regel mindestens drei eigenständige XML-Pipelines: eine UBL-/CII-basierte, eine FatturaPA- und eine Facturae-Pipeline, erzeugt aus denselben zugrunde liegenden Rechnungsdaten.

Wie verhalten sich diese Formate zu Peppol BIS Billing 3.0?

Peppol BIS Billing 3.0 ist kein separates Rechnungsformat. Es ist eine CIUS, die UBL 2.1 für den Austausch über das Peppol-Netzwerk einschränkt. Es nimmt das breite, größtenteils optionale UBL-2.1-Schema und macht bestimmte Felder verpflichtend (etwa den rechtlichen Namen, die Adresse und die Peppol-Endpoint-ID beider Handelsparteien), sodass zwei beliebige Unternehmen im Peppol-Netzwerk Rechnungen austauschen können, ohne sich vorab bilateral darauf zu einigen, welche optionalen Felder zu verwenden sind. Wie dieser Austausch zwischen den beiden Parteien tatsächlich geroutet wird – über Access Points und das Vier-Ecken-Modell – ist ein eigenes Thema; ein separater fiskaly-Leitfaden zum Peppol-Netzwerk behandelt diesen Mechanismus ausführlich.

Deshalb können eine UBL-basierte XRechnung und eine Peppol-BIS-Billing-3.0-Rechnung auf XML-Ebene nahezu identisch aussehen. Beide sind EN-16931-konforme CIUS-Profile desselben UBL-Basisschemas, mit unterschiedlichen Regeln für Pflichtfelder darüber. FatturaPA und Facturae stehen vollständig außerhalb dieser Beziehung, da keines von beiden ein UBL- oder CII-Derivat ist.

Wie Sie entscheiden, welche(s) Format(e) Sie unterstützen

1. Listen Sie jedes Land auf, aus dem Sie Rechnungen stellen, und jedes Land, dem Sie Rechnungen stellen. Die Formatakzeptanz wird auf Länderebene festgelegt, und ein in einem Markt gültiges Format kann in einem anderen wertlos sein.
2. Prüfen Sie, ob das Land EN-16931-Formate akzeptiert oder ein proprietäres Schema verlangt. Deutschland und Frankreich akzeptieren EN-16931-basierte Dateien. Italien verlangt speziell FatturaPA, und Spanien verlangt je nach Ablauf Facturae oder eine „originalgetreue Kopie" in UBL.
3. Entscheiden Sie sich zwischen einem reinen XML-Format und einem hybriden Format, wo Sie die Wahl haben. Die XRechnung (reines XML) eignet sich für die vollständig automatisierte Back-Office-Verarbeitung; Factur-X/ZUGFeRD eignet sich für gemischte Umgebungen, in denen ein Mensch die Rechnung manchmal noch öffnen und lesen muss.
4. Wählen Sie das richtige Profil, wenn Sie Factur-X/ZUGFeRD erzeugen. EN 16931 (COMFORT) deckt die meisten B2G- und Standard-B2B-Anforderungen ab. Wechseln Sie nur dann zu EXTENDED, wenn Ihre Branche die zusätzlichen Handelsdaten tatsächlich erfordert.
5. Bestätigen Sie den Übertragungsweg getrennt vom Format. Eine korrekt erstellte XRechnung muss dennoch über Peppol oder eine Plattform wie OZG-RE laufen; eine korrekt erstellte FatturaPA-Datei muss dennoch über das SDI laufen.
6. Bauen Sie eine Konvertierungslogik, sobald Sie mehr als zwei Formate unterstützen. Unternehmen, die gleichzeitig in Deutschland, Frankreich, Italien und Spanien tätig sind, müssen in der Regel mindestens drei strukturell unterschiedliche XML-Ausgaben (UBL-/CII-basiert, FatturaPA und Facturae) aus denselben zugrunde liegenden Rechnungsdaten erzeugen.

Fazit

Jedes wichtige EU-E-Rechnungsformat fällt in eine von zwei Familien: EN-16931-basierte Formate, die auf UBL- oder CII-Syntax aufbauen (XRechnung, Factur-X/ZUGFeRD, Peppol BIS Billing 3.0), und ältere nationale Schemata, die dem europäischen Standard vorausgehen (FatturaPA, Facturae). Zu wissen, welcher Familie ein Markt angehört und welches spezifische Profil oder welche Schemaversion er erwartet, ist wichtiger, als die allgemeine E-Rechnungsrichtung der EU zu kennen. Die Datei, die Ihre Software erzeugt, muss exakt dem entsprechen, was die Plattform des empfangenden Landes validiert.

Die länderweise aufgeschlüsselten Fristen und den Mandatsstatus hinter diesen Formaten finden Sie in fiskalys Leitfaden zu Europas E-Rechnungsmandaten. Für Formaterzeugung, Validierung und Peppol-Anbindung über mehrere Märkte hinweg aus einer einzigen Integration siehe fiskaly E-INVOICE.