ZUGFeRD vs. XRechnung: Welches Format passt zu welchem Empfänger?

ZUGFeRD vs. XRechnung im Direktvergleich

So funktioniert ZUGFeRD

ZUGFeRD ist ein hybrides Rechnungsformat. Nach der offiziellen Beschreibung des Forums elektronische Rechnung Deutschland werden strukturierte Rechnungsdaten im XML-Format in ein PDF/A-3-Dokument eingebettet. Das PDF ist die sichtbare Komponente, die XML-Datei kann automatisiert verarbeitet werden.

• Der Mensch öffnet die PDF-Sicht wie ein gewohntes Rechnungsdokument.
• Die Buchhaltungssoftware liest die eingebettete XML-Struktur.
• PDF und XML gehören zu derselben Rechnung und müssen inhaltlich übereinstimmen.
• Das verwendete Profil muss die benötigten Rechnungsdaten abbilden.

So funktioniert XRechnung

XRechnung konkretisiert die europäische Norm EN 16931 für deutsche Anforderungen. Die Rechnung besteht aus strukturierten XML-Daten. Die offiziellen XStandards Einkauf stellen Spezifikation, Testszenarien, UBL- und CII-Beispiele sowie Validator-Komponenten bereit.

Eine XRechnung ist für Programme gut auswertbar, aber als Roh-XML für Menschen unhandlich. Zur visuellen Kontrolle wird sie deshalb mit einer geeigneten Darstellung geöffnet. Eine zusätzlich verschickte PDF-Kopie ersetzt die strukturierte XRechnung nicht und sollte keine abweichenden Beträge oder Angaben enthalten.

XRechnung und Behörden

Bei einer Rechnung an einen öffentlichen Auftraggeber kommen neben dem Format weitere Vorgaben hinzu: etwa Leitweg-ID beziehungsweise Buyer Reference, Routingdaten, zugelassener Übertragungskanal und Größen- oder Anlagenregeln. Diese Daten teilt der jeweilige Auftraggeber mit. Nicht jede Behörde und jedes Bundesland nutzt exakt denselben Einreichungsweg.

Sind ZUGFeRD und XRechnung rechtlich gleichwertig?

Für die umsatzsteuerliche E-Rechnung kommt es auf ein strukturiertes elektronisches Format an, das die elektronische Verarbeitung ermöglicht. Das aktuelle BMF-FAQ zur E-Rechnung nennt XRechnung und ZUGFeRD ab Version 2.0.1 – mit Ausnahme von MINIMUM und BASIC-WL – als in Deutschland übliche Formate, die die Voraussetzungen grundsätzlich erfüllen.

„Gleichwertig“ bedeutet dabei nicht, dass jeder Empfänger jedes Format und jeden Kanal akzeptieren muss. Vertragliche Vorgaben, B2G-Portale und technische Empfangsprozesse können die Auswahl einschränken. Außerdem bleibt eine formal valide XML-Datei inhaltlich falsch, wenn beispielsweise Steuerfall, Leistungsdatum oder Betrag nicht stimmen.

Die allgemeinen Fristen und Übergangsregeln der deutschen B2B-E-Rechnung behandelt der separate Pillar E-Rechnung-Pflicht. Dieser Vergleich bleibt bewusst bei der Formatentscheidung.

XRechnung oder ZUGFeRD: eine praktische Entscheidungshilfe

1. Empfänger fragenKläre zuerst, welches Format und welchen Übertragungskanal der Empfänger akzeptiert oder verlangt.
2. B2G-Vorgaben lesenBei Behörden Leitweg-ID, Portal, Syntax und weitere Pflichtfelder aus Auftrag oder Bestellunterlagen übernehmen.
3. B2B-Prozess betrachtenKann der Kunde XML importieren und möchte er zusätzlich eine direkt lesbare Sicht? Dann kann ZUGFeRD passend sein.
4. Rechnungsdaten vervollständigenSteuerfall, elektronische Adresse, Zahlungsdaten und Referenzen vor der Erzeugung prüfen.
5. Datei validierenStrukturelle und fachliche Fehler vor der Übermittlung beheben.

