Inhaltliche Identität

Als hybrides Datenformat integriert ZUGFeRD in einem PDF-Dokument (PDF/A-3) strukturierte Rechnungsdaten im XML-Format. Das heißt, der Rechnungsversand erfolgt grundsätzlich in Form eines PDF-Dokuments, welches die Sichtkomponente der Rechnung darstellt.

Gleichzeitig wird ein inhaltlich identisches Mehrstück derselben Rechnung (XML) innerhalb des PDF mit versandt, so dass die elektronische Verarbeitung der Rechnung über die strukturierten Rechnungsdaten - nach Übertragung in das unternehmensspezifische Softwaresystem - problemlos möglich ist.

PDF und XML müssen die Vorgaben des § 14 Abs. 4 Umsatzsteuergesetz ( UStG ) berücksichtigen, um inhaltlich identische Mehrstücke derselben Rechnung darzustellen. Da die Finanzverwaltung keine konkreten Prüfpflichten bzw. Kontrollmaßnahmen für dieses Verfahren festgelegt hat, ist dem Rechnungssender und dem Rechnungssteller zu empfehlen, eigene Prüfmechanismen zur Sicherstellung der inhaltlichen Identität der beiden Rechnungen einzuführen. Neben den gesetzlichen Regelungen sind auch die Grundsätze zur ordnungsgemäßen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff , zuletzt vom 28. November 2019, zu beachten.

