Elektronische Rechnungen in Europa

Definition

Von elektronischen Rechnungen spricht man bei digital übertragenen Rechnungsdaten, typischerweise in Form einer Datei,von einem Sender an einen Empfänger. Dies kann zum Beispiel eine XML-Datei per E-Mail, ein PDF-Download von einem Web-Portal aber auch ein Computerfax zwischen zwei Computern sein. Wird ein spezielles Protokoll für die Übermittlung von elektronischen Rechnungen benutzt handelt es sich um Electronic data interchange, also immer noch um eine strukturierte elektronische Rechnung,die allerdings nicht zwangsläufig als Datei vorliegen muss.

Elektronische Rechnungen haben nichts mit einer elektronischen Zahlung zu tun, auch elektronische Rechnungen können also durchaus auch bar bezahlt werden. Obwohl Sie Rechnungen also in jedem Fall zahlen müssen weisen strukturierte und hybride elektronische Rechnungen also wenigstens sehr klar und maschinenlesbar aus was wann wem gezahlt werden müsste, in Onlinebankingprogrammen ist dann sogar eine Funktionalität “diese Datei bezahlen” denkbar.

Strukturiert vs unstrukturiert

Unstrukturierte Rechnungen sind menschenlesbar,wie beispielsweise die Bilddatei einer gescannten Papierrechnung.PDF-Dateien können zwar zusätzlich zu den Bilddaten einen Text enthalten, der beispielsweise nach einem Scan durch OCR gewonnen wird,aber selbst in diesem Text, mit dem immerhin Copy&Paste möglich wird, ist die Bedeutung beispielsweise der Beträge nicht maschinenlesbar eindeutig definiert. Das bedeutet dass PDF-Dateien mit und ohne Text grundsätzlich unstrukturiert sind: Eine Software könnte die Bedeutung eines Betrages höchstens mit einer bestimmten Wahrscheinlichkeit erraten. In der Regel macht dies mindestens eine manuelle Prüfung,gegebenenfalls sogar Korrektur erfoderlich.

Die Bedeutung in einer strukturierten elektronischen Rechnung drückt sich typischerweise in einer XML-Syntax aus: XML-Rechnungen sind typischerweise strukturiert, sie definieren Daten und Bedeutung aber typischerweise keine Layoutinformationen.

Strukturierte elektronische Rechnungen sind für B2G Rechnungen in einigen Ländern bereits verpflichtend und werden es ab 2020 in Deutschland ebenfalls werden.

Strukturierte Rechnungen können hybrid oder nativ sein.

Hybrid vs native

