ZUGFeRD, XRechnung oder UBL: Welches Format brauche ich für E-Rechnungen?

Von Jan Hagemeister · Veröffentlicht am 24. September 2026

Ein Kunde möchte ZUGFeRD, der nächste eine XRechnung, ein dritter erwartet UBL über Peppol. Muss die eigene Software jetzt drei völlig unterschiedliche Rechnungen erzeugen?

Nicht unbedingt. Die Verwirrung beginnt häufig schon bei den Begriffen: ZUGFeRD, Factur-X, XRechnung, EN 16931, CII, UBL und Peppol werden oft nebeneinander genannt, als seien sie austauschbare Alternativen. Tatsächlich beschreiben sie unterschiedliche Dinge: Rechnungsinhalte, XML-Strukturen, zusätzliche Anforderungen, Dateicontainer oder Übertragungswege.

Für die Entwicklung einer eigenen E-Rechnungslösung ist diese Unterscheidung entscheidend. Das gilt auch für FileMaker: Wer sein Datenmodell von Anfang an auf ein einziges Ausgabeformat zuschneidet, stößt bei der nächsten Kundenanforderung schnell an Grenzen.

Warum die Formatfrage jetzt wichtig ist

Die E-Rechnung ist im deutschen B2B-Bereich keine rein freiwillige Angelegenheit mehr. Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können. Für die Ausstellung gelten Übergangsfristen: Ab 2027 greift die Pflicht für Unternehmen mit einem Vorjahresumsatz von mehr als 800.000 Euro, ab 2028 grundsätzlich auch für die übrigen Unternehmen.

Für jede Software, die Rechnungen erzeugt, stellt sich damit dieselbe Frage: Welche Formate muss sie tatsächlich unterstützen? Vor der technischen Umsetzung lohnt sich deshalb auch der Blick auf die typischen fachlichen Stolpersteine in gewachsenen FileMaker-Datenbanken.

EN 16931: Erst der Inhalt, dann das Dateiformat

Die europäische Norm EN 16931 ist das gemeinsame Fundament. Sie legt zunächst kein Dateiformat fest, sondern ein semantisches Datenmodell: Welche Informationen gehören zu einer Rechnung? Welche sind verpflichtend? Wie hängen sie zusammen, und welche Geschäftsregeln gelten?

Die einzelnen Informationen haben eindeutige Kennungen. Die Rechnungsnummer ist BT-1, das Rechnungsdatum BT-2, der Rechnungstyp BT-3. Rechnungspositionen sind in der Gruppe BG-25 zusammengefasst. Diese Business Terms und Business Groups bilden die gemeinsame fachliche Sprache.

Erst danach kommt die technische Darstellung in XML. Dafür sind zwei Syntaxen vorgesehen: UN/CEFACT Cross Industry Invoice (CII) und OASIS Universal Business Language (UBL).

Einfach gesagt: Die Semantik beschreibt, was eine Information bedeutet. Die Syntax beschreibt, wie sie in der XML-Datei steht. Diese Trennung erklärt einen großen Teil der vermeintlichen Formatvielfalt.

ZUGFeRD und Factur-X: PDF und XML in einer Datei

ZUGFeRD beziehungsweise Factur-X ist ein hybrides Rechnungsformat. Es verbindet ein lesbares PDF mit strukturierten Rechnungsdaten: Die XML-Datei wird in ein PDF/A-3-Dokument eingebettet.

Der Empfänger bekommt damit beides. Er kann die Rechnung wie gewohnt öffnen, lesen oder ausdrucken. Seine Buchhaltungssoftware kann gleichzeitig die eingebetteten Daten verarbeiten.

ZUGFeRD wird vom Forum elektronische Rechnung Deutschland, kurz FeRD, herausgegeben. Factur-X ist das französische Pendant. Seit ZUGFeRD 2.1 sind beide Formate technisch identisch. Als XML-Syntax verwenden sie CII.

Nicht jedes Profil enthält gleich viele Daten

ZUGFeRD kennt mehrere Profile mit unterschiedlichem Informationsumfang:

Für die E-Rechnungspflicht ist die Profilwahl wichtig. MINIMUM und BASIC WL erfüllen nach Auffassung der Finanzverwaltung nicht die Anforderungen an eine E-Rechnung, weil die erforderlichen Angaben nicht vollständig strukturiert enthalten sind. Für eine umfassende Implementierung empfiehlt sich mindestens das Profil EN 16931.

Zwei Darstellungen – aber nur eine Datenbasis

Der Komfort des hybriden Formats bringt eine zusätzliche Verantwortung mit sich: PDF und XML dürfen sich nicht widersprechen.

Deshalb sollten PDF und XML nicht unabhängig voneinander entstehen. Für eine FileMaker-Lösung bedeutet das: Drucklayout und XML-Ausgabe greifen auf dieselben Felder und Berechnungen zu. Summen, Steuern und Rundungen werden einmal berechnet und zweimal ausgegeben – nicht auf zwei unterschiedlichen Wegen neu ermittelt.

