ZUGFeRD: Aufbau, Profile und eine echte Beispielrechnung

Kurz­zusammen­fassung

14 Min.

ZUGFeRD ist ein Rechnungsformat, das zwei Dinge in einer einzigen Datei zusammenbringt: ein PDF für den Menschen und einen strukturierten XML-Datensatz für die Software. Wer die Datei öffnet, sieht eine ganz normale Rechnung. Wer sie in ein Buchhaltungsprogramm zieht, bekommt Beträge, Steuersätze und Positionen automatisch eingelesen. Gepflegt wird der Standard vom Forum elektronische Rechnung Deutschland (FeRD), veröffentlicht wird er über die AWV. Aktuell ist die Version 2.5.2 vom 4. August 2026. Entscheidend ist dabei nicht die Versionsnummer, sondern das Profil: Zwei der fünf Profile gelten in Deutschland ausdrücklich nicht als vollständige Rechnung. Dieser Ratgeber erklärt den Aufbau, die Profile, zeigt eine vollständige Beispielrechnung mit ihrer XML und ordnet ein, wer das Format wirklich braucht.

Was ist ZUGFeRD?

ZUGFeRD ist ein Hybridformat für elektronische Rechnungen. Hybrid heißt: eine Datei, zwei Lesarten. Außen ist es ein PDF, wie man es kennt, mit Briefkopf, Positionen und Summen. Innen steckt derselbe Rechnungsinhalt noch einmal als XML, also als Datensatz, in dem jedes Feld eine klare Bedeutung hat. Der Empfänger öffnet entweder das eine oder das andere, je nachdem ob ein Mensch oder eine Software auf die Rechnung schaut. Eine ZUGFeRD Rechnung ist damit kein eigenes Dateiformat neben dem PDF, sondern eine ganz normale PDF-Datei mit einem zusätzlichen Datensatz darin.

Die Abkürzung ZUGFeRD steht ausgeschrieben für den Zentralen User Guide des Forums elektronische Rechnung Deutschland, und viel mehr bedeutet der Name auch nicht. Wichtiger als die Auflösung ist, wer dahintersteht: Das FeRD ist ein Zusammenschluss aus Verbänden, Verwaltung und Softwarehäusern, unterstützt vom Bundesministerium für Wirtschaft und Energie. Der Standard wird über die AWV veröffentlicht und ist frei verfügbar, es gibt keine Lizenzgebühr und keinen Hersteller, der ihn besitzt.

ZUGFeRD, E-Rechnung und XRechnung sauber getrennt

Wer die drei Begriffe verwechselt, verlangt von seiner Software das falsche Format oder hält ein PDF per Mail schon für erledigt. Deshalb zuerst die Abgrenzung. E-Rechnung ist der Oberbegriff. Gemeint ist jede Rechnung, die in einem strukturierten Format ausgestellt, übermittelt und empfangen wird und sich automatisch weiterverarbeiten lässt. Ein PDF per Mail erfüllt das nicht, auch dann nicht, wenn es aus einem Rechnungsprogramm kommt, denn für eine Software ist der Inhalt nur Text ohne Bedeutung.

ZUGFeRD ist eine von mehreren Möglichkeiten, diese Anforderung zu erfüllen. Die zweite in Deutschland verbreitete Möglichkeit ist die XRechnung, eine reine Datendatei ohne jede Sichtschicht. Beide setzen dieselbe europäische Norm um, die EN 16931, und beide sind damit gleichwertig zulässig. Der Unterschied liegt darin, ob am Ende noch etwas zum Ansehen übrig bleibt.

Wo die Pflicht ins Spiel kommt