Eine XML-Rechnungsdatei die die Bedeutung aller Posten und Attribute trägt ist typischerweise einenative strukturierte elektronische Rechnung: Sie trägt meist keine Informationen wie sie optisch darzustellen ist. Da das Layout nicht definiert ist müsste der Empfänger, wollte er sie drucken, definieren dass beispielsweise die Gesamtsumme unten Rechts auf der Seite darzustellen sei. Es gibt viele native Formate und Versionen davon,UNCEFACT CII und UBL sind nur zwei Beispiele (und es gibt eine sehr interessante Aufstellung warum sich UBL und UN/CEFACT überhaupt auseinanderentwickelt haben.

Native Formate erfordern spezielle Lesesoftware, die allerdings auch in ERP-Programme integriert sein kann und die das jeweilige Format verstehen und dem Nutzer präsentieren können: Sie können die mathematische Korrektheit dann zwar automatisch nachrechnen aber ob das auch so bestellt war und geliefert wurde ist typischerweise noch ein manueller Schritt.

Hybride e-Rechnungen definieren sowohl Struktur als auch Layout. ZUGFeRD definiert das Layout beispielsweise in einer konventionellen PDF-Datei und kann mit jedem PDF-Anzeigeprogramm gelesen werden. Die Daten (welcher Betrag ist welcher Steuerbetrag und so weiter),ist zusätzlich in einer XML-Datei definiert die in die PDF-Datei eingebettet ist.

Aufgrund der weitverbreiteten PDF-Lesesoftware können viele Empfänger die Rechnungen wie üblich “manuell” nutzen (i.e. bezahlen).Die Informationen im XML-Teil können automatisch herangezogen werden, wenn die Software des Nutzers ZUGFeRD versteht.

Das FeRD hat Richtlinien für den Gebrauch elektronischer Rechnungen veröffentlicht. E.ON Energie Deutschland GmbH hat einen sehr einfachen (deutschen) Erklärfilm für hybrige E-Rechnungen veröffentlicht:

Pro hybride Rechnungen

  • Die Fallback-Lesesoftware (bspw. PDF Reader) ist meist weit verbreitet
  • Der Sender muss daher oft gar nicht zwischen verschiedenen Empfängergruppen (Geschäftskunden, Behörden, Privatkunden) unterscheiden die bestimmte Formate bevorzugen
  • Das Rechnungslayout kann den gedrucken Rechnungen nahe kommen oder identisch sein.
  • Absender und Empfänger können einfach Ausdrucke anfertigen.
  • Kein Umstellungsdatum notwendig: durch Ersatzformat kann einem Umstellung langsam vorgenommen werden
  • Inhalt und Layout können zusammen archiviert werden.
  • Scandienstleister können Rechnungsdaten mit dem erfassten Text- und dem Scan-Bild zusammenfassen
  • Zusätzliche rechnungsbegründende Unterlagen wie Stundenlisten oder Aufmaße können in derselben Datei geliefert werden
  • Die Rechnung kann digital signiert werden, was bspw. in Ungarn noch vorgeschrieben ist
  • Hybride Rechnungen sind generell auch im B2C Umfeld einsetzbar (wie bspw. bei EON oder Conrad der Fall).

Kontra hybride Rechnungen

  • Auch wenn Ausdrucke leicht zu erstellen sind ist eine digitale Archivierung des Original meist vorgeschrieben.
  • Hybride Rechnungen sind redundant, manipulierte Abweichungen zwischen Inhalt und Darstellung können automatisch nur schwer geprüft werden.
  • Höherer Aufwand der Erstellung einer Datei da nicht nur valides XML sondern auch valides PDF-A benötigt wird.
  • Ein kleiner Anteil hybrider Rechnungen erzeugen nur eine marginale Zeitersparnis.
  • In Unternehmen in denen der maschinenlesbare Teil genutzt werden soll ist es teils schwierig die Anwender davon abzubringen den vertrauteren menschenlesbaren Teil nicht zu nutzen.
  • Die Entscheidung ob der maschinen- oder menschenlesbare Teil genutzt wird muss in einigen Ländern wie Deutschland in der Prozessdokumentation festgehalten werden.
  • Viele Anwender wissen gar nicht, dass ein maschinenlesbarer Teil existiert
  • Ist der menschenlesbare Teil intakt wird der Absender mitunter nicht benachrichtigt wenn der maschinenlesbare Teil unvollständig oder defekt ist.
  • Hybride Rechnungen haben eine größere Dateigröße und erfordern ein Layout, bspw. einen Briefkopf.
  • ZUGFeRD 2.0, das europäische B2G-Rechnungen unterstützen soll, ist noch nicht verfügbar.

Nutzen

Magische Scans (nur hybride Rechnungen)
Scandienstleister können zusätzlich zur Texterkennung eine Rechnungserkennung anbieten und die Ergebnisse in einer Datei liefern.
Procure-To-Pay (hybride und native Rechnungen)
Wenn Firmen ERP-Systeme nutzen und darin

  • Bestellungen erfassen und ihren
  • Wareneingang verbuchen können
  • ZUGFeRD-Rechnungen automatisch bezahlt und dunkel verbucht werden

Die Rechnungen können dabei automatisch den Bestellungen zugeordnet werden.

Verbesserte Zusammenarbeit mit Lieferanten (hybride und native Rechnungen)
Einige Firmen haben einen signifikanten Anteil ihre Zulieferer überredet, ZUGFeRD-Rechnungen zu versenden.Das spart Zeit und damit Geld weil keine papierbehafteten oder unstrukturierten digitalen Rechnungen mehr bearbeitet werden muss.
Automatische Zahlung, automatisches Nachrechnen, automatischer Vorsteuerabzug (hybrid und nativ)
Es gibt keinen Bedarf mehr IBAN, Zahlungstermin, Betrag oder Verwendungszweck per copy&paste zu übertragen, es reicht die Datei(en) auszuwählen, die gezahlt werden sollen. Es gibt bspw. eine Machbarkeitsstudie für ein Plugin für die Open-Source Onlinebanking-Software Hibiscus oder ein kommerzielles Produkt namens CIB SEPArator das ZUGFeRD-Dateien in SEPA XML umwandelt.

E-Rechnung in Europa

B2G

Einige Länder haben Ihre Zulieferer und Dienstleister zu strukturierten elektronischen Rechnungen an die Behörden (B2G) verpflichtet, so zum Beispiel der Vorreiter Dänemark 2005, gefolgt von Schweden 2008, Spanien und Finland 2010 und Österreich sowie Italien 2014.

Schon 2009 konnte Dänemark glaubhaft machen mit der E-Rechnung jährlich 100 Millionen Euro zu sparen. 2014 entschied sich dann die EU mit Ihrer Richtlinie 2014/55 EU zur gesamteuropäischen Einführung.

Die EU Gesetzgebung definiert „elektronische Rechnung“ als “eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird, das ihre automatische und elektronische Verarbeitung ermöglicht”. Diese Definition („elektronische Rechnung“=„strukturierte elektronische Rechnung“) gibt es teilweise auch in der deutschen Legislative: Das e-Rechnungsgesetz bzw. die e Rechnungsverordnung spricht ebenfalls von „elektronische Rechnung“ i.S.v. „strukturierte elektronische Rechnung“ während das Umsatzsteuergesetz bei elektronischen Rechnungen sich sowohl auf strukturierte als auch auf unstrukturierte bezieht. Der nicht einheitliche Sprachgebrauch führt zu gefährlichem Halbwissen, beispielsweise einem Artikel der unterstellt, 68% der Unternehmer kännten nicht einmal die Definition der elektronischen Rechnung(der Artikel fragt nach elektronischer Rechnung, bezieht sich dann allerdings ausschließlich auf strukturierte elektronische Rechnungen). Quelle für den Artikel ist dabei wahrscheinlich diese Umfrage.

Die europäische Normungsbehörde CEN hat EN16931 veröffentlicht um EU/2014/55 normentechnisch zu ergänzen und zu begleiten, die von den nationalen Normungsbehörden – in Deutschland dem dazugehörigen Beuth-Verlag – gekauft werden kann .

Nach längerer Diskussion (Details) wurde entschieden, dass eine Ausgabe des ersten Teils des Standard, EN16931-1, der die Rechenregeln, Anzahl Dezimalstellen etc. festlegt, auch kostenlos zur Verfügung stehen soll.

Mittlerweile hat CEFDIGITAL auch eine sehr hilfreiche Liste aller Codes, die in EN16931 bspw. für Währungen, Länder oder Identifikationen verwendet werden können, nachgelegt.

Die Schweiz folgte mit elektronischen Rechnungen in 2016. Deutsche Bundesbehörden werden ab November 2018 elektronische strukturierte Rechnungen akzeptieren und ab November 2020 nicht-elektronische Rechnungen ablehnen.

B2B

Elektronische Rechnungen sind im B2B-Verkehr grundsätzlich freiwillig.

In Österreich gelten für elektronische Rechnungen ähnliche Vorschriften wie für Papierrechnungen,es kann mitunter sogar erlaubt sein elektronische Rechnungen auszudrucken und zu archivieren. In Deutschland gilt das nicht, aufgrund der GOBD müssen digitale Rechnungen auch digital archiviert werden.

In Ungarn müssen elektronische Rechnungen noch digital signiert werden.

Betreffs der Schweiz scheinen die Behörden zumindest an ZUGFeRD nichts auszusetzen zu haben, s.Simone Sporing’s Rede “Die E-Rechnung in Industrie und Handel” in 2018.

Slides

Für weitere Details zu den EU-länderspezifischen Regelungen s. bspw. das “EU compendium on e-invoicing retention” und die (deutsche) Sammlung rechticher Grundlagen für elektronische Rechnungen in der Sammlung der Rechtsgrundlagen für elektronische Rechnungen in der EG sowie die, besonders für B2G interessante CEFDIGITAL E-invoicing situation per country.

Das CEF Monitoring Dashboard zeigt einen e-invocing “readiness factor” der europäischen Länder.
Screenshot of the CEF Monitoring Dashboard

Situation in Deutschland

B2G

Wie im E-Rechnungsgesetz (geändertes E-Rechnungsgesetz im Bgbl 19/2017) und der entsprechenden Verordnung, der E-Rechnungsverordnung angeordnet werden strukturierte e-Rechnungen vis á vis den Bundesbehörden ab November 2020 in Deutschland verpflichtend.

Grundsätzlich sind alle Formate gemäß der Richtlinie 2014/55 EU erlaubt die in CEN 16931 aufgeführt werden und den deutschen Anfoderungen=dem nationalen Anforderungsprofil (CIUS, Liste)entsprechen. Erstes und bislang einzige deutsche CIUS ist die XRechnung. Das reicht für das ZUGFeRD 2 Profil EN16931. Weitere ZUGFeRD’s CIUS, bspw. für das Extended Profil sind noch im Entwurfsstadium.

Herr Hauschild hat 2018 die Situation der Länder und Kommunen in einem deutschen Vortrag (Folien) dargestellt und eine entsprechende deutsche Handreichung for the empfohlen.

In Deutschland sind bei der bundesweiten Neuregelung möglicherweise rund 300000 Zulieferer und Dienstleister betroffen.

B2B

Die deutschen GOBD legen Absendern und Empfängern digitale Archivierungs- und Sorgfaltspflichten auf.

Zu den wichtigesten Anforderungen gehört eine revisionssichere digitale Archivierung sowie eine Prozessdokumentation auf Sender- und Empfängerseite. BITKOMs hat die zehn wichtigsten Anforderungen zusammengefasst und u.a. einen umfangreichen Anforderungskatalog vis á vis Dokumentenmanagementsysteme veröffentlicht.

Einen 20-Minuten-Vortag zum Thema elektronische Rechnungen für KMUs findet sich auf Youtube.

Zusammenfassend dürfen digitalisierte=gescannte Rechnungen zwar vernichtet werden, allerdings nur unter bestimmten Bedingungen. So muss bspw. geklärt sein wer jeden einzelnen Scan auf Vollständigkeit und Lesbarkeit verantwortet und eine Vernichtung des Originals ist vor der
ersten digitalen Sicherungskopie untersagt.

Es gibt eine Musterverfahrensdokumentation zum Ersetzenden Scannen und eine generelle Musterverfahrensdokumentation zur digitalen Belegablage. Die DATEV hat in Musterprozessen die grundsätzliche Rechts- und Beweissicherheit digitaler Unterlagen dargelegt.

In Deutschland gibt es keine rechtliche Anforderung den Empfänger vor dem Versand einer elektronischen Rechnung um Erlaubnis zu fragen. Bei Akzeptanz, spätestens bei Zahlung der Rechnung bestätigt er konkludent, dass er elektronische Rechnungen akzeptiert und unterliegt implizit den zusätzlichen Regularien (Stichwort GoBD).Der Empfänger kann statt dessen explizit nach einer Papierrechnung fragen, die ihm in diesem Fall vermutlich ohne zusätzliche Kosten zugestellt werden muss.

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) ist ein anderer Name für ZUGFeRD 2.0.

