ZUGFeRD

ZUGFeRD ( Zentraler User Guide Forum elektronische Rechnung Deutschland ) ist ein offener europäischer Standard für e-Rechnungen. Umgesetzt wird dies durch eine XML-Datei die in eine PDF-Datei eingebettet wird. Die menschenlesbare Version kann dabei weiterhin mit allen PDF-Readern dargestellt werden, nur die Interpretation des maschinenlesbaren XML-Teils erfordert entsprechende Zusatzsoftware. Den maschinenlesbaren Teil nennt man auch “strukturiert” und eine Kombination aus mehreren, in diesem Fall strukturierten und nicht strukturierten Daten (dem PDF-Dokument) nennt man auch “hybride” Rechnung.

Rechts sehen Sie eine Beispiel-PDF-Rechnung die mit Mustangproject generierte ZUGFeRD-Metadaten enthält. Wenn Sie sie in Adobe Acrobat Reader öffnen klicken Sie auf das Büroklammer-Symbol des Tab für Dateianhänge um die eingebettete XML-Datei zu sehen.
Screenshot eines Acrobat Adobe PDF Reader der eine ZUGFeRD-Rechnung mit geöffnetem Reiter für Dateianhänge zeigt

Der Anteil von Unternehmen, die ZUGFeRD/Factur-X versenden, beträgt laut Bitkom-Studie im September 2021 etwa 45% (der 43% der Unternehmen die überhaupt elektronische Rechnungen versenden).

Architektur

ZUGFeRD basiert auf

  • PDF zur optischen Darstellung
  • UN/CEFACT Cross Industry Invoice XML-Datei für die maschinenlesbaren Inhalte

