ZUGFeRD und Software-Anbieter

Angesichts der hohen Zahl von Downloads der ZUGFeRD-Spezifikationen müsste der Standard längst in viele Anwendungsprogramme implementiert sein. Das ist leider nicht der Fall. Woran liegt es? Ein Grund könnte die – vermeintliche – Komplexität des Standards sein, die viele Software-Anbieter bremst. Insbesondere Anbieter von Lösungen für kleine Unternehmen, für Handwerker und Freiberufler, machen noch einen Bogen um ZUGFeRD.

Dabei lässt sich ZUGFeRD einfach aufzäumen. Auf der Seite der Rechnungs-Steller müssen sie anstatt zu drucken eine PDF generieren und in diese die geforderten Daten (Stamm- und individuelle Rechnungsdaten) standardkonform als XML einbetten. Die Ansprüche auf Empfängerseite scheinen vielfältiger und komplexer, tangieren Software-Anbieter aber nur marginal.

  1. Die ZUGFeRD-Rechnungen müssen zur visuellen Prüfung angezeigt werden
  2. Zur Eingangs-Prüfung, ob alle nach § 14 UStG geforderten Angaben in einer Rechnung enthalten sind, lesen sie XML-Daten automatisiert aus
  3. Zur Be- und Verarbeitung der Rechnungen wollen Empfänger unterschiedliche Teile der XML-Daten in ihre verschiedenen Anwendungen übernehmen
  4. Die Rechnungen müssen ins elektronische Archiv verfrachtet und auf den innerbetrieblichen Prüfpfad gesetzt werden

Für Punkt 3 müssen die Anwendungsprogramme ausgelegt sein. Deren Kopplung mit elektronischer Archivierung zählt inzwischen fast zum Standard. Viele Archivanbieter beherrschen sie ohne Mitwirkung der Software-Anbieter.

Anstatt für jedes Programm den Input von ZUGFeRD-XML zu programmieren ist es effizienter, ein Tool einzusetzen, welches die PDF anzeigt und erkennen lässt, ob alle geforderten XML-Daten  enthalten sind. Die zur weiteren Bearbeitung benötigten Daten werden entweder als XML oder als CSV-Datei an die Ziel-Applikation übergeben. Die Ablaufgrafik „ZUGFeRD-Rechnungseingangs-Management“ verdeutlicht dieses Verfahren. Es wird gesteuert vom „PDF-Cockpit“. Der Link zur detaillierten Beschreibung des PFD-Cockpits für ZUGFeRD- und andere PDF öffnet sich hier.

Ein Pluspunkt des PDF-Cockpits ist, dass sich damit selbst Non-ZUGFeRD-konforme PDF-Rechnungen in den Prüfungsprozess einschleusen lassen. Ein weiterer, dass es all denjenigen Unternehmen Komfort bietet, die beim Steuerberater buchen lassen. Zudem ist es schnell zu implementieren.

Software-Anbieter müssen den ZUGFeRD-Dateninput also nur im XML-, CSV- oder Datev-Format beherrschen.  Wenn sie das beherzigen wird aus dem heute (12/2016) noch eher lahmen ZUGFeRD bald ein flotter Traber.

2 Gedanken zu „ZUGFeRD und Software-Anbieter“

  1. Ein ganz wesentlicher Aspekt, der bei dieser Diskussion außer Acht gelassen wurde ist die Tatsache, dass der ZUGFeRD-Rechnungsempfänger ja eigentlich zwei Rechnungen erhält, eine im PDF-Format und eine im XML-Format. Diese sollten im Idealfall identische Daten ausweisen, nur dann gelten sie steuerrechtlich als eine einzige Rechnung. Aber wer prüft dies? In der Praxis wird sich der Rechnungsempfänger auf eine dieser beiden Rechnungsformate beschränken und muss dies auch in seinem Rechnungseingangsprüfungsverfahren so festlegen bzw. gegenüber einer evtl. Steuerprüfung so darlegen. Beschränkt sich der Rechnungsempfänger nun auf das XML-Format, so ist zwar eine Vollständigkeitsprüfung der Daten gemäß den Anforderungen für eine Rechnung relativ einfach implementierbar aber die Richtigkeit bzw. Plausibilität der Daten lässt sich nur sehr schwer automatisiert prüfen (es müsste zumindest ein Bezug z. B. zu einer EK-Bestellung o. ä. vorhanden sein). Man kommt in diesem Fall nicht über eine Art Visualisierung der XML-Daten herum, um eine manuelle Überprüfung durchzuführen. Da eine Rechnung auch jederzeit in ihrer Orginalform für einen evtl. Prüfer lesbar gemacht werden muss, würde der Rechnungsempfänger ein Visualisierungstool für die XML-Daten benötigen. Idealerweise sollte dieses zwanglos in eine ERP-Lösung integrierbar sein. Oder um es nochmal klar zu formulieren: Es darf nicht ohne entsprechende Prüfung davon ausgegangen werden, dass die Daten im PDF-Format identisch sind mit den Daten im XML-Format. Eine praktiable Lösung könnte so aussehen, dass im Rechnungseingangsprüfungsverfahren die XML-Daten automatisiert verarbeitet werden, dabei im ERP-System visualisiert werden, und das Ergebnis über eine Sichtprüfung mit der PDF-Datei auf Übereinstimmung geprüft wird. In diesem Fall kann dann bei einer Prüfung auch die PDF-Datei (ohne XML-Daten) als (geprüftes) Rechnungsdokument dem Prüfer vorgelegt werden.

    1. Sehr geehrter Herr Hübner,
      danke, genau diese Diskussion müssen wir zu Ende bringen, damit das ZUGFeRD endlich zum Laufen kommt. Haben Sie sich das Ablaufschema bei dem kommentierten Artikel angesehen? Genau so läuft nach unserer Erfahrung der Rechnungsprüfungsprozess. Die wenigsten Unternehmen werden ZUGFeRD-Rechnungen ohne visuelle Prüfung in Ihre Systeme pumpen. Und wenn doch, ist es nicht so schlimm. Die Gefahr, dass ein Rechnungsteller aus seinem ERP zwei differierende Versionen (PDF/XML) erzeugen wird, wird gegen null tendieren. Bei ZUGFeRD-Druckertreibern ist sie minimal. Und wenn es passiert, fällt es dem Ersteller auf die Füße. Er muss dann die USt doppelt abführen – theoretisch. XML zu visualisieren (über die Dauer der Aufbewahrung) wäre aufwändig, kontraproduktiv und ist überflüssig. Die GoBD geben in RZ 131 klar vor, dass eingehende elektronische Dokumente in dem Format aufbewahrt werden müssen, in dem sie eingegangen sind. Das heißt in der Praxis: die PDF ist immer da. Einer sehr kompetenten Quelle im Bayerischen Landesamt für Steuern zufolge werden sich Prüfer immer am im Archiv liegenden Image orientieren, wenn sie einen Buchungssatz hinterfragen wollen. Die XML-Daten betrachtet man dort als nützliche Buchungshilfe für die Anwender; nichts weiter.

Kommentare sind geschlossen.