Auch die Verpackung muss stimmen. Das Trägerdokument muss gültiges PDF/A-3 sein; die XML-Datei benötigt den richtigen Dateinamen und die passenden XMP-Metadaten. Ein PDF mit einer irgendwie angehängten XML-Datei ist noch keine korrekt erzeugte ZUGFeRD-Rechnung. Die Praxisanleitung E-Rechnungen in FileMaker erstellen zeigt den vollständigen Ablauf; der Vergleich Plugin, Open Source oder Webdienst hilft bei der Wahl des Integrationswegs.

XRechnung: Deutsche Anforderungen an strukturierte Rechnungen

Die XRechnung begegnet einem vor allem bei Rechnungen an öffentliche Auftraggeber in Deutschland, also im B2G-Bereich.

Anders als ZUGFeRD ist sie kein hybrides PDF-Format. Eine XRechnung ist eine XML-Rechnung nach einer deutschen Spezifikation auf Grundlage der EN 16931. Eine solche Konkretisierung heißt Core Invoice Usage Specification, kurz CIUS.

Die XRechnung schränkt die europäische Norm an einigen Stellen ein und ergänzt nationale Anforderungen. Dazu gehört bei Rechnungen an öffentliche Stellen die Leitweg-ID, die im Feld BT-10 zur Zuordnung der Rechnung verwendet wird.

Die Koordinierungsstelle für IT-Standards (KoSIT) veröffentlicht die XRechnung-Spezifikationen und die zugehörigen technischen Artefakte. Eine eigene „XRechnung-XSD“ gibt es nicht. UBL und CII haben ihre jeweiligen XML-Schemas. Die zusätzlichen Geschäftsregeln der EN 16931 und der XRechnung werden über Schematron geprüft.

Eine ZUGFeRD-Datei im Profil XRECHNUNG enthält einen entsprechenden CII-Datensatz, eingebettet in ein PDF. Ob ein Rechnungseingangsportal diese hybride Datei akzeptiert, ist allerdings eine eigene Frage. Im Zweifel ist die reine XML-Datei der sichere Weg.

Die Übermittlung erfolgt je nach Empfänger über die Rechnungseingangsplattformen des Bundes oder der Länder oder über Peppol.

UBL: Mehr als eine alternative XML-Schreibweise

Universal Business Language, kurz UBL, wird von OASIS gepflegt. UBL ist nicht nur für Rechnungen gedacht, sondern beschreibt eine ganze Familie elektronischer Geschäftsdokumente – darunter Bestellungen, Lieferavise und Kataloge.

Für E-Rechnungen sind vor allem zwei Dokumenttypen wichtig: Invoice und CreditNote. Gerade hier liegt ein Unterschied zu CII, der bei der Implementierung leicht unterschätzt wird.

Eine Gutschrift ist in UBL ein eigener Dokumenttyp

Bei CII bleibt die Grundstruktur des Dokuments gleich. Die Rechnungsart wird über einen Typcode unterschieden: beispielsweise 380 für eine Rechnung, 381 für eine Gutschrift und 384 für eine Korrekturrechnung. Warum dabei bereits die fachliche Bezeichnung entscheidend ist, erläutert der Beitrag Gutschrift oder Rechnungskorrektur.

UBL verwendet für Rechnung und Gutschrift dagegen unterschiedliche Dokumentstrukturen:

Auch die Namespaces und die zugehörigen XML-Schemas unterscheiden sich.

Weitere Unterschiede betreffen etwa die Verschachtelung von Adressen und Parteien, die Darstellung von Zu- und Abschlägen und die Gruppierung der Steueraufschlüsselung.

Die gemeinsame EN-16931-Semantik hilft beim Mapping. Sie macht die XML-Strukturen aber nicht identisch. Eine fachlich gleiche Information kann in beiden Syntaxen sehr unterschiedlich aufgebaut sein. Deshalb sollten UBL und CII direkt aus den Geschäftsdaten entstehen, statt eine Syntax nachträglich in die andere zu konvertieren.

Peppol: Übertragungsnetzwerk und Dokumentregeln

International gewinnt UBL insbesondere durch Peppol an Bedeutung.

Peppol wird häufig nur als Übertragungsweg beschrieben: Geschäftsdokumente werden über ein Netzwerk zertifizierter Access Points ausgetauscht. Das stimmt, ist aber nicht die ganze Geschichte. Die Peppol Business Interoperability Specifications (BIS) legen zusätzlich fest, welche Anforderungen die ausgetauschten Dokumente erfüllen müssen.

Für Rechnungen verwendet Peppol BIS Billing 3.0 die Syntax UBL 2.1, mit getrennten Schemas für Invoice und CreditNote. Auch PINT-EU, die europäische Peppol-Spezifikation, basiert auf diesem Modell und unterscheidet die Transaktionen für Rechnung und Gutschrift.

In Deutschland ist Peppol besonders im B2G-Bereich etabliert und gewinnt auch im B2B-Austausch an Bedeutung. In anderen europäischen Ländern ist es teilweise bereits ein zentraler Kanal für E-Rechnungen.

Für die Softwareplanung bedeutet das: UBL sollte nicht erst dann auf die Aufgabenliste kommen, wenn der erste internationale Kunde danach fragt. Auch eine Lösung, die heute vor allem ZUGFeRD ausgibt, sollte diese Erweiterung im Datenmodell berücksichtigen.

