ZUGFeRD

ZUGFeRD ( Zentraler User Guide Forum elektronische Rechnung Deutschland ) ist ein offener europäischer Standart für strukturierte, hybride PDF 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.

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

Architektur

ZUGFeRD basiert auf

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

Das PDF ist genauer 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 (hat nichts mit dem Papierformat DIN-A3 zu tun und) ist die dritte Auflage des archivierbaren PDF/A Formats, die unter anderem eingebettete Dateien unterstützt. 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.

Factur/X

Factur-X (1.0.05) ist ein anderer Name für ZUGFeRD 2.1.

Versionen

ZUGFeRD 2.1 am 24.03.2020 veröffentlicht.

  1. von 2.0 auf 2.1
    • Es wurde auch 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 sind jetzt auf Version 3 von https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Registry+of+supporting+artefacts+to+implement+EN16931
    • viele Kardinalitäten wurden angepasst (Extended unterstützt jetzt bspw. die zweimalige Angabe von Grand Total bspw. in Euro und Fremdwährung)
  2. 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.
    • In der Google Group befindet sich eine detaillierte Liste was noch gemacht werden muss.

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

Profile

ZF kann in fünf Vollständigkeitsprofilen vorliegen

  • Minimum (nur ZF 2)
  • Basic Without Lines (nur ZF 2)
  • Basic
  • EN16931 (in ZF1 “Comfort” genannt)
  • 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.

Beispiele