Das PDF ist archivierbar nach den Vorgaben von PDF/A-3. PDF/A ist eine zur Archivierbarkeit optimierte Untermenge von PDF die unter anderem auch validiert werden kann (PDF selbst kann nicht komplett validiert werden). PDF/A-3 (standardisiert in ISO 19005-3:2012 ist die dritte Auflage des archivierbaren PDF/A Formats, die unter anderem eingebettete Dateien unterstützt.

Hintergrundinfo

Das CEN semantische Datenmodell einer Kernrechnung war bereits Grundlage für ZUGFeRD 1.0. Es definiert u.a. die Anzahl von Dezimalstellen (Regel 9): in Mengenangaben (4), Einzelpreisen (4) und Gesamtsummen (2), die Einheiten und wie der Gesamtbetrag berechnet wird. Andreas Starke has im Juni 2018 seinen Vorschlag für branchenspezifische Erweiterungen für ZUGFeRD vorgestellt.

Bei einer sehr kleinen Untersuchung von 100 Rechnungen wurden ZUGFeRD-Rechungen 5,3 Tage früher bezahlt.

Offensichtlich akzeptieren alle Deutsche Bundesländer ZUGFeRD-Rechnungen und E-Rechnung-Bund erwähnt das ZUGFeRD 2.1.1 XRechnung-Referenzprofil als Alternative zur XRechnung.

Umsetzung

Wie die XRechnung auch verwendet ZUGFeRD die EN16931 Rechenregeln für die Berechnung und Codelisten für die erlaubten Attribute.

Factur/X

Factur-X (1.0.06) ist ein anderer Name für ZUGFeRD 2.2.

Versionen

ZUGFeRD 2.2.0 wurde am 01.03.2022 veröffentlicht.

  1. von 2.1 auf 2.1.1
    • Es gibt jetzt ein Profil XRechnung mit der entsprechenden Unterstützung des eingebetten Dateinamens xrechnung.xml
  2. von 2.0 auf 2.1
    • Es wurde auch wieder ein englischer Spezifikationstext freigegeben (es gab keine Übersetzung von ZF 2.0),
    • factur-x.xml ist jetzt als Dateiname der eingebetteten Datei nicht nur erlaubt sondern gegenüber zugferd-invoice.xml bevorzugt
    • die Codelisten waren damals auf 6 und sind aktuell auf Version 8 der Digital Building Blocks-Seite
    • viele Kardinalitäten wurden angepasst (Extended unterstützt jetzt bspw. die zweimalige Angabe von Grand Total bspw. in Euro und Fremdwährung)
  3. von 1.0 auf 2.0
    • ZUGFeRD 2 unterstützt europäische B2G-Rechnungen, namentlich EN16931.Alternativ zu ZUGFeRD (genauer der UN/CEFACT CrossIndustryInvoice D16B SCRDM uncoupled) sind auch UBL 2.1 und EDIFACT EN16931-konform.
    • Die ZUGFeRD 2-Vorgängerversion wurde in Frankreich vom FNFE als “Factur-X 1.0” eingeführt.
    • Der Dateiname der eingebetten XML-Datei hat sich von ZUGFeRD-invoice.xml (ZF1) zu factur-x.xml (Factur-X und ZUGFeRD>= 2.1), zugferd-invoice.xml (ZF2) geändert.
    • Es ist jetzt “erlaubt” lediglich den XML-Teil zu versenden.
    • Zwei neue Profile unterhalb von Basic, nämlich
      • Minimum
      • Basic Without Lines (BASIC WL)
    • Das Profile Comfort wurde in Factur-X 1/ZUGFeRD 2 praktisch in EN 16931 umbenannt.
    • Der XML-Teil von ZF1 war praktisch “angepasstes” UN/CEFACT. ZF2 basiert hingegen auf dem Original des XML Schemas, UN/CEFACTS Cross Industry Invoice CII, genauer auf UN/CEFACT CII SCRDM 16B uncoupled .
    • Die “root node” ändert sich dahingehend von CrossIndustryDocument auf CrossIndustryInvoice.
    • Einige Elements haben neue Namen, beispielsweise
      Name in ZF1 in ZF2
      SpecifiedExchangedDocumentContext ExchangedDocumentContext
      HeaderExchangedDocument ExchangedDocument
      ApplicablePercent ram:RateApplicablePercent
      SpecifiedSupplyChainTradeDelivery ram:SpecifiedLineTradeDelivery
      SpecifiedLineTradeAgreement ram:AssociatedDocumentLineDocument
      SpecifiedSupplyChainTradeAgreement ram:SpecifiedLineTradeAgreement
    • Einige generische Elemente wurden durch spezifische ersetzt, beispielsweise wurde ID unterhalb von BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument und ContractReferencedDocument zur IssuerAssignedID.
    • Die Reihenfolge der Elemente spielt eine größere Rolle, so muss beispielsweise unterhalb von SpecifiedSupplyChainTradeTransaction
      das IncludedSupplyChainTradeLineItem jetzt das erste Kindelement sein. BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument ContractReferencedDocument müssen jetzt mit ID anfangen, dann typecode und dann den Rest enthalten.
    • Es wird keine XSLT-Stylesheet-Datei zur Umwandlung in HTML mehr ausgeliefert, aber die der XRechnung kann verwendet werden.

Sie können mit der Mustangproject Kommandozeile eine experimentelle XSLT Transformation anwenden um ZF1 versuchsweise in ZF2 umzuwandeln. Es gibt auch den ersten Versuch einer Mustangproject Beispielsdatei für ZF2.

Profile

ZF kann in sechs Vollständigkeitsprofilen vorliegen

  • Minimum (nur ZF 2)
  • Basic Without Lines (nur ZF 2)
  • Basic
  • EN16931 (in ZF1 “Comfort” genannt)
  • XRechnung (ein “Referenzprofil” für das die AWV keine Validierungsartefakte veröffentlicht)
  • Extended

Mustangproject schreibt üblicherweise im Profil EN16931.

  • 2015 hat Intarsys einige schöne Folien über den Status, und stellt die Geschichte und Abstammung von ZUGFeRD 1, inklusive einiger PDF-Aspekte, Werkzeuge und Prozesse dar und vergleicht einige Profile optisch.
  • Die Bitkom hat in 2014 ZUGFeRD erklärt und zeigt eine ähnliche Beispielrechnung mit einem optischen Vergleich der Profile auf Seite 6.

Anhänge

Rechnungsbegründende Unterlagen wie Protokolle, Aufmaße oder Stundenlisten werden als weitere Dateien in die PDF-Datei eingebettet (Relationship=Source). Erlaubte Dateitypen sind

  • application/pdf (.pdf)
  • image/jpeg (.jpg)
  • text/csv (.csv)
  • TXT
  • XML
  • JSON
  • image/gif (.gif)
  • image/tiff (.tiff)

Der Typecode für diese Anhänge ist oft “916”.

Beispiele

sowie

  • das Corpus Projekt um u.a. echte Beispieldateien aus der Wildbahn zu sammeln.

Codelisten

Alle erlaubten Attributwerte sind in der Tabelle Full listing of the code lists as used in EN16931 aufgeführt.

Branchenempfehlungen

Die deutsche Energiebranche und ein Pharmakonzern haben Anwendungsempfehlungen zu ZUGFeRD veröffentlicht.

Die deutsche Bauausstatter Empfehlung wurde offensichtlich durch eine gemeinsame Branchenempfehlung Bau durch mehrere Verbände ersetzt.

Die Empfehlungen machen bestimmte Elemente verpflichtend, oder empfohlen, und erklären wie ihre Geschäftsprozesse genau elektronisch abgerechnet werden können.

Es gibt eine Empfehlung wie ZUGFeRD-Dateien für Schweizer Rechnungen verwendet werden können.

Andreas Starke hat ein Tool und Prozess veröffentlicht um branchenspezifische additional data, beispielsweise für das Transportwesen in ZUGFeRD-Rechungen zu integrieren. Bislang ist noch keine branchenspezifische Implementierung bekannt.
Frankreich stellt für B2B ein Chorus Pro Testsystem zur Verfügung und dokumentiert die notwendigen Prozesse auch auf englisch in einem Dokument in mittlerweile Version 2.2.

Open-Source-Software