Versionen

ZUGFeRD 1.0 wurde

  • in deutsch am 25.06.2014 veröffentlicht,
  • am 29.09.2014 gab es ein Korrigendum.
  • Die englische Übersetzung folgte am 19.01.2015.

ZUGFeRD 2.0 wurde am 11.03.2019 veröffentlicht.

Änderungen von ZUGFeRD 1 auf ZUGFeRD 2:

    1. ZUGFeRD 2 unterstützt europäische B2G invoices, namentlich EN16931.Alternativ zu ZUGFeRD (genauer der UN/CEFACT CrossIndustryInvoice D16B SCRDM uncoupled) sind auch UBL 2.1 und EDIFACT EN16931-konform.
    2. Die ZUGFeRD 2-Vorgängerversion wurde in Frankreich vom FNFE als “Factur-X 1.0” eingeführt.
    3. Der Dateiname der eingebetten XML-Datei hat sich von ZUGFeRD-invoice.xml (ZF1) zu factur-x.xml (Factur-X) beziehungsweise zugferd-invoice.xml (ZF2) geändert.
    4. Es ist jetzt “erlaubt” lediglich den XML-Teil zu versenden.
    5. 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.

  1. 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 .
  2. Die “root node” ändert sich dahingehend von CrossIndustryDocument auf CrossIndustryInvoice.
  3. 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
  4. Einige generische Elemente wurden durch spezifische ersetzt, beispielsweise wurde ID unterhalb von BuyerOrderReferencedDocument, DeliveryNoteReferencedDocument, AdditionalReferencedDocument und ContractReferencedDocument zur IssuerAssignedID.
  5. 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.
  6. Es wird keine XSLT-Stylesheet-Datei zur Umwandlung in HTML mehr ausgeliefert, aber die der XRechnung kann verwendet werden.
  7. 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.