Die Begriffe auf einen Blick

Viele Missverständnisse verschwinden, sobald man die Begriffe der richtigen Ebene zuordnet:

Deshalb ist „ZUGFeRD oder UBL?“ technisch keine ganz saubere Gegenüberstellung. ZUGFeRD beschreibt das hybride Format mit CII-Daten, UBL eine XML-Syntax. Entscheidend ist, welche Kombination der jeweilige Empfänger benötigt.

Validierung: Erzeugt ist noch nicht gültig

Eine E-Rechnung ist nicht schon deshalb gültig, weil sich die XML-Datei öffnen lässt oder die PDF-Darstellung plausibel aussieht. Warum Erzeugung und Validierung zwei verschiedene Schritte sind, zeigt sich an den mehreren Prüfebenen:

1. XML-Schema (XSD): Ist die XML-Struktur korrekt aufgebaut?
2. Geschäftsregeln der EN 16931: Sind Pflichtangaben vorhanden und beispielsweise Summen konsistent?
3. Zusätzliche Regeln der Spezifikation: Sind die Anforderungen der XRechnung oder von Peppol erfüllt?
4. PDF/A-3-Konformität: Ist bei ZUGFeRD auch das Trägerdokument korrekt?

Die Geschäftsregeln der zweiten und dritten Ebene werden über Schematron geprüft. Für die XRechnung stellt die KoSIT einen frei verfügbaren Validator mit passender Konfiguration bereit. Für ZUGFeRD gibt es unter anderem das Open-Source-Projekt Mustang; für die PDF/A-Prüfung veraPDF.

Welche Formate sollte meine Software unterstützen?

Das Einsatzgebiet gibt die Richtung vor.

ZUGFeRD / Factur-X bietet sich für den klassischen B2B-Austausch an, wenn neben strukturierten Daten weiterhin ein unmittelbar lesbares PDF gewünscht ist. Für eine umfassende Umsetzung empfiehlt sich das Profil EN 16931 oder ein entsprechend weitergehendes Profil.

XRechnung ist besonders wichtig für deutsche öffentliche Auftraggeber. Dabei müssen die gewünschte Syntax und die Leitweg-ID des Empfängers berücksichtigt werden.

UBL wird vor allem dann wichtig, wenn internationale Prozesse oder der Rechnungsaustausch über Peppol hinzukommen. Rechnung und Gutschrift müssen dabei als unterschiedliche Dokumenttypen unterstützt werden.

Die Frage „Kann die Software XRechnung?“ greift deshalb zu kurz. Aussagekräftiger ist:

Welche Syntaxen, Profile und Übertragungswege unterstützt sie – und in welcher Kombination?

Für FileMaker und andere Lösungen: Datenmodell zuerst

Eine nachhaltige E-Rechnungsimplementierung beginnt nicht beim XML-Export, sondern bei den Rechnungsdaten. Auch das XML selbst sollte nicht über verteilte Stringverkettungen entstehen; der Beitrag Warum E-Rechnungs-XML nicht mit Textfunktionen gebaut werden sollte erläutert die technischen Gründe.

Das semantische Modell der EN 16931 ist dafür eine gute Grundlage. Verkäufer und Käufer, Positionen, Steueraufschlüsselungen, Zahlungsinformationen und Referenzen sollten fachlich sauber abgebildet werden – zunächst unabhängig davon, ob später CII oder UBL ausgegeben wird. Selbst Details wie Skonto brauchen dabei eine bewusst gewählte Abbildung.

Aus dieser gemeinsamen Datenbasis entstehen die jeweiligen Ausgaben: CII für ZUGFeRD und XRechnung in CII-Syntax, UBL Invoice oder UBL CreditNote für die entsprechenden UBL-Ausgaben sowie das PDF-Layout für die lesbare Darstellung.

Die formatspezifische Logik gehört in die Ausgabeschicht. Ob eine Gutschrift als UBL-CreditNote oder als CII-Dokument mit Typcode 381 geschrieben wird, darf nicht die Struktur der gesamten Rechnungsdatenbank bestimmen.

Der Vorteil zeigt sich bei der nächsten Kundenanforderung. Wird statt ZUGFeRD per E-Mail plötzlich UBL über Peppol benötigt, kommt eine weitere Ausgabe hinzu – statt die Rechnungslogik vollständig neu aufzubauen. Ändert sich eine Spezifikation, lässt sich die Anpassung an der dafür vorgesehenen Stelle vornehmen.

Fazit: Der Empfänger bestimmt die Ausgabe

Es gibt nicht das eine E-Rechnungsformat für jeden Anwendungsfall. ZUGFeRD, XRechnung, CII, UBL und Peppol übernehmen unterschiedliche Aufgaben und lassen sich nicht sinnvoll auf eine einzige Entweder-oder-Frage reduzieren.

Wer diese Ebenen trennt, kann seine Software flexibler aufbauen: mit einer gemeinsamen fachlichen Datenbasis, passenden Ausgaben und einer festen Validierung.