(Quelle: https://www.ferd-net.de/standards/was-ist-zugferd/was-ist-zugferd.html)

Kurz gesagt, handelt es sich um ein PDF welches ein XML enthält, dass z. B. mit dem Acrobat Reader von Adobe angesehen und von Lobster Integration ausgelesen werden kann.

Basis-Daten: Preparser

Hier können Sie in der Vorverarbeitung den Preparser ZUGFeRD nutzen, indem Sie in den Basis-Daten unter Erweiterungen → Vorbearbeitung den genannten Preparser auswählen.

Dieser extrahiert ohne weitere Konfiguration das enthaltene XML mit dem Namen ZUGFeRD-invoice.xml, zugferd-invoice.xml oder factur-x.xml.

Phase 3: Strukturen erstellen und Mapping

In der Phase 3 wird der Grundstein für die ZUGFeRD-XML-Nachricht gelegt. Hier wird die Struktur für das gewünschte Konformitätslevel inklusive der nötigen Namespaces erstellt.

Die Struktur wird bei ZUGFeRD aus mehreren XSDs erzeugt. Wichtig dabei ist, dass Sie immer die Struktur für die geforderte ZUGFeRD-Version und Konformitätsstufe verwenden.

Alle verfügbaren ZUGFeRD-Informationen inklusive aller XSDs für die aktuelle ZUGFeRD Version 2.3 (Stand September 24) sind hier verfügbar: https://www.ferd-net.de/standards/zugferd-2.3/zugferd-2.3.html

Praxisbeispiel

Ist also die Version ZUGFeRD 2.1 EXTENDED gefordert, laden Sie sich das Paket für Version 2.3 herunter und suchen Sie sich dafür das entsprechende Schema heraus. Die Schemata sind jeweils abwärtskompatibel.

Für den Fall ZUGFeRD 2.1 EXTENDED verwenden Sie ZUGFeRD 2.3 EXTENDED. Das Schema besteht aus 4 XSDs:

1. Factur-X_1.0.07_EXTENDED.xsd (Haupt-XSD)

2. Factur-X_1.0.07_EXTENDED_urn_un_unece_uncefact_data_standard_QualifiedDataType_100.xsd

3. Factur-X_1.0.07_EXTENDED_urn_un_unece_uncefact_data_standard_ReusableAggregateBusinessInformationEntity_100.xsd

4. Factur-X_1.0.07_EXTENDED_urn_un_unece_uncefact_data_standard_UnqualifiedDataType_100.xsd

Die Haupt-XSD verweist auf die Unter-XSDs. Legen Sie die 3 Unter-XSDs in das Rootverzeichnis des Integration Servers.

Erzeugen Sie nun die Zielstruktur über die Datei-Analyse im Menü der Zielstruktur (Menü → Struktur erzeugen → aus Datei-Analyse), indem Sie die Haupt-XSD auf die Analyse ziehen und XSD/DTD Schema als Art auswählen.

Als Root-Elementname geben Sie CrossIndustryInvoice an und klicken dann auf Anwenden.

Hinweis: Wenn Sie den Root-Namen einer XSD nicht kennen, können Sie data in das Feld eingeben. Lobster Integration sucht dann nach dem Root-Namen. Voraussetzung ist allerdings, dass es nur einen Rootnamen in der XSD gibt.

Praktischerweise wird die Dokumentart XML sowie das Root-Element in Phase 2 automatisch eingetragen, sodass Sie sich darüber keine Gedanken mehr machen müssen.

Mehr zu XML Schemas: Abschnitt XML-Schemas (XSD/DTD).

Haben Sie alles richtig gemacht, wird eine Struktur erstellt und Sie können mit dem Mapping beginnen.

In dem ZUGFeRD-Paket finden Sie auch Beschreibungen, welche Ihnen helfen, die richtigen Orte für Ihre Daten zu finden.

Wenn Sie eine ZUGFeRD-Beispiel-XML ansehen, werden Ihnen die Präfixe vor den XML-Tags auffallen. Sowie die Elemente, denen ein xmlns: vorangestellt sind, die man auch für Attribute halten könnte.

Dabei handelt es sich um Namespaces, welche einzelne XML-Elementen einer eindeutigen Adresse zuordnen. Mehr zu Namespaces erfahren Sie hier: https://de.wikipedia.org/wiki/Namensraum_(XML)

Diese werden nicht automatisch erstellt, sondern können über Felder mit einer speziellen Syntax definiert werden.

Ein Feld für eine Namespacedefinition bekommt immer den Namen des Namespaces und das Suffix _nsdef.

Bleiben wir also beim Beispiel ZUGFeRD 2.3 EXTENDED. Dort werden folgenden Namespaces benötigt:

Hier haben wir also 5 Namespaces, die deklariert werden müssen. Legen Sie daher also die Felder wie folgt an und geben Sie diesen die URI als Fixwert mit:

Nun müssen die deklarierten Namespaces auch den Knoten und Felder bekannt gemacht werden, um den Tags das jeweilige Präfix zu geben.

Dafür steht Ihnen in den Knoten- und Feldeigenschaften das Attribut XML Namespace zur Verfügung. Tragen Sie dort den Namespace ein, welcher als Suffix für das XML-Element verwendet werden soll.

Soll eine untergeordnete Struktur ebenfalls den gleichen Namespace erhalten, kann der Namespace über das Kontextmenü an die untergeordneten Knoten und Felder vererbt werden.

Öffnen Sie dafür auf dem entsprechenden Knoten das Kontextmenü durch einen Rechtsklick und wählen Sie XML Namespaces vererben aus.

Gehen Sie so durch die gesamte Struktur, um den Elementen die Namespaces, genau wie in den Beispielen aus dem Paket, zuzuordnen.

Jetzt haben wir ganz viel über XML geredet, aber Sie fragen sich bestimmt, wann die PDF-Rechnung wichtig wird. Genau jetzt.

Nachdem das Mapping steht, sollte man sich auch überlegen, wo die PDF-Rechnung herkommt.

Idealerweise hat ein vorgelagertes System diese schon erstellt und in ein Verzeichnis gelegt. Diesen Pfad ermitteln Sie mit einer eigenen Logik und speichern diesen in eine Variable, welche wir in einer der nächsten Phasen brauchen.

Hinweis: Achten Sie darauf, dass es sich um ein Verzeichnis innerhalb des Installationsverzeichnisses des Integration Servers handelt und nicht um ein Netzlaufwerk.

Das PDF kann auch mit dem PDFCreator erzeugt werden, wenn das nicht durch ein anderes System erledigt werden kann.

Phase 5: Integration Unit

Es gibt zwei Wege, eine ZUGFeRD zu erstellen:

1. Die ZUGFeRD IU.

2. Die XMLNoTemplateUnit in Verbindung mit dem Postexecuter ZUGFerdPDF.

Unsere Empfehlung ist der 2. Weg mit der XMLNoTemplateUnit in Verbindung mit dem ZUGFerdPDF-Postexecuter. Die Vorteile liegen auf der Hand:

1. Es muss keine Vorlage erstellt werden.

2. Alle XML-Besonderheiten (Attribute, Namespaces, Strukturen) werden in der Zielstruktur erzeugt, sind für jeden sichtbar und leicht zu debuggen. Siehe auch Abschnitt Satzarterkennungen, eindeutige/reservierte Namen für XML.

3. Es kann auch ohne weiteres in anderen Antwortwegen auf das XML zugegriffen werden.

Basierend auf der Empfehlung, verwenden Sie die XMLNoTemplateUnit wie gewohnt.

Je nachdem, ob Sie in anderen Antwortwegen das XML benötigen (z.B. für das Archiv) oder nicht, kann direkt unter der Integration Unit im Bereich Nachbearbeitung der Postexecuter ZUGFerdPDF verwendet werden.

In diesem Fall würde dann das Ergebnis aus der Integration Unit immer die ZUGFeRD sein und das XML wäre nur noch über diese auszulesen.

Daher empfehlen wir die Erstellung der ZUGFeRD erst im entsprechenden Antwortweg.

Phase 6: ZUGFeRD erstellen

Es kann selbstverständlich jede Art von Antwortweg verwendet werden.

Der Antwortweg (oder auch mehrere), der die ZUGFeRD als Ergebnis ausgeben soll, erhält in den Inhalts-Einstellungen den PostExecuter ZUGFerdPDF.

Hier brauchen Sie nun den Pfad zur PDF-Rechnung. Dieser sollte vollständig aus einer Variablen kommen. In der Konfiguration wird auch das Konformitätslevel und die ZUGFeRD-Version erwartet. Optional können ab ZUGFeRD 2 noch weitere Anhänge in das PDF gepackt werden.

Gehen wir davon aus, dass wir den Pfad zur PDF-Rechnung in Phase 3 in die Variable var__pfad_zum_PDF geschrieben haben, wir das Konformitätslevel EXTENDED brauchen, eine ZUGFeRD Version 2 erstellen und keine weiteren Daten mit Anhängen wollen. Die Konfiguration dazu sieht dann so aus:

Außerdem setzen Sie die Inhalts-Einstellung auf Ausgabe von IU und die Kodierung auf UTF-8.

Das Ergebnis ist eine ZUGFeRD-PDF mit eingebettetem XML.

Jetzt fragen Sie sich aber vielleicht, wann welche ZUGFeRD-Version und welches Konformitätslevel benötigt wird. Gute Frage!

Diese Frage lässt sich recht einfach beantworten: Ihr Partner wird Ihnen mitteilen, welche ZUGFeRD-Version Sie ihm in welchem Level übermitteln sollen.

Was aber, wenn Ihr Partner Ihnen nur eine Beispiel-XML gesendet hat?

Auch hier gilt: Kein Problem. Die ZUGFeRD-Version lässt sich anhand des XMLs über folgende Punkte herausfinden.

1. Der Name der XML.
   ZUGFeRD 1: ZUGFeRD-invoice.xml und zugferd-invoice.xml
   ZUGFeRD 2: factur-x.xml

2. Das Root-Element.
   ZUGFeRD 1: CrossIndustryDocument
   ZUGFeRD 2: CrossIndustryInvoice

Damit wissen wir jetzt die Version, aber wie steht es um das Konformitätslevel?

Das steht praktischerweise in einer validen ZUGFeRD-Nachricht in den Daten. Suchen Sie nach dem Tag <ram:ID>. Dort finden Sie einen String, welcher das konkrete Konformitätslevel enthält.

In diesem Beispiel sehen wir, dass es sich um das Konformitätslevel BASIC handelt.

Mit diesen Informationen kann die ZUGFeRD-Konfiguration dann in jedem Fall erfolgreich durchgeführt werden.

Phase 6: ZUGFeRD auslesen

Parallel zum ZUGFeRD-Preparser, welcher eine XML aus einer ZUGFeRD ausliest, gibt es auch einen Postexecuter, der dies kann: ZUGFeRDExtractXML.

Dieser kann verwendet werden, wenn in Phase 3 z. B. nur der PDF-Teil analysiert werden soll, um zu entscheiden, was mit der XML und dem PDF geschehen soll. Es kann dann z. B. einen Antwortweg geben, der die komplette ZUGFeRD archiviert, einen der das XML an ein Verarbeitungsprofil schickt und einen, der nur das XML archiviert.

Der Postexecuter sollte nicht in Phase 5 verwendet werden.

PDF/A-3

ZUGFeRD basiert auf dem PDF/A-3-Standard. Lobster Integration versucht beim Erstellen der Daten die verknüpfte PDF-Rechnung zu einer PDF/A-3 umzuwandeln. Damit das gelingen kann, sollte das PDF sauber erstellt worden sein.

Abweichend von der Dokumentation kann auch ein PDF-A verwendet werden, da dort die Metadaten meist schon in der richtigen Form sind.

Abweichende Namen des XMLs

Es kann auch passieren, dass Ihnen ein Partner eine ZUGFeRD (zumindest behauptet er, es sei eine) zukommen lässt und das XML vom Preparser ZUGFeRD bzw. vom Postexecuter ZUGFeRDExtractXML nicht ausgelesen werden kann, weil kein XML mit den oben beschriebenen Namen in den Metadaten gefunden werden kann.

Schaut man mit dem Adobe Acrobat in das PDF, steht dort aber der vermeintlich korrekte Name.

Wenn dies der Fall ist, handelt es sich nicht um eine valide ZUGFeRD-Rechnung.

Der XML-Teil kann trotzdem ausgelesen werden, nur nicht mit dem ZUGFeRD-Bordmitteln.

Verwenden Sie in einem solchen Fall den Preparser ExtractFileFromPDF.

Sie sollten Ihren Partner aber darauf hinweisen, dass es sich um kein valides ZUGFeRD handelt.

EN16931 XRECHNUNG

ZUGFeRD 2.2 in der Konformitätsstufe XRECHNUNG wird von deutschen Behörden im Rahmen der EN16931 als Rechnungsformat für die E-Rechnung akzeptiert.

Allerdings wird hier nur der XML-Teil ohne PDF erwartet. Beachten Sie dafür aber auch die Anforderungen der jeweiligen Behörden und Partner.

Der Ablauf zur Erstellung der XML-Datei ist genau derselbe, wie bei den anderen Typen, mit dem Unterschied, dass die XML-Datei am Ende nicht in ein PDF gepackt wird.

Fehlerbehandlung

Wenn ein Validator das XML oder das PDF moniert, gilt es, Verschiedenes zu prüfen.

Wird das XML moniert, prüfen Sie, ob die Strukturen korrekt sind, alle Namespaces richtig deklariert und zugeordnet sind und dass an den entsprechenden Stellen die richtigen Formate und Codes gemäß ZUGFeRD-Beschreibungen vorhanden sind.

Wird das PDF selbst moniert, muss an der Stelle geprüft werden, an der das PDF erstellt wird. Es konnte dann von Lobster Integration aus dem vorliegenden PDF kein valides PDF/A-3 erstellt werden.

Gründe dafür können schon vorab defekte PDF-Metadaten sein. Dies kann z. B. passieren, wenn mehrere unterschiedliche Programme an der Erstellung des PDFs beteiligt waren.

Wir arbeiten daran, dass diese externen Einflüsse keine Auswirkungen mehr auf die Erstellung von validen PDF/A-3 haben. Lassen Sie aber bei einem beanstandeten PDF Ihren Partner prüfen, ob er die ZUGFeRD annehmen würde.