Profiles

ZF unterstützt 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 Extended.

  • 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.

Geschichte


Beispiele

XRechnung

EN16931 definiert einen gemeinsamen Kern (Core Invoice) und nationale Erweiterungen, sogenannte Core Invoice Usage Specifications, CIUS. XRechnung ist die CIUS für Rechnungen an deutsche Behörden.

Beispiel: Die Core Invoice erfordert für den Empfänger lediglich die Pflichtangaben Land und Email-Addresse. Laut deutschem §19 UstG muss eine Rechnung allerdings die Postanschrift des Empfängers beinhalten. Die Postanschrift ist folgerichtig unter den Attributen,die deutsche CIUS, die XRechnung, verpflichtend macht.In der XRechnung gibt es auch zusätzliche nichtverpflichtende Angaben wie Skonto. Skonto ist zwar auf deutschen Rechnungen üblich, im restlichen Europa aber nicht gebräuchlich und deshalb nicht Teil der Core Invoice.

Die Anforderungen der XRechnung können in UBL oder UN/CEFACT XML erfüllt werden. Eine UN/CEFACT XRechnung (wie diese) basiert auf derselben Schema-Datei und ist identisch zu der eingebetteten XML-Struktur in einem ZUGFeRD 2.0 PDF
nach dem EN16931 Profile.

Name Veröffentlichungs datum Datei format Hybrid B2G B2B mit Abstimmung B2B ohne Abstimmung B2C XML Dialekt
XRechnung 1.0 2017-05-10 .xml n y y n n UBL, UN/CEFACT CII
XRechnung 1.1 2017-11-30 .xml n y y n n UBL, UN/CEFACT CII
ZUGFeRD 1.0 2014-06-25 .pdf y n y y y UN/CEFACT CII
ZUGFeRD 2.0 not yet .pdf y y y y y UN/CEFACT CII

Auf Heise finden Sie eine ZUGFeRD/XRechnung Gegenüberstellung.

Die XRechnung hat open-source XSLT style sheets veröffentlicht, die EN16931 XML in HTML umwandeln, und die auch mit ZUGFeRD 2 und Factur-X-Dateien funktionieren.

Weitere Quellen