Validierung prüft mehr als die Dateiendung

Eine technische Validierung kann Schema- und Geschäftsregeln prüfen, beispielsweise fehlende Pflichtfelder, ungültige Codes oder rechnerische Widersprüche. Das BMF empfiehlt eine Validierung bereits bei Erstellung und Versand, weist aber zugleich darauf hin, dass sie keine automatische steuerliche Anerkennung garantiert.

• Rechnungssumme entspricht Positionen, Zuschlägen, Nachlässen und Steuerbeträgen.
• Verkäufer- und Käuferdaten sind vollständig und richtig zugeordnet.
• Steuerkategorie und Steuersatz passen zum tatsächlichen Umsatz.
• Einheitencodes, Währung, Zahlungsdaten und Datumsfelder sind zulässig.
• Bei B2G sind Buyer Reference beziehungsweise Leitweg-ID und elektronische Adressen vorhanden.
• Bei ZUGFeRD stimmen sichtbare PDF- und strukturierte XML-Inhalte überein.

ZUGFeRD und XRechnung in Invoify auswählen

Invoify bietet für geeignete deutsche Rechnungen ZUGFeRD und XRechnung als auswählbare E-Rechnungsformate. Der Beleg wird aus denselben geprüften Rechnungsdaten erzeugt; Format und erforderliche Empfängerreferenzen werden vor dem Fertigstellen festgelegt.

1. Rechnung erfassenKontakt, Positionen, Leistungsdatum, Steuerfall und Zahlungsdaten vollständig anlegen.
2. Empfängerprozess wählenZUGFeRD für den passenden hybriden Austausch oder XRechnung für den verlangten XML-Prozess auswählen.
3. B2G-Daten ergänzenBei Behörden die mitgeteilte Leitweg-ID und weitere elektronische Adressdaten eintragen.
4. Validierung beachtenGemeldete Struktur- oder Inhaltsfehler vor dem Fertigstellen korrigieren.
5. Original übermittelnDie erzeugte E-Rechnung über den mit dem Empfänger abgestimmten Kanal versenden und unverändert aufbewahren.

Für Aufbau und Pflichtangaben einer normalen Ausgangsrechnung führt der Ratgeber Rechnung schreiben durch den vollständigen Workflow.

Formatvergleich statt Erstellanleitung: aktualisierte Owner-Grenzen 2026

Der Owner bleibt der direkte Formatvergleich und ordnet PDF/A-3 mit eingebettetem XML gegenüber einer reinen strukturierten XML-Rechnung ein. Diese Seite bleibt der kanonische Owner für die Auswahl zwischen ZUGFeRD und XRechnung. Sie fasst angrenzende Fragen nur so weit zusammen, wie es für die Auswahl nötig ist. Die eigentliche Anleitung, Berechnung oder Vorlage liegt jeweils auf der verlinkten Vertiefung.

Pflichtfristen, Leitweg-ID, Validierung und Archivierung sind eigenständige Entscheidungen und werden nur verlinkt. Die Grenze verhindert, dass ähnliche Begriffe zu austauschbaren Seiten werden. Ändern sich im Jahr 2027 einzelne Fristen, Beträge oder Produktdetails, wird der bestehende Owner mit Prüfdatum aktualisiert; es entsteht keine nahezu identische Jahreskopie.

Entscheidungs- und Freigabeablauf

1. Ausgangsfall bestimmenDokumentiere zuerst den konkreten Vorgang, bevor der Überblick „die Auswahl zwischen ZUGFeRD und XRechnung“ auf einen Detailfall angewendet wird.
2. Owner auswählenNutze die Entscheidungsmatrix und wechsle für Spezialfragen auf den verlinkten Detail-Owner.
3. Daten und Nachweis prüfenHalte Eingaben, Quelle, Ergebnis und verantwortliche Freigabe gemeinsam fest.
4. Ergebnis kontrollierenPrüfe vor Abschluss, ob Überblick, Detailentscheidung und Produktprozess dieselbe Aussage transportieren.

