Ist ZUGFeRD ein Rohrkrepierer?

Der Inhalt des XML-Teils einer ZUGFeRD 2.0 -Rechnung kann verschiedene Detailierungsgrade (Profile) umfassen:

• Minimum
• BASIC, BASIC WL
• COMFORT (EN 16931)
• EXTENDED

 Ab dem Level „COMFORT“ enthält die Rechnung so viele Informationen, dass diese buchhalterisch sinnvoll verbucht werden kann (z. B. Aufteilungsbuchungen). Die Level Minium und Basic WL sind in Deutschland umsatzsteuerlich nicht anerkannt.

Der Level „EXTENDED“ muss hinsichtlich einer Verarbeitung genau geprüft werden, da er individuelle Vereinbarungen enthalten kann, die nur zwischen Rechnungsaussteller und Rechnungsempfänger gelten.

Nun ist die Idee der elektronischen Rechnung ja nichts Neues. Der EDI-Fact-Standard existiert bereits seit mehreren Jahren, das Open Trans-Format (entwickelt vom Fraunhofer Institut) gibt es seit 2001.

Warum noch einen Standard?

Der Gründe für die Entwicklung des ZUGFeRD-Standards lassen sich wie folgt wiedergeben:

• Der Benutzer erhält ein Rechnungsbild, das für die Langzeitarchivierung zugelassen ist
• Die XML-Struktur des Formates kann weitaus mehr Informationen aufnehmen,
  als dies z. B. ein EDI-Format kann.

Stand Heute

Das ZUGFeRD-Forum Zugferd-Community betont zwar, dass tausende Unternehmen die Entwicklerdokumentation heruntergeladen haben, aber nirgends ist eine genaue Zahl zu finden, wie viele Unternehmen Rechnungen im ZUGFeRD-Format ausstellen. Die Unterstützerliste auf der ZUGFeRD-Webseite umfasst auch fünf Jahre nach der Einführung des ZUGFeRD-Standards nur wenige hundert Unternehmen.

Aus unserer – zugegeben subjektiven - Sicht setzt sich das Format nur sehr, sehr langsam durch. Andere Formate, wie beispielsweise EDI-Fact und Open Trans, werden weitaus häufiger genutzt als ZUGFeRD.

Betrachtet man das ZUGFeRD-Format genauer, lässt sich relativ leicht erklären, warum die Verbreitung nur schleppend stattfindet:

1. Es existieren bereits Standards
Elektronische Rechnungen werden seit Jahren erfolgreich mittels existierender Standards erstellt und versendet.  Es gibt für die Rechnungsaussteller zunächst keinen wirklichen Grund, ein neues Format zu unterstützen. Es sei denn, man benötigt Features, die nur das ZUGFeRD-Format anbietet.

2. Teuer in der Entwicklung
Da ZUGFeRD letztendlich ein eigener PDF-Standard ist, benötigt man für die Erstellung der Rechnung besondere Entwicklerwerkzeuge (SDK´s = Software Development Kit), die nicht gerade billig sind. Die althergebrachten e-Rechnungen lassen sich i. d. R. mit den Bordmitteln der verbreiteten Programmiersprachen leicht erzeugen.

3. Speicherintensiv
Der Rechnungsempfänger erhält mit ZUGFeRD zwar nun ein Bild der Rechnung, gleichzeitig ist ein PDF-A auch speicherintensiver als normale PDFs. Da es sich ja auch noch nach 10 Jahren noch öffnen lassen muss, werden bei der Erstellung des PDF alle Fonts, Grafiken etc. eingebunden. Je nach System, in dem diese Rechnungen gespeichert werden, können die Speicherkosten im Laufe der Jahre ziemlich hoch werden.

4. Fehlende Verarbeitungsmöglichkeiten in den Finanzbuchhaltungssystemen
Während die etablierten e-Invoicing-Formate (hier vor allem EDIFact) für die Rechnungsübermittlung zwischen größeren Unternehmen eingesetzt werden sollten, ist ZUGFeRD ja als Jedermann-Format gedacht. Das setzt aber voraus, dass jedermann (also jede Warenwirtschaft) diese Rechnungen erzeugen und diese wiederum von jedermann (also jeder Finanzbuchhaltung) verarbeitet werden können.

Trotzt der maschinell gut auslesbaren Daten schaffen es nur wenige der im Mittelstand eingesetzten Finanzbuchhaltungssysteme, mehr als lediglich die Basisdaten wie Rechnungs-Nr., Kreditor, Betrag, Rechnungs-Datum etc. auszulesen. Damit lassen sich dann allenfalls Buchungsvorschläge ableiten, eine vollautomatische Verarbeitung ist damit sicherlich nicht möglich. Insbesondere die an sich bis an die Zähne technisch hochgerüsteten Steuerkanzleien haben hier noch Nachholbedarf.

5. Fehlinterpretationen und Ausbildung von Dialekten
Da bereits der COMFORT-Standard eine Vielzahl von Datenfeldern bereitstellt, kommt es regelmäßig zu Fehlinterpretationen des ZUGFeRD-Formats. D. h., dass bestimmte Felder mit einem anderen Inhalt befüllt werden, als der für den Sie bestimmt sind.  Ebenso kommt es vor, dass der Inhalt der XML-Datei nicht mit den Beleginformationen übereinstimmt. Auch Vorzeichenfehler sind regelmäßig zu finden. So wird aus einer Rechnungskorrektur schnell eine weitere Rechnung.