Seit dem 1. Januar 2025 muss jedes inländische Unternehmen elektronische Rechnungen empfangen können. Dafür gibt es keine Übergangsfrist und keine Umsatzgrenze. Das Ausstellen läuft dagegen gestaffelt: Bis Ende 2026 darf noch jeder auf Papier oder im einfachen PDF schreiben, wer 2026 nicht mehr als 800.000 Euro Umsatz gemacht hat, bekommt ein Jahr mehr, und ab dem 1. Januar 2028 ist die elektronische Rechnung im inländischen Geschäft zwischen Unternehmen ohne Ausnahme Pflicht. Die Details, die Ausnahmen und was für Kleinunternehmer gilt, stehen im Ratgeber zur E-Rechnungspflicht.

Für das Format heißt das: Die Pflicht schreibt kein ZUGFeRD vor. Sie schreibt vor, dass die Rechnung der EN 16931 entspricht. ZUGFeRD ist ein Weg dorthin, aber eben nur in bestimmten Ausprägungen, und genau da liegt die Falle, zu der wir gleich kommen.

ZUGFeRD Rechnungsformat: PDF und XML in einer Datei

Das ZUGFeRD Rechnungsformat löst ein Problem, das in der Umstellungsphase real ist: Die eine Hälfte der Kunden kann strukturierte Daten verarbeiten, die andere nicht. Wer eine reine XML-Datei verschickt, hängt die zweite Hälfte ab. Wer ein PDF verschickt, erfüllt die Anforderung nicht. Das Hybridformat umgeht die Entscheidung, indem es beides in dieselbe Datei packt.

Wie die XML in die PDF kommt

Technisch nutzt ZUGFeRD das PDF-Format PDF/A-3. Das ist die Langzeitarchiv-Variante von PDF, und sie darf, anders als ein gewöhnliches PDF, beliebige Dateien als Anhang mitführen. Genau dort liegt die XML, nicht sichtbar, aber fest verbunden mit dem Dokument. Eine Software, die ZUGFeRD kennt, greift sich diesen Anhang und liest ihn aus. Ein Mensch, der die Datei doppelklickt, merkt davon nichts.

Die XML selbst ist in der Syntax UN/CEFACT CII geschrieben. Das ist eine von zwei technischen Schreibweisen, in denen sich die EN 16931 ausdrücken lässt, die andere heißt UBL. Für das Hybridformat ist nur CII zugelassen. Das wird dort zum Thema, wo im Haus bereits UBL entsteht, etwa für den Versand über Peppol oder für eine XRechnung in der UBL-Fassung. Dieser Datensatz lässt sich nicht einfach ins PDF legen, er muss vorher nach CII übersetzt werden. Wer das übersieht, plant einen Arbeitsschritt zu wenig ein.

Welche Datei rechtlich zählt

Hier wird es für die Buchhaltung ernst. Bei einer reinen XRechnung ist die Antwort einfach, die XML-Datei ist das Original. Bei ZUGFeRD steckt beides in derselben Datei, und maßgeblich ist der strukturierte Teil. Weichen Sichtschicht und Datensatz voneinander ab, etwa weil jemand das PDF nachträglich bearbeitet hat, gilt die XML. Aufzubewahren ist deshalb immer die Originaldatei, nicht der Ausdruck und auch keine neu erzeugte Kopie.

Praktisch bedeutet das auch, dass das PDF nicht als Beleg allein weiterwandern darf. Wer die Rechnung aus dem Mailprogramm in ein Archiv zieht, muss sicherstellen, dass die eingebettete XML dabei erhalten bleibt. Manche Werkzeuge, die PDFs komprimieren oder zusammenführen, werfen eingebettete Anhänge still weg. Das fällt erst bei der Prüfung auf.

Versionen und Profile: welche Variante als E-Rechnung zählt

Es gibt nicht das ZUGFeRD. Es gibt eine Versionslinie und darin fünf Datenprofile, die unterschiedlich viel enthalten. Wer das übersieht, verschickt im besten Fall eine Rechnung, die der Empfänger ablehnt, und im schlechteren eine, die als E-Rechnung gar nicht anerkannt wird.

Von 1.0 zu 2.x