Für die Umsetzung werden Ausgangsdaten, gewählter Owner, fachliche Entscheidung und Nachweis am Vorgang zusammengehalten. Ein Link ist dabei nicht nur Navigation: Er markiert, welche Seite die Detailantwort verantwortet. Wer später aktualisiert, erkennt dadurch, ob eine Änderung in diesem Überblick oder im spezialisierten Child vorgenommen werden muss.

Bei Ausnahmen wird kein plausibel klingender Standard eingesetzt. Stattdessen erhält der offene Punkt eine verantwortliche Person, eine konkrete Rückfrage und einen nächsten Prüftermin. Wiederkehrende Standardfälle dürfen erst automatisiert werden, nachdem Eingaben und Ergebnis anhand eines realen Beispiels kontrolliert wurden.

Produktgrenze und Review

Invoify erzeugt aus freigegebenen Rechnungsdaten ZUGFeRD oder XRechnung und validiert die technische Ausgabe. Empfängerkanal und fachliche Annahme bleiben außerhalb der Formatdatei.

Produktclaims wurden am 31. Juli 2026 gegen die aktuelle Invoify-Funktionsdokumentation geprüft. Fachliche Rechts-, Steuer- oder Bewertungsentscheidungen bleiben bei den verantwortlichen Personen beziehungsweise ihrer Beratung. Nächster turnusmäßiger Review: Januar 2027; frühere Prüfung bei Gesetzes-, Standard- oder Produktänderung.

Das E-Rechnungsformat nach Empfänger und Übertragungsweg wählen

Die Formatentscheidung beginnt beim Empfängerprozess. Eine Behörde kann XRechnung, eine bestimmte Profilstufe, eine Leitweg-ID und einen festgelegten Übertragungskanal verlangen. Ein privatwirtschaftlicher Kunde kann dagegen ZUGFeRD bevorzugen, weil PDF-Sichtbild und strukturierte Daten gemeinsam in einer Datei vorliegen. Entscheidend ist nicht, welches Format allgemein „besser“ aussieht, sondern welches der Empfänger technisch annehmen, validieren und verarbeiten kann.

Die Tabelle beschreibt typische Entscheidungen, keine universelle Empfängervorgabe. Ein Unternehmen kann beide Formate akzeptieren, während ein konkretes Portal nur bestimmte Varianten zulässt. Auftrag, Lieferanteninformation und technische Dokumentation des Empfängers haben deshalb Vorrang vor einer allgemeinen Präferenz des Rechnungsstellers.

Für öffentliche Rechnungen ist die Käuferreferenz besonders wichtig. Die Leitweg-ID wird als fachlicher Wert in den strukturierten Daten übergeben und darf nicht nur optisch in einen PDF-Kopf geschrieben werden. Weitere Empfängerreferenzen wie Bestellnummer oder Lieferantennummer müssen ebenfalls in den vorgesehenen Feldern stehen, wenn der Prozess sie verlangt.

Strukturprüfung, Sichtprüfung und Geschäftsprüfung ergänzen sich

Eine syntaktisch gültige XML-Datei kann trotzdem fachlich falsch sein. Der Validator erkennt beispielsweise fehlende Pflichtfelder, ungültige Codewerte oder widersprüchliche Summen. Er weiß aber nicht automatisch, ob die gelieferte Leistung korrekt beschrieben, der richtige Kunde gewählt oder eine vereinbarte Bestellnummer verwendet wurde. Deshalb besteht die Freigabe aus mindestens drei Ebenen.