Der/die aufmerksame Leser/in wird nun anmerken, dass dies ja vor allem datentechnische Probleme sind, die keineswegs zwingend im ZUGFeRD-Format begründet liegen. Ja und Nein:  Unserer Erfahrung nach kontrolliert der Mensch immer nur das Belegbild (weil bequem lesbar) und ignoriert den XML-Anhang geflissentlich.

Wir hatten jüngst den Fall, dass ein Rechnungsaussteller vergessen hatte, den Leistungszeitraum und die Steuernummer auf die Rechnung zu schreiben – diese sind allerdings Pflichtangaben in einer Rechnung. In einem solchen Fall stellen nun das PDF und der zugehörige XML-Anhang formaljuristisch unterschiedliche Belege dar.  Ein Graus …

Bei den klassischen Formaten gibt es kein Belegbild, d. h., dass der Anwender entweder die Daten direkt in Augenschein nehmen muss oder die Daten durch ein entsprechendes Programm zu einem Belegbild aufbereitet werden. Ein auseinanderlaufen der Rechnungsdaten ist in diesem Fall nicht möglich - es gibt ja nur die strukturierten Rechnungsdaten.

Fazit:

Um die provokante Frage im Titel des Blogbeitrags „Ist ZUGFeRD ein Rohrkrepierer?“ zu beantworten: Nein, ganz sicher nicht.

Das ZUGFeRD-Format wird sich, wenn auch langsam, seinen Platz unter den e-Invoicing-Formaten erkämpfen.  Insbesondere der Umstand, dass ZUGFeRD von Behörden akzeptiert wird unterstreicht den politischen Willen, dieses Format in der Wirtschaft zu etablieren.

Im Zuge der Digitalisierung im Allgemeinen und der Vereinfachung von kaufmännischen Prozessen im Besonderen sollte sich jedes Unternehmen mit dem Thema e-Invoicing auseinandersetzen. Dabei ist – wie immer in der Digitalisierung - nicht eine Software, sondern ein funktionierender Prozess gefragt.

Unternehmen, die Rechnungen erstellen und versenden, empfehlen wir:

• Prüfen Sie, welches e-Invoicing-Format Ihre Kunden am besten verarbeiten können.
  (im B2B Verkehr unbedingt auch EDI-Fact und Open Trans 2 prüfen).
• Wenn Sie Rechnungen im ZUGFeRD-Format erstellen: Achten Sie peinlichst genau darauf, dass die Daten im PDF- und im XML-Teil identisch sind.
  Prüfen Sie dies regelmäßig, insbesondere bei Änderungen am Aufbau der Rechnungen
• Berechnen Sie die langfristigen Speicherkosten der von Ihnen erstellten Rechnungen.
  Auch der Rechnungsemittent muss seine Rechnungen 10 Jahre aufheben.
• Denken Sie daran, die elektronischen Rechnungen GoBD-konform zu archivieren
• Stellen Sie Ihren Kunden die Rechnungen so bereit, dass diese elektronisch heruntergeladen werden können (technischer Stand: Bulkdownload mit Meta-Daten per API).

Für Unternehmen, die elektronische Rechnungen empfangen, empfehlen wir:

• Prüfen Sie die eingehenden ZUGFeRD-Rechnungen stichprobenartig auf alle Merkmale nach
  §14(4) Umsatzsteuergesetz (Pflichtangaben auf einer Rechnung):
  Prüfen Sie ebenfalls, ob die Daten aus PDF und XML-Anhang übereinstimmen (achten Sie bei Rechnungskorrekturen auf die Betragsvorzeichen!)
• Im Rahmen der GoBD-Verfahrensdokumentation sollten Sie die ZUGFeRD-Rechnungen neuer Lieferanten immer einer initialen Prüfung unterziehen.
  Dokumentieren Sie initiale und laufende Prüfungen.
• Berechnen Sie anhand der durchschnittlichen Größe der ZUGFeRD-Rechnungen die langfristigen Speicherkosten. Insbesondere bei Speicherung über externe Dienstleister
  (hier werden bis zu 6,00 € pro GB/Monat verlangt), kann das schnell teuer werden.
• Sofern Sie ZUGFeRD-Rechnungen in größerem Umfang erhalten, prüfen Sie, ob diese mit einer entsprechenden Software vollautomatisch und vollständig verbucht werden können.
  Das eigentliche Finanzbuchhaltungssystem übernimmt nur noch die fertigen Buchungssätze.
• Prüfen Sie, ob Sie die Rechnungen Ihrer Lieferanten auch maschinell abrufen und ggf. gleich archivieren können (Rechnungsportal mit API Funktionalität).
  Tipp für Unternehmen: Per API können Sie die Rechnungen regelmäßig abrufen und direkt in den Workflow ihres DMS einstellen.

Gerade im Bereich der kleineren und mittelständischen Unternehmen lassen sich erst durch den Einsatz solcher Werkzeuge die Vorteile einer Automatisierung richtig realisieren (bis zu 99.x % Zeiteinsparung).