Die erste Fassung erschien 2014, lange vor der europäischen Norm, und folgte einer eigenen Logik. Mit Version 2.0 wurde das Format auf die EN 16931 ausgerichtet, und seitdem zählt für die deutsche Rechtslage eine klare Grenze: Als E-Rechnung anerkannt wird ZUGFeRD erst ab Version 2.0.1. Alles davor ist ein Datenaustauschformat, aber keine E-Rechnung im Sinne der Vorschriften. Die aktuelle Fassung ist 2.5.2 vom 4. August 2026, und das FeRD veröffentlicht neue Versionen inzwischen eng getaktet an den halbjährlichen Aktualisierungen der Codelisten.

Für die Praxis ist das weniger dramatisch, als es klingt. Neuere Versionen erweitern meist die oberen Profile, während der Kern stabil bleibt. Die Frage, die Sie Ihrer Software stellen sollten, lautet trotzdem konkret: Welche Version und welches Profil erzeugt sie, und lässt sich das umstellen.

Die fünf Profile und der Fallstrick

Ein Profil bestimmt, wie viele Felder der Datensatz enthält. Von sehr wenig bis sehr viel reicht die Reihe MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT) und EXTENDED. Dazu kommt ein Referenzprofil namens XRECHNUNG, das keine eigene Datenmenge beschreibt, sondern festlegt, wie eine normkonforme XML in das PDF eingebettet wird.

Die beiden kleinsten Profile sind der häufigste Grund für zurückgewiesene Rechnungen. MINIMUM und BASIC WL enthalten keine Rechnungszeilen und sind vom FeRD ausdrücklich als Buchungshilfe gedacht, nicht als Rechnung. Wenn eine Software standardmäßig MINIMUM erzeugt, sieht die Datei für den Absender vollkommen normal aus, denn das PDF ist ja vollständig. Der Fehler zeigt sich erst beim Empfänger.

Für den laufenden Geschäftsverkehr ist EN 16931 (COMFORT) die sichere Wahl. Es deckt den Kerndatensatz der Norm vollständig ab, enthält also Steuersätze je Position, Leistungszeitraum und Zahlungsbedingungen als eigene Felder. EXTENDED lohnt nur dort, wo eine Branche zusätzliche Angaben verlangt, etwa im Baugewerbe oder in der Logistik.

Wie Sie herausfinden, was Ihre Software erzeugt

Verlassen Sie sich nicht auf die Webseite des Anbieters, dort steht meist nur das Wort ZUGFeRD ohne Zusatz. Der verlässliche Weg dauert zwei Minuten. Schreiben Sie eine Testrechnung an sich selbst, öffnen Sie die Datei im PDF-Betrachter und holen Sie die eingebettete XML aus der Anlagenliste heraus. Ganz oben in dieser Datei steht in einem Feld namens GuidelineSpecifiedDocumentContextParameter eine Kennung, und die verrät das Profil. Endet sie auf minimum oder basicwl, haben Sie das Problem gefunden, bevor es Ihr Kunde findet.

Noch schneller geht es mit einem Prüfwerkzeug, das die Datei einliest und Version und Profil im Klartext meldet. Der Aufwand lohnt sich einmalig, denn an dieser Einstellung ändert sich danach selten etwas. Lässt Ihre Software das Profil nicht einstellen und erzeugt sie eine der beiden kleinen Varianten, ist das ein harter Grund für einen Wechsel, kein Schönheitsfehler.

Factur-X, derselbe Standard mit französischem Namen

Wer international abrechnet, stolpert über den Namen Factur-X. Dahinter steckt dasselbe Format. Deutschland und Frankreich entwickeln es gemeinsam weiter, die Versionen erscheinen im Gleichschritt, und eine Datei aus dem einen Land wird im anderen ohne Umweg gelesen. Für die Empfängerseite ist der Unterschied nur der Name auf dem Papier.

ZUGFeRD Rechnung Beispiel: so sieht die eingebettete XML aus

