Kurz beantwortet
Für Rechnungen an Geschäftskunden reicht ZUGFeRD 2.5 (PDF/A-3 mit eingebettetem XML nach EN 16931). Für öffentliche Auftraggeber ist XRechnung 3.0.2 als reines XML mit Leitweg-ID vorgeschrieben. Wer beides beliefert, braucht beide Formate — steuerbar über ein Format-Feld je Debitor, nicht über eine pauschale Systemumstellung.
Welches Format Sie brauchen
Für das normale Inlandsgeschäft mit Geschäftskunden: ZUGFeRD. Für Rechnungen an öffentliche Auftraggeber: XRechnung. Wer beides beliefert, braucht beides — und dann wird die eigentliche Frage nicht „welches Format“, sondern „wie schalte ich je Kunde um“.
Die Umschaltung je Kunde ist in einer NAV- oder BC-14-Installation der Punkt, an dem sich entscheidet, ob die Lösung im Betrieb funktioniert. Deshalb steht sie hier im Mittelpunkt und nicht der Formatvergleich.
Die gemeinsame Grundlage: EN 16931
Die Frage kommt in fast jedem Erstgespräch, und fast immer so gestellt, als müsse man sich für ein Lager entscheiden. Muss man nicht. Beide setzen die europäische EN 16931 um und beschreiben dieselben rund 150 semantischen Felder: Rechnungsnummer, Steuerbeträge, Zahlungsbedingungen, Positionsdaten. Der Unterschied fängt erst darunter an.
Der Unterschied liegt in zwei Dimensionen:
Syntax. Die Norm lässt zwei XML-Sprachen zu: UN/CEFACT CII und OASIS UBL. ZUGFeRD verwendet CII. XRechnung erlaubt beide, in der Praxis überwiegt UBL. Dieselbe Rechnung, zwei unterschiedliche XML-Bäume — der Grund, warum eine Umwandlung zwischen den Formaten Arbeit ist und kein Umschalten eines Schalters.
Verpackung. XRechnung ist eine reine XML-Datei. Sie öffnen sie, Sie sehen Quelltext. ZUGFeRD ist ein PDF/A-3, in das dieselben Daten als Anhang eingebettet sind. Der Empfänger sieht ein gewöhnliches PDF und kann es lesen, drucken, weiterleiten wie bisher; seine Software liest zusätzlich den Datensatz aus.
Wann Sie welches Format brauchen
ZUGFeRD im B2B. Der Grund dafür ist ein praktischer: Ihre Kunden sind unterschiedlich weit. Der eine hat eine Software, die den Datensatz automatisch einliest. Der andere druckt die Rechnung aus und heftet sie ab. ZUGFeRD bedient beide, weil das Ergebnis für Menschen lesbar bleibt. Eine XRechnung an einen Kunden, der keinen Viewer hat, erzeugt einen Anruf in Ihrer Buchhaltung, und zwar bei jeder Rechnung.
XRechnung im B2G. Öffentliche Auftraggeber verlangen sie, und sie verlangen zusätzlich die Leitweg-ID des Empfängers im Feld Käuferreferenz. Ohne diese ID wird die Rechnung im Eingangsportal des Auftraggebers abgewiesen, unabhängig davon, ob der Datensatz sonst korrekt ist. Die Leitweg-ID bekommen Sie vom Auftraggeber; sie gehört in die Debitorenstammdaten, nicht in ein Bemerkungsfeld.
Wenn der Kunde etwas vorgibt. Große Konzernkunden und Automotive-Zulieferketten schreiben mitunter ein Format oder einen Übertragungsweg vor. Diese Vorgaben gehen dem allgemeinen Fall vor — prüfen Sie Ihre Rahmenverträge, bevor Sie sich festlegen.
Profile: Nicht jedes ZUGFeRD ist eine E-Rechnung
ZUGFeRD kennt mehrere Profile mit unterschiedlichem Feldumfang. Das ist der am häufigsten übersehene Punkt, und er kostet Zeit, wenn er zu spät auffällt.
Nicht zulässig
MINIMUM / BASIC WL
Enthalten zu wenige Felder und gelten nach Auffassung der Finanzverwaltung nicht als E-Rechnung im Sinne des Gesetzes.
Eingeschränkt
BASIC
Grundsätzlich zulässig, deckt aber nur einfache Fälle ab.
Empfehlung
EN 16931
Früher COMFORT genannt — der vollständige Normumfang und die richtige Wahl für B2B-Interoperabilität.
Branchenspezifisch
EXTENDED
Geht über den Normumfang hinaus, etwa für Unterpositionen.
B2G-tauglich
XRECHNUNG
Erzeugt ein ZUGFeRD, das zugleich die deutschen XRechnung-Regeln erfüllt.
Wer eine Lösung einkauft oder baut, sollte sich das Profil schriftlich geben lassen. „Wir können ZUGFeRD“ ist keine Aussage.
Warum die Versionsnummer weniger aussagt, als man denkt
Die Versionsstände bewegen sich. Zum Zeitpunkt dieses Textes gilt XRechnung 3.0.2 als aktuelle Fassung, ZUGFeRD steht bei 2.5. Eine XRechnung 4.0 ist angekündigt, weil die zugrundeliegende Norm in einer neuen Fassung (EN 16931-1:2026) erscheint; ZUGFeRD zieht erfahrungsgemäß einige Monate später nach.
Für Sie ist daraus nur eines wichtig, und es ist eine Architekturfrage, keine Formatfrage:
Das Gesetz verlangt Konformität zur EN 16931 — kein bestimmtes Produkt und keine bestimmte Versionsnummer. Aber die Norm ändert sich, und mit ihr die Codelisten und Prüfregeln.
Eine Umsetzung, die die Feldzuordnung aus Ihren Belegdaten und die Erzeugung der konkreten XML-Syntax in einem Stück macht, muss bei jeder Normrevision komplett angefasst werden. Eine Umsetzung, die beides trennt — hier die semantische Zuordnung aus NAV, dort die Ausgabe in CII oder UBL —, überlebt die Revision mit einer angepassten Ausgabeschicht.
Das ist der Grund, warum wir den Datensatz aus den Belegdaten aufbauen und nicht aus dem Druckbild ableiten. Wer das Druckbild parst, baut die Abhängigkeit von der Norm direkt in den Rechnungsbericht ein — und darf sie zweimal bezahlen.
Was das für NAV 2013 bis BC 14 konkret bedeutet
In diesen Versionen liefert der Standard keines der beiden Formate. Was Sie brauchen, entsteht in vier Bausteinen:
1
Format je Kunde steuerbar
Ein Feld am Debitor entscheidet, was beim Buchen und Drucken erzeugt wird: ZUGFeRD, XRechnung oder gar nichts (Privatkunden, Auslandsgeschäft). Ohne dieses Feld müssen Ihre Mitarbeiter bei jeder Rechnung selbst entscheiden — und das geht schief.
2
Leitweg-ID als Stammdatum
Feld am Debitor, Pflichtprüfung beim Buchen, wenn dort XRechnung hinterlegt ist. Fehlt sie, soll das System vor dem Versand meckern und nicht das Portal des Auftraggebers.
3
Der Versandweg bleibt
Ob Ihre Rechnungen heute per E-Mail aus NAV gehen, über Ihr DMS oder über einen Dienstleister — der Weg ändert sich nicht, nur der Anhang ist ein anderer. Das ist der Teil, der in Projekten am wenigsten Aufwand macht und am meisten Sorgen bereitet.
4
Prüfung vor dem Versand
Eine Formatprüfung, die den erzeugten Datensatz gegen die Regeln der Norm hält, bevor er das Haus verlässt. Sie werden sie in der Einführungsphase brauchen und im Regelbetrieb kaum noch bemerken.
Ein Punkt, der oft zu spät kommt: die Archivierung
Bei ZUGFeRD ist die Originaldatei das PDF/A-3 mit dem eingebetteten XML. Ein Ausdruck ist kein Archiv, und ein PDF, aus dem beim Weiterverarbeiten der Anhang verlorengeht, auch nicht. Wenn Ihr Dokumentenmanagement die Ausgangsrechnung heute als PDF ablegt, prüfen Sie, ob es die Einbettung erhält. Bei den meisten gängigen DMS-Lösungen lässt sich das entsprechend konfigurieren, bei manchen älteren Konfigurationen fällt der Anhang beim Konvertieren heraus.
Dasselbe gilt für den Rechnungseingang, sobald Ihre Lieferanten umstellen — aber das ist ein eigenes Thema, weil Sie beim Empfang das Format nicht bestimmen.
Fazit
Die Formatfrage ist in den meisten Fällen schnell entschieden: ZUGFeRD für B2B, XRechnung zusätzlich für B2G. Entschieden ist die Formatfrage damit schnell. Die Arbeit liegt danach in der sauberen Zuordnung Ihrer Belegdaten auf die Normfelder: Steuerkategorien, Einheitencodes, Zahlungsdaten. Wie dieses Mapping in gewachsenen NAV-Installationen aussieht und wo es typischerweise klemmt, haben wir hier beschrieben: EN 16931 in NAV-Altsystemen sauber mappen.
Und wenn Sie wissen wollen, wie beide Formate ohne Versionswechsel aus Ihrer bestehenden Installation entstehen: ZUGFeRD und XRechnung aus NAV 2013 bis Business Central 14.
Stand: August 2026. Versionsangaben zu XRechnung und ZUGFeRD nach den Veröffentlichungen von KoSIT und FeRD; maßgeblich ist die jeweils geltende Fassung. Dieser Text ist keine Steuerberatung. Dynamics, Business Central und NAV sind Marken der Microsoft Corporation.
2 Comments