Der Begriff „hybrid” ist der Schlüssel zum Verständnis. Eine reine PDF-Rechnung ist für Empfangende angenehm, weil sie aussieht wie ein gewohntes Dokument – aber sie ist für ein Buchhaltungssystem nur ein Bild mit Text darin. Eine rein strukturierte Rechnung wiederum ist für Software ideal, für das menschliche Auge aber unübersichtlich. ZUGFeRD löst diesen Zielkonflikt, indem es beide Welten in eine Datei legt. Wer die Datei öffnet, sieht eine vertraute Rechnung. Wer sie maschinell einliest, findet den XML-Datensatz mit allen Feldern in normierter Form.
Drei Eigenschaften definieren ZUGFeRD im Kern:
Der hybride Ansatz hat einen praktischen Ursprung. Als die elektronische Rechnung in der Breite ankam, wollten viele Unternehmen nicht von heute auf morgen ihre gewohnten PDF-Rechnungen aufgeben. Gleichzeitig drängten Verwaltung und große Auftraggeber auf strukturierte Daten, die sich automatisch weiterverarbeiten lassen. ZUGFeRD wurde als Brücke konzipiert: Wer die eingebetteten Daten noch nicht nutzen kann, behandelt die Datei einfach wie eine PDF-Rechnung. Wer schon weiter ist, liest das XML aus und automatisiert die Buchung.
Diese Brückenfunktion erklärt, warum ZUGFeRD im Mittelstand so beliebt ist. Es zwingt niemanden zu einem Technologiesprung, sondern erlaubt einen schrittweisen Übergang. Eine Handwerksbetrieb-Buchhaltung kann die Datei zunächst wie gewohnt sichten und abheften, während die Software im Hintergrund bereits die strukturierten Felder mitliest. Mit wachsender Reife verschiebt sich der Schwerpunkt von der visuellen Sichtung hin zur maschinellen Verarbeitung.
ZUGFeRD ist über mehrere Versionen gewachsen. Die frühen Fassungen waren noch ein eigenständiger deutscher Ansatz. Mit den späteren Versionen wurde das Format eng an die europäische Norm EN 16931 angelehnt und mit dem französischen Factur-X harmonisiert. Heute teilen sich ZUGFeRD und Factur-X technisch denselben Kern – sie sind weitgehend das gleiche Format unter zwei Namen. Diese Annäherung an einen europäischen Standard ist der wichtigste Reifeschritt: Sie macht aus einem nationalen Behelf ein anschlussfähiges Werkzeug.
Technisch besteht jede ZUGFeRD-Datei aus zwei Bausteinen: dem PDF/A-3-Container und dem eingebetteten XML. Der Container ist immer gleich aufgebaut; die Profile beziehen sich auf den Inhalt und die Vollständigkeit des XML-Datensatzes. Ein Profil legt fest, welche Datenfelder mindestens vorhanden sein müssen und wie tief die Rechnung strukturell beschrieben wird.
Die Profilwahl ist keine technische Nebensache, sondern eine fachliche Entscheidung. Ein MINIMUM-Profil mag verlockend einfach sein, transportiert aber so wenig strukturierte Information, dass sich daraus keine vollständige automatische Buchung ableiten lässt. Wer ernsthaft automatisieren will, kommt an einem Profil auf dem Niveau von EN 16931 nicht vorbei. EXTENDED ist dann sinnvoll, wenn der Geschäftsvorfall Felder benötigt, die das Norm-Profil nicht abbildet.
Eine wichtige Faustregel aus der Praxis: Empfangende Systeme sollten möglichst alle Profile lesen können, sendende Systeme sollten ein hohes Profil erzeugen. Wer als Empfänger nur MINIMUM verarbeiten kann, verschenkt den eigentlichen Vorteil des Formats. Wer als Sender ein zu schlankes Profil wählt, zwingt seine Empfänger zur manuellen Nacherfassung.
ZUGFeRD und das französische Factur-X sind technisch eng verwandt – in den aktuellen Fassungen teilen sie denselben Datenkern und dieselbe Struktur. Praktisch bedeutet das: Eine korrekt erzeugte ZUGFeRD-Datei im Norm-Profil ist zugleich eine Factur-X-Datei und umgekehrt. Für den grenzüberschreitenden Rechnungsaustausch im DACH-Raum und nach Frankreich ist das ein erheblicher Vorteil, weil dieselbe technische Basis funktioniert. Die Profile tragen teils unterschiedliche Bezeichnungen, beschreiben aber vergleichbare Detailgrade.
Im Kern definiert die europäische Norm EN 16931 ein semantisches Datenmodell für elektronische Rechnungen – also welche Informationen eine Rechnung enthalten muss und wie sie strukturiert beschrieben werden. Eine elektronische Rechnung im engeren Sinn ist üblicherweise eine Rechnung, die in einem strukturierten Format ausgestellt, übermittelt und empfangen wird, das eine automatische und elektronische Verarbeitung ermöglicht. Genau hier entscheidet sich, ob eine bestimmte ZUGFeRD-Datei mitspielt.
Entscheidend ist der eingebettete strukturierte Datensatz, nicht das sichtbare PDF. Eine ZUGFeRD-Datei kann dann als strukturierte E-Rechnung im Sinne der Norm gelten, wenn ihr XML-Anteil die Anforderungen der EN 16931 erfüllt – also typischerweise ab dem Profil auf Norm-Niveau aufwärts. Die schlanken Profile, allen voran MINIMUM, transportieren bewusst nur einen reduzierten Datensatz und sind als reine Buchungshilfe gedacht; sie erfüllen die normierten Inhaltsanforderungen einer vollwertigen E-Rechnung in der Regel nicht.
Daraus folgt eine klare praktische Linie: Wer ZUGFeRD im Kontext einer E-Rechnungspflicht einsetzen möchte, sollte ein Profil wählen, das dem Datenumfang der EN 16931 entspricht. Das sichtbare PDF bleibt dabei eine bequeme Beigabe für das menschliche Auge, ist aber für die rechtliche Einordnung als strukturierte Rechnung nicht der maßgebliche Teil.
Rund um die Einführung verpflichtender E-Rechnungen gibt es im DACH-Raum gestaffelte Übergangsregelungen und Stichtage, die sich nach Unternehmensgröße, Rechnungsart und Empfängerkreis unterscheiden können. Solche Fristen ändern sich, werden präzisiert oder durch Übergangsregelungen abgefedert. Aus diesem Grund ist hier bewusst Zurückhaltung geboten: Konkrete Termine und deren Anwendbarkeit auf Ihren Fall sollten Sie stets anhand der aktuellen amtlichen Quellen und mit fachkundiger Begleitung prüfen.
Was sich sachlich festhalten lässt, ist die Richtung: Der Empfang strukturierter elektronischer Rechnungen wird in vielen Konstellationen zur Grundanforderung, während für den Versand häufig Übergangszeiträume gelten. Für Unternehmen heißt das vor allem eines: Die Fähigkeit, eingehende E-Rechnungen – auch ZUGFeRD-Dateien – zuverlässig anzunehmen und zu verarbeiten, sollte frühzeitig hergestellt werden.
Der zentrale Unterschied lässt sich in einem Satz fassen: ZUGFeRD ist eine PDF-Datei mit eingebettetem XML, XRechnung ist ein reiner XML-Datensatz ohne sichtbare PDF-Darstellung. Eine XRechnung sieht für das menschliche Auge zunächst wie nichts aus – es ist eine Datenstruktur, die erst durch ein Anzeigeprogramm oder einen Viewer lesbar wird. Beide Ansätze haben ihre Berechtigung.
Die Wahl zwischen ZUGFeRD und XRechnung ist selten eine reine Geschmacksfrage, sondern hängt vom Empfänger und vom Reifegrad der eigenen Prozesse ab. XRechnung ist im Verkehr mit öffentlichen Auftraggebern weit verbreitet und dort häufig das geforderte Format. ZUGFeRD spielt seine Stärken im allgemeinen Geschäftsverkehr aus, gerade wenn auf der Empfängerseite noch nicht alle Partner vollständig automatisiert verarbeiten.
Eine pragmatische Linie aus der Praxis: Wer überwiegend an öffentliche Stellen fakturiert, kommt an XRechnung oft nicht vorbei. Wer im breiten B2B-Umfeld unterwegs ist und gemischte Empfänger bedient, fährt mit ZUGFeRD häufig komfortabler, weil die sichtbare PDF-Schicht auch weniger weit fortgeschrittene Partner abholt. Viele Unternehmen entscheiden sich daher bewusst dafür, beide Formate erzeugen zu können – die zugrunde liegende Datenbasis ist ohnehin weitgehend dieselbe.
Trotz aller Unterschiede teilen ZUGFeRD und XRechnung dasselbe inhaltliche Fundament: die Semantik der EN 16931. Vereinfacht gesagt beschreiben beide dieselben Rechnungsfelder, nur die Verpackung unterscheidet sich. Das hat einen angenehmen Nebeneffekt: Wer seine Stammdaten und Rechnungslogik einmal sauber an der Norm ausgerichtet hat, kann mit überschaubarem Mehraufwand beide Formate bedienen. Die Entscheidung für ein Format ist damit weniger dramatisch, als sie zunächst wirkt.
Der Erstellungsprozess hat zwei Seiten, die zueinander passen müssen: das sichtbare PDF und das eingebettete XML. Beide Repräsentationen müssen denselben Geschäftsvorfall beschreiben. Weicht der ausgewiesene Betrag im PDF vom Betrag im XML ab, ist die Datei zwar technisch eine ZUGFeRD-Datei, fachlich aber widersprüchlich – und damit ein Risiko.
Validierung ist kein Luxus, sondern ein notwendiger Bestandteil eines belastbaren Prozesses. Eine sinnvolle Prüfung umfasst mehrere Ebenen: Ist das PDF tatsächlich ein gültiges PDF/A-3? Ist das eingebettete XML technisch wohlgeformt und schema-konform? Erfüllt der Datensatz die Regeln des angegebenen Profils und der EN 16931? Und – fachlich am wichtigsten – stimmen die Werte im XML mit dem sichtbaren PDF überein?
Gerade die letzte Ebene wird in der Praxis gerne übersehen. Eine Datei kann jede technische Prüfung bestehen und trotzdem inhaltlich falsch sein, etwa wenn ein Rabatt im PDF dargestellt, im XML aber nicht abgebildet wird. Ein guter Prozess prüft daher nicht nur die Technik, sondern auch die inhaltliche Übereinstimmung beider Repräsentationen.
Bevor ZUGFeRD-Rechnungen produktiv versendet werden, empfiehlt sich ein Testlauf mit ausgewählten Empfängern. Dabei zeigt sich schnell, ob die erzeugten Dateien auf der Gegenseite sauber eingelesen werden oder ob ein Profil zu schlank gewählt wurde. Dieser Testlauf ist günstiger als die Korrektur fehlerhafter Rechnungen im laufenden Betrieb und schafft Vertrauen auf beiden Seiten. Wer hier sorgfältig vorgeht, erspart sich später viele Rückfragen.
Beim Empfang trifft eine ZUGFeRD-Datei auf eine Schwelle: Behandelt das empfangende System sie nur als PDF, ist nichts gewonnen – die Buchhaltung tippt die Daten weiterhin ab. Liest das System hingegen das eingebettete XML aus, lassen sich Lieferant, Betrag, Steuer, Positionen und Zahlungsbedingungen automatisch übernehmen. Genau an dieser Stelle entscheidet sich, ob ZUGFeRD ein Fortschritt ist oder nur eine hübsch verpackte PDF.
Der erste Schritt jeder sinnvollen Verarbeitung ist die Extraktion des eingebetteten XML aus der PDF/A-3-Datei. Anschließend werden die strukturierten Felder ausgelesen und auf die Felder des eigenen Systems abgebildet. Idealerweise prüft das System dabei, ob die Werte im XML zu der sichtbaren PDF passen, und gleicht die Lieferantendaten mit dem eigenen Stammdatenbestand ab. So entsteht aus einer eingehenden Datei ein vorerfasster Buchungsvorschlag, den die Buchhaltung nur noch kontrolliert und freigibt.
Ein häufiger Stolperstein liegt im Umgang mit unterschiedlichen Profilen. Ein robustes Empfangssystem muss damit rechnen, dass eingehende Dateien in verschiedenen Profilen ankommen – vom schlanken MINIMUM bis zum umfangreichen EXTENDED. Es sollte fehlende Felder erkennen, kennzeichnen und im Zweifel eine manuelle Nachbearbeitung anstoßen, statt eine unvollständige Buchung blind durchzuwinken.
Im Mittelstand laufen eingehende Rechnungen typischerweise in zwei Systeme: in das ERP- beziehungsweise Buchhaltungssystem für die Verbuchung und in das Dokumentenmanagementsystem für die revisionssichere Ablage. ZUGFeRD bedient beide Welten elegant, weil die eine Datei sowohl das menschenlesbare Dokument als auch die strukturierten Buchungsdaten enthält. Das DMS archiviert das PDF/A-3 im Original, während das ERP die XML-Daten zur Verbuchung nutzt.
Entscheidend ist, dass die Originaldatei unverändert erhalten bleibt. Es darf nicht passieren, dass das DMS nur das sichtbare PDF speichert und das eingebettete XML beim Import verloren geht. Die archivierte Datei muss exakt der empfangenen Datei entsprechen – mit beiden Bestandteilen. Andernfalls geht der prüfbare Zusammenhang zwischen sichtbarer und strukturierter Repräsentation verloren.
Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form – kurz GoBD – beschreiben, wie elektronische Unterlagen aufzubewahren sind, damit sie als ordnungsgemäß gelten. Im Kern geht es um Unveränderbarkeit, Vollständigkeit, Nachvollziehbarkeit und maschinelle Auswertbarkeit über die gesamte Aufbewahrungsfrist. Diese Begriffe lassen sich gut auf ZUGFeRD übertragen.
PDF/A ist eine speziell für die Langzeitarchivierung entworfene PDF-Variante. Sie verzichtet auf Elemente, die in ferner Zukunft nicht mehr zuverlässig darstellbar wären, und sorgt dafür, dass ein Dokument auch nach vielen Jahren noch originalgetreu angezeigt werden kann. Die Variante PDF/A-3 erlaubt zusätzlich das Einbetten beliebiger Dateien – genau diese Eigenschaft nutzt ZUGFeRD für sein XML. Damit ist das Trägerformat selbst bereits auf Langlebigkeit ausgelegt.
Für die Archivierung folgt daraus ein wichtiger Grundsatz: Aufzubewahren ist die vollständige Originaldatei mit beiden Bestandteilen, also PDF und eingebettetes XML. Es genügt nicht, nur einen Ausdruck oder nur das extrahierte XML abzulegen. Erst die unveränderte Originaldatei dokumentiert den tatsächlich ausgetauschten Beleg in seiner ursprünglichen Form.
Revisionssicher abzulegen bedeutet vor allem, dass eine einmal archivierte Rechnung nicht unbemerkt verändert werden kann und über die gesamte Aufbewahrungsfrist auffindbar und lesbar bleibt. Ein geeignetes Dokumentenmanagementsystem unterstützt dies durch Schutz vor nachträglicher Veränderung, lückenlose Protokollierung von Zugriffen und Verknüpfung der Rechnung mit den zugehörigen Buchungs- und Verfahrensinformationen. Wichtig ist außerdem eine nachvollziehbare Verfahrensdokumentation, die beschreibt, wie eingehende ZUGFeRD-Dateien empfangen, geprüft, verarbeitet und archiviert werden.
Zur Aufbewahrungsfrist ist Zurückhaltung angebracht: Wie lange Rechnungen aufzubewahren sind, ergibt sich aus steuer- und handelsrechtlichen Vorgaben, die sich ändern können und vom Einzelfall abhängen. Diese Fristen sollten Sie sachlich anhand der jeweils geltenden Regelungen und mit fachkundiger Begleitung bestimmen. Eine pauschale Jahreszahl wäre hier unseriös.
Die gute Nachricht zuerst: Für viele mittelständische Unternehmen ist ZUGFeRD ein erreichbares Ziel, weil es an vorhandene Prozesse anknüpft. Die gewohnte PDF-Rechnung bleibt erhalten, die Buchhaltung muss ihre Arbeitsweise nicht von Grund auf umstellen, und viele bestehende Systeme bringen die nötigen Funktionen bereits mit oder lassen sich nachrüsten. Trotzdem gibt es wiederkehrende Fehlerquellen, die man kennen sollte.
Die häufigste fachliche Stolperfalle ist der Widerspruch zwischen dem sichtbaren PDF und dem eingebetteten XML. Er entsteht oft, wenn das PDF aus einer Layout-Vorlage stammt und das XML aus einer anderen Datenquelle befüllt wird. Ein nachträglich gewährter Rabatt, ein geänderter Steuersatz oder eine korrigierte Position landet dann nur in einer der beiden Repräsentationen. Für Empfangende ist das gefährlich, weil je nach Verarbeitungsweg unterschiedliche Werte gebucht werden könnten. Die Abhilfe ist organisatorisch: PDF und XML müssen aus derselben Datenbasis entstehen.
Eine zweite Stolperfalle ist die Reihenfolge der Einführung. Viele Unternehmen konzentrieren sich zunächst auf den Versand, weil das die nach außen sichtbare Seite ist. In der Praxis ist jedoch die zuverlässige Empfangsfähigkeit häufig der wichtigere und dringlichere Hebel – sowohl für die eigene Effizienz als auch mit Blick auf eingehende E-Rechnungen von Lieferanten. Wer eingehende ZUGFeRD-Dateien nicht sauber verarbeiten kann, schafft sich einen stillen Engpass, der erst auffällt, wenn das Belegvolumen steigt.
Aus vielen Projekten lässt sich eine einfache Lehre ziehen: Die richtige Reihenfolge ist wichtiger als das Tempo. Wer mit der Empfangsfähigkeit beginnt, schafft schnell sichtbaren Nutzen und gewinnt die Buchhaltung als Verbündete. Wer hingegen sofort den Versand priorisiert, ohne die Archivierung mitzudenken, baut sich später eine aufwendige Nachbesserung. Ein gestaffeltes Vorgehen reduziert Risiko und Frust gleichermaßen.
Technik ist nur die halbe Miete. Die Buchhaltung muss verstehen, warum eine eingehende Datei jetzt anders behandelt wird und worauf bei der Prüfung zu achten ist. Eine kurze, praxisnahe Schulung und klare Handlungsanweisungen sorgen dafür, dass die neuen Abläufe akzeptiert und konsequent gelebt werden. Gerade in kleineren Teams entscheidet die Akzeptanz darüber, ob die Automatisierung tatsächlich genutzt wird oder ob im Zweifel doch wieder manuell abgetippt wird.