Fast jede Erklärung zu dem Format hört genau da auf, wo es interessant wird. Deshalb hier eine vollständige ZUGFeRD Beispielrechnung, erst als das, was der Mensch sieht, dann als das, was die Software liest. Es ist derselbe Vorgang, zweimal dargestellt.

Die Rechnung, wie der Empfänger sie sieht

Angenommen, ein Ingenieurbüro stellt einem Bauherrn die statische Berechnung eines Dachtragwerks in Rechnung. Rechnungsnummer 2026-0184, Rechnungsdatum 14. Oktober 2026, Leistungszeitraum bis 30. September 2026, eine Position über 12,5 Stunden zu 95 Euro. Das ergibt netto 1.187,50 Euro, darauf 19 Prozent Umsatzsteuer, also 225,63 Euro, und damit einen Endbetrag von 1.413,13 Euro, zahlbar bis zum 28. Oktober.

So weit die gewohnte Ansicht. Im PDF steht das als Tabelle mit Briefkopf, Positionszeile und Summenblock, genau wie bei jeder anderen Rechnung auch. Nichts an dieser Seite verrät, dass die Datei mehr enthält.

Dieselbe Rechnung als XML

Im Inneren derselben Datei liegt der Datensatz. Gekürzt auf die tragenden Teile sieht er so aus:

<rsm:CrossIndustryInvoice>
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>2026-0184</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20261014</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Statische Berechnung Dachtragwerk</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>95.0000</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">12.5000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
          <ram:TypeCode>VAT</ram:TypeCode>
          <ram:CategoryCode>S</ram:CategoryCode>
          <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>1187.50</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>1187.50</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">225.63</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1413.13</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1413.13</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Drei Stellen lohnen einen zweiten Blick. Ganz oben steht mit urn:cen.eu:en16931:2017 die Angabe, nach welcher Norm die Rechnung gebaut ist. Daran erkennt eine prüfende Software sofort, welches Regelwerk sie anlegen muss. Der TypeCode 380 bedeutet schlicht Rechnung, eine Gutschrift trüge hier die 381. Und im Summenblock steht jeder Wert einzeln, von der Positionssumme bis zum Zahlbetrag, damit die Prüfung nachrechnen kann, ob die Zahlen zueinander passen.

Genau diese Nachrechnung ist der häufigste Ablehnungsgrund in der Praxis. Nicht ein fehlendes Feld, sondern ein Steuerbetrag, der um einen Cent von der Summe der Positionen abweicht, weil irgendwo anders gerundet wurde.

Dieselbe Rechnung im falschen Profil

Jetzt der aufschlussreiche Teil. Würde dieselbe Rechnung im Profil MINIMUM erzeugt, fiele der gesamte mittlere Block weg, also IncludedSupplyChainTradeLineItem mit Leistungsbezeichnung, Stundenzahl und Stundensatz. Übrig bliebe ein Datensatz, der Rechnungsnummer, Datum, Gesamtbetrag und Steuerbetrag kennt, aber nicht, wofür das Geld fließt. Die sichtbare PDF-Seite wäre dabei vollkommen unverändert, mit Position, Beschreibung und allem, was dazugehört.

Daran scheitert die Rechnung. Nicht an der Optik, sondern daran, dass der maßgebliche Teil die Pflichtangaben nicht mehr enthält. Der Absender sieht ein korrektes Dokument, der Empfänger bekommt einen unvollständigen Datensatz, und keiner von beiden merkt es, bis die Buchhaltung nachfragt. Deshalb ist das Profil die einzige Angabe, auf die es bei dem Format wirklich ankommt, und nicht die Versionsnummer, über die meist geredet wird.

Woran Sie erkennen, ob eine PDF ZUGFeRD enthält