1. Belegdaten prüfenEmpfänger, Positionen, Leistungsdatum, Steuerfall, Zahlbetrag und Referenzen mit Auftrag und Leistung vergleichen.
2. Format validierenXML gegen Syntax, Schema und Geschäftsregeln des gewählten Standards prüfen.
3. Darstellung kontrollierenBei ZUGFeRD PDF und XML auf inhaltliche Übereinstimmung prüfen; bei XRechnung einen geeigneten Viewer verwenden.
4. Empfängerregeln prüfenPortalvorgaben, zulässige Version, Dateigröße und zusätzliche Referenzen berücksichtigen.
5. Ergebnis dokumentierenErzeugte Originaldatei, Prüfbericht und Versand- beziehungsweise Einreichungsnachweis gemeinsam ablegen.

Übereinstimmung von PDF und XML

Bei einem hybriden Format dürfen sichtbare und strukturierte Angaben nicht zwei verschiedene Rechnungen ergeben. Rechnungsnummer, Datum, Empfänger, Positionen, Steuergruppen und Gesamtbetrag sollten aus derselben Datenbasis erzeugt werden. Werden Werte nachträglich nur im PDF geändert, bleibt das eingebettete XML unberührt. Ein solcher Medienbruch kann die automatische Verarbeitung und die menschliche Prüfung zu unterschiedlichen Ergebnissen führen.

ZUGFeRD und XRechnung kontrolliert in den Alltag einführen

Ein sinnvoller Rollout startet mit wenigen repräsentativen Empfängern. Dazu gehören eine einfache Inlandsrechnung, mehrere Steuersätze, Rabatt oder Skonto, eine Gutschrift beziehungsweise Korrektur und – soweit relevant – ein öffentlicher Auftraggeber. Jede Testdatei wird im Zielkanal geprüft, bevor der Prozess für alle Rechnungen freigegeben wird.

• Empfängeranforderungen und gewünschtes Format in den Kontaktdaten hinterlegen.
• Pflichtfelder und Referenzen bereits vor der Belegerstellung vollständig erfassen.
• Testrechnungen mit offiziellem oder empfängerakzeptiertem Validator prüfen.
• PDF, XML, Prüfbericht und Versandnachweis unverändert aufbewahren.
• Fehlercodes in verständliche Korrekturschritte übersetzen.
• Bei Versionswechseln einen erneuten Abnahmetest durchführen.

Invoify kann XRechnung und ZUGFeRD aus derselben Rechnungsdatenbasis erzeugen und technisch validieren. Die Auswahl des passenden Formats, der Empfangskanal und zusätzliche kundenspezifische Regeln bleiben pro Empfänger zu prüfen. Die allgemeinen gesetzlichen Übergangsfristen behandelt die Seite zur E-Rechnung-Pflicht; dieser Beitrag bleibt bei der Format- und Prozessentscheidung.

Validierungsfehler von der Meldung zur Ursache zurückverfolgen

Validatoren melden häufig Business Terms, Regelkennungen oder XML-Pfade. Für die Korrektur muss diese technische Meldung auf ein Eingabefeld und den zugrunde liegenden Geschäftsvorgang zurückgeführt werden. Ein fehlendes BT-10 betrifft beispielsweise die Käuferreferenz; eine Summenregel kann auf Rundung, Rabattverteilung oder Steuergruppen hinweisen.

Bearbeiten Sie nicht direkt die erzeugte XML-Datei, wenn sie aus einem Rechnungsprogramm stammt. Die Korrektur gehört in die Quelldaten, damit PDF, XML und spätere Exporte denselben Stand verwenden. Anschließend wird neu erzeugt und erneut validiert.

Speichern Sie bei wiederkehrenden Fehlern eine interne Erklärung: Nutzer benötigen nicht nur den Standardcode, sondern die Information, welches Feld im eigenen Prozess fehlt und wer es liefern kann. So wird Validierung zu einem reproduzierbaren Qualitätsprozess statt zu wiederholtem Ausprobieren.

Prüfen Sie außerdem die Dateibezeichnung und den MIME-Typ beim Versand. Ein technisch gültiges Dokument kann an einer Portalvorgabe oder einer blockierten Dateiendung scheitern. Der Versandnachweis sollte deshalb Dateiname, Formatversion und Ergebnis des Annahmekanals erkennen lassen.