Von außen sieht man es nicht, und darauf fallen auch erfahrene Buchhalter herein. Zwei Wege führen zur Antwort. Im PDF-Betrachter gibt es eine Anlagen- oder Anhangsliste, dort taucht die eingebettete Datei auf, meist unter dem Namen factur-x.xml oder zugferd-invoice.xml. Der zweite Weg ist ein Prüfwerkzeug, das die Datei einliest und nicht nur sagt, ob eine XML drinsteckt, sondern auch welches Profil und welche Version. Wer regelmäßig Rechnungen prüft, braucht ohnehin ein solches Werkzeug.

Wer ZUGFeRD braucht und wer nicht

Die meisten Erklärungen zum Thema beschreiben die Technik und lassen den Leser mit der eigentlichen Frage allein. Deshalb hier die Einordnung nach Einsatzfall statt nach Format.

Rechnungen an Behörden

Hier ist ZUGFeRD die schwächere Wahl. Bund und Länder haben ihre Rechnungseingangsportale auf die XRechnung ausgerichtet, dort wird die reine Datendatei erwartet, samt Leitweg-ID als Käuferreferenz. Manche Portale nehmen eine ZUGFeRD-Datei im Referenzprofil XRECHNUNG an, verlassen sollte man sich darauf nicht. Wer regelmäßig an öffentliche Auftraggeber stellt, fährt mit der XRechnung ruhiger.

Rechnungen an Unternehmen

Das ist das eigentliche Zuhause des Formats. Im Geschäft zwischen Unternehmen ist die Empfängerseite gemischt: Große Kunden haben eine Buchhaltungssoftware, die strukturierte Daten liest, kleinere öffnen die Rechnung noch von Hand. Eine ZUGFeRD-Datei bedient beide, ohne dass Sie vorher fragen müssen, wie weit der Kunde ist. Für Dienstleister mit gemischtem Kundenstamm ist das der stärkste Grund für das Format.

Rechnungen ins Ausland

Innerhalb der EU trifft man eher auf Peppol und die dort übliche UBL-Syntax. Frankreich ist die Ausnahme, dort heißt dasselbe Format Factur-X und ist etabliert. Wer regelmäßig grenzüberschreitend abrechnet, sollte vor der Softwareauswahl klären, welches Format die Kunden tatsächlich erwarten, statt sich auf eine deutsche Gewohnheit zu verlassen.

Privatkunden und Kleinbeträge

Hier brauchen Sie es nicht. Rechnungen an Privatpersonen fallen nicht unter die Pflicht, und für Kleinbetragsrechnungen bis 250 Euro sowie für Fahrausweise gelten Ausnahmen. Ein lesbares PDF reicht. Wer trotzdem umstellt, tut es aus Bequemlichkeit, nicht aus Vorschrift, und das ist ein vollkommen legitimer Grund, solange man ihn nicht mit einer Pflicht verwechselt.

Die Antwort hängt am Empfänger, nicht an der Technik.

Wenn Sie nicht wissen, was der Kunde verarbeiten kann

Das ist der Normalfall, und er wird in Ratgebern gern übersprungen. Niemand ruft vor jeder Rechnung beim Kunden an, um das Format abzufragen. Zwei Vorgehensweisen haben sich bewährt. Die erste ist, einmalig bei den zwanzig wichtigsten Kunden nachzufragen und die Antwort im Kundendatensatz zu hinterlegen, am besten dort, wo auch die Zahlungsbedingungen stehen. Das kostet einen Vormittag und erledigt die Frage für Jahre.

Die zweite ist, auf das Hybridformat zu setzen und die Frage damit offenzulassen. Genau dafür wurde es gebaut. Der Preis ist, dass Sie bei Behörden trotzdem auf die XRechnung umschalten müssen, denn dort gilt die Ausnahme. Wer beides braucht, sollte eine Software wählen, die beides beherrscht, statt zwei Programme nebeneinander zu betreiben.

ZUGFeRD erstellen: welche Wege es gibt

Von Hand lässt sich das Format nicht erzeugen. Ein PDF/A-3 mit korrekt eingebetteter, normkonformer XML entsteht nicht in einem Textprogramm, und auch der Export aus einer Tabellenkalkulation hilft nicht weiter. Es braucht eine Software, die das Format kennt. Die Wege unterscheiden sich weniger im Ergebnis als darin, wie viel Arbeit vorher und nachher anfällt.

Dieser Artikel stammt von der Unusual Software GmbH, dem Anbieter von Unusual Suite. Die folgende Übersicht nennt auch das eigene Produkt. Wir haben die Einordnung so geschrieben, dass sie auch dann nützlich ist, wenn Sie sich für eine andere Lösung entscheiden.

Preise und Funktionsumfang hängen vom gewählten Paket und der Zahl der Nutzer ab. Für verbindliche Kosten lohnt die Anfrage beim jeweiligen Anbieter.

Buchhaltungssoftware

Programme wie Lexware Office, sevDesk oder die DATEV-Welt kommen von der Buchhaltung her. Ihre Stärke ist der Anschluss nach hinten: Belege, Kontenrahmen, Umsatzsteuervoranmeldung und die Übergabe an die Kanzlei. Das Rechnungsformat ist dort ein Baustein unter vielen und wird entsprechend zuverlässig gepflegt. Ihre Schwäche zeigt sich nach vorn, zum Projekt hin. Wer Stunden erfasst, Aufgaben verteilt und daraus abrechnet, führt diese Daten woanders und tippt sie für die Rechnung ein zweites Mal ab.

Kostenlose Online-Werkzeuge

Es gibt Generatoren, die eine einzelne Rechnung im Browser erzeugen, ohne Anmeldung und ohne Kosten. Für einen Testlauf, für die seltene Rechnung oder um überhaupt erst einmal eine ZUGFeRD-Datei in der Hand zu haben, sind sie gut geeignet. Für den laufenden Betrieb sind sie es nicht: Es gibt keine Nummernkreise, keine Kundendaten, keine Nachverfolgung offener Posten, und jede Rechnung beginnt bei null. Dazu kommt die Frage, wohin die eingegebenen Daten gehen.

Integrierte Business-Software

Der dritte Weg kommt von der anderen Seite. Hier liegen Kunden, Projekte und Zeiten ohnehin im System, und die Rechnung entsteht aus Daten, die schon da sind. Das spart den Übertrag und die Fehler, die dabei passieren. Der Preis dafür ist, dass die Buchhaltungstiefe fehlt, eine solche Lösung ersetzt die Kanzlei nicht.

Unusual Suite

Unusual Suite verschickt ein hybrides PDF. Das gehört an den Anfang, weil es die Frage dieses Ratgebers direkt beantwortet. Jede gestellte Rechnung geht als lesbares PDF hinaus, das die maschinenlesbare E-Rechnung nach EN 16931 eingebettet trägt und zusätzlich separat beilegt, für Deutschland und die meisten Länder als XRechnung in der Fassung 3.0.1. Mensch und Buchhaltungssoftware lesen damit dieselbe Sendung, und der Empfänger nimmt sich die Form, die sein System versteht.

Der Rest ist schnell erzählt. Die Software führt CRM, Projektmanagement, Zeiterfassung und Rechnungsstellung in einer Oberfläche zusammen. Rechnungspositionen entstehen aus erfassten Arbeitszeiten samt Projekt, Abrechnungsregel, Zeitraum und Rundung, und die übernommenen Einträge sind danach als abgerechnet markiert und gesperrt. Pflichtangaben wie Anschrift, Umsatzsteuer-Identifikationsnummer, Leistungsdatum und Zahlungsangaben zieht das System aus dem Firmen- und Kundendatensatz, eine Korrektur geht als elektronische Gutschrift hinaus, die auf die berichtigte Rechnung verweist.

Gedacht ist das für Dienstleister, die nach Aufwand abrechnen.

Welcher Weg der richtige ist, hängt weniger am Format als am Umfeld. Eine Übersicht darüber, was eine E-Rechnung Software leisten muss und woran Sie eine passende erkennen, steht in einem eigenen Ratgeber.

Elektronische Rechnung mit ZUGFeRD empfangen und weiterverarbeiten

Über das Ausstellen wird viel geschrieben, über das Empfangen wenig, dabei trifft die Pflicht dort schon heute jeden. Wer eine elektronische Rechnung im ZUGFeRD-Format bekommt, muss sie annehmen, lesen und aufbewahren können.

Prüfen statt vertrauen

Eine eingegangene Datei sollte man nicht einfach durchwinken. Ein Prüfwerkzeug liest die eingebettete XML, meldet fehlende Pflichtfelder und rechnet die Summen nach. Es sagt außerdem, welches Profil vorliegt, und genau das ist die Stelle, an der die beiden kleinsten Profile auffallen. Kommt eine Rechnung im Profil MINIMUM herein, fehlen die Positionen, und als vollständige Rechnung taugt sie damit nicht.

Der zweite Punkt betrifft die Sichtschicht. Wenn PDF und XML unterschiedliche Beträge nennen, gilt der Datensatz. Darum reicht es nicht, das PDF anzusehen und abzuheften. Wer von Hand bucht, sollte die Daten aus der XML lesen und nicht aus der gedruckten Seite.

Was bei einer fehlerhaften Rechnung passiert

Fällt ein Fehler erst nach dem Versand auf, wird die Rechnung nicht überschrieben und auch nicht gelöscht. Sie bleibt, wie sie ist, und bekommt ein zweites Dokument an die Seite. Im Datensatz unterscheidet die beiden nur ein Zeichen: Eine Rechnung trägt im TypeCode die 380, eine Gutschrift die 381, und die Gutschrift nennt zusätzlich die Rechnung, auf die sie sich bezieht. Für die Buchhaltung ist das sauberer als jede Korrektur am Original, weil der Vorgang nachvollziehbar bleibt.

Praktisch heißt das: Ihre Software sollte eine Korrektur als eigenen elektronischen Beleg erzeugen können, nicht nur als neue PDF mit dem Wort Storno im Betreff. Das ist eine der Funktionen, die bei einfachen Rechnungswerkzeugen gern fehlt und die man vor der Entscheidung ausprobieren sollte, am besten an einer Testrechnung, die man gleich wieder berichtigt.

Aufbewahren

Aufzubewahren ist die Originaldatei in unveränderter Form, über die gesetzliche Frist hinweg und so, dass die eingebettete ZUGFeRD-XML erhalten bleibt. Ein Ausdruck genügt nicht, eine neu erzeugte PDF-Kopie ebenfalls nicht. Wer ein Dokumentenarchiv einsetzt, sollte an einer Testdatei prüfen, ob der Anhang den Weg durch das System übersteht, bevor es ernst wird.

An dieser Stelle gehört eine Grenze benannt, die viele Rechnungsprogramme teilen: Nicht jedes Werkzeug, das E-Rechnungen schreibt, kann auch eingehende lesen. Das gilt für die günstigen Tarife mancher Buchhaltungsanbieter. Beim Vergleich lohnt es deshalb, Ausstellen und Empfangen getrennt zu prüfen.

Fazit: erst das Format verstehen, dann das Werkzeug wählen

ZUGFeRD ist kein Zwang, sondern eine Antwort auf eine Übergangszeit, in der die eine Hälfte der Kunden strukturierte Daten liest und die andere noch nicht. Solange das so bleibt, ist das Hybridformat im Geschäft zwischen Unternehmen die bequemste Lösung. An Behörden führt der Weg eher über die XRechnung, und im Ausland sieht die Lage noch einmal anders aus.

Was Sie aus diesem Text mitnehmen sollten, ist weniger die Technik als die eine Frage, die man seiner Software stellen muss: Welche Version und welches Profil erzeugt sie. Ab 2.0.1 aufwärts und mindestens im Profil EN 16931, dann stimmt die Grundlage. Alles andere, von der Zeiterfassung bis zum Archiv, entscheidet sich danach.