Kontext und Zusammenhänge der elektronischen Rechnung
Die Geschichte der elektronischen Rechnung ist eng mit der Geschichte der Informationstechnologie (IT) verbunden. Als es noch Pferde und Kutschen auf den Straßen gab, wurden bereits die ersten elektronische Nachrichten per Telegraph übertragen, um Blumenlieferungen zu beauftragen und in Rechnung zu stellen. Ähnlich ging es ab den 1980igern in den Automobil- und Konsumgüter-Branchen mit der Einführung des elektronischen Datenaustauschs oder auf Englisch Electronic Data Interchange (EDI). Das Zeitalter des Internets fügte neue EDI-Übertragungsprotokolle (z.B. EDIINT AS2, AS4), Formate (XML) und Dienstleistungsformen (Software as a Service, Marktplätze) hinzu. In den meisten Unternehmen wuchs dadurch die Komplexität der Anbindungen, so dass elektronische Nachrichten langsam selbst zum Engpass wurden, von dem was sie lösen sollten: Die Automatisierung der Geschäftsprozesse.
In den Jahren 2000 hatte die Europäische Union (EU) bereits diese Entwicklung gesetzlich begleitet. Sie hatte EU-weit die Gültigkeit der elektronischen Signatur gesichert (1999/93/EG) und die Anforderungen an Rechnungsinhalten harmonisiert (2006/112/EG). Im nächsten Schritt fiel auf, dass die Digitalisierung an mangelnder Interoperabilität stockte. Die Vielfalt der XML und EDI Formate nahm stetig zu. EDI-Dienstleister und Marktplätze konnten sich nicht leicht über Vertragliches und Technisches abstimmen. Manche verweigerten ganz die Zusammenarbeit. „Die Vielzahl nicht interoperabler Normen führt zu übermäßiger Komplexität, Rechtsunsicherheit und zusätzlichen Betriebskosten für Wirtschaftsteilnehmer“ stellte die EU fest.
Das führte zum Start des Peppol (Pan-European Public Procurement OnLine) Projekts in 2008. Über 3 -4 Jahren traf sich eine Gruppe von Experten regelmäßig in Brüssel: Teilnehmer waren Vertreter von staatlichen IT-Abteilungen, von EDI-Dienstleistern und Branchen. Sie listeten die Schwierigkeiten auf und erarbeiteten einen Lösungsansatz. Dieser führte 2010 zu der Gründung des openPeppol-Vereins, um einen rechtlichen und technischen Rahmen für die Interoperabilität von Providern zu erarbeiten und weiterzuentwickeln. Erfahrungen aus Norwegen und Dänemark belegten Anfang der Jahren 2010 mit Zahlen, dass eine gesetzliche Verpflichtung zugunsten von ein bis zwei Formaten eine kritische Adoptionsmasse schaffen kann. Es zeigte auch, dass diese Verpflichtung eine 1000-fache Wirkung hatte, wenn nicht nur die Rechnungsempfänger verpflichtet wurden, sondern auch ihre Lieferanten.
Dies führte zur Richtlinie 2014/55/EU. Diese sieht vor, dass alle öffentlichen Auftraggeber der EU in der Lage sein müssen, elektronische Rechnungen zu empfangen[1]. Im Kontext der Richtlinie ist die Definition der elektronischen Rechnung auf strukturierte Rechnungen begrenzt[2]: „Eine bloße Bilddatei sollte nicht als elektronische Rechnung im Sinne [der] Richtlinie gelten.” Reine PDF-Dateien sind somit ausgeschlossen. Die EU überließ weitere Spezifikationen dem Europäischen Komitee für Normung (CEN), der mit der Norm EN 16931 zwei Syntaxe definierte:
- UN/CEFACT XML CII D16B
- ISO/IEC 19845 (aka UBL 2.1)
Somit wurde der Weg für nationale Umsetzungen geebnet. Den einzelnen EU Staaten wurde überlassen, ob eine gesetzliche Lieferanten-Verpflichtung mit eingeführt werden sollte. Die nationalen Ausgangssituationen waren in dieser Hinsicht sehr unterschiedlich und prägten somit auch deren Umsetzung:
- Österreich, Dänemark, Frankreich, Italien, Slowenien, Spanien hatten längst eine gesetzliche Lieferantenverpflichtung eingeführt (B2G[3]). Dort waren bereits andere Syntaxe und Syntaxversionen im Einsatz als die, die der CEN erarbeitet hatte. In der Praxis kommen die EU-Syntaxe erstmal hinzu. Manche Staaten wie Dänemark haben eine Migration in Richtung der EU-Syntaxe geplant und schalten die eigenen nationalen Formate nach einer Übergangsphase ab. Andere Länder nehmen sich mehr Zeit.
- Belgien, Niederlande, Schweden und nicht zuletzt Deutschland hatten solche B2G-Verpflichtungen noch nicht und konnten somit die EU-Norm als Basis für ihre Programme heranziehen. Diese Staaten definierten die Peppol/UBL Variante als bevorzugte Syntax und Peppol als bevorzugtes Transportmittel, ganz nach den Vorgaben von openPeppol. Sie gingen auch teilweise den Schritt einer Verpflichtung der Lieferanten.
In Deutschland gilt diese gesetzliche Lieferantenverpflichtung aktuell für den Bund, Bremen und Niedersachsen.
Abbildung: Meilensteine der elektronischen Rechnung in Deutschland.
Manche Bundesländer haben sich gegen eine gesetzliche Verpflichtung der Lieferanten entschieden – was einzelvertragliche Verpflichtungen nicht ausschließt. Bei einigen Bundesländern steht die Entscheidung noch aus. Eine Übersicht der gesetzliche Umsetzung der EU-Richtlinie auf Länderebene ist auf der Webseite der Koordinierungstelle für IT-Standards (KoSIT) zu finden[4]. Die Kanzlei Peters, Schönberger & Partner (PSP) München beschreibt rechtliche Aspekte und Anforderungen der Umsetzung ausführlicher in einem Leitfaden, der ebenfalls lesenswert ist[5].
Wenn keine gesetzliche Lieferantenverpflichtung vorliegt, sollten die Lieferanten trotzdem beachten, dass andere Verpflichtungen auf sie zukommen können. Öffentliche Auftraggeber können bei Vertragserneuerung eine Klausel zur elektronischen Rechnung einführen, auch für Rechnungen unter 1000 €. Bundesstellen werden sicherlich darauf drängen, dass Lieferanten alle ihre Rechnungen elektronisch senden. Wenn Sie sich daran machen, Ihre Rechnungsvolumen für das Projekt einzuschätzen, ist dies ein wichtiger Aspekt.
Was ist die XRechnung?
Trotz EU und openPeppol Vorgaben gibt es nationale Besonderheiten. In dem Fall von Deutschland fiel zum Beispiel auf, dass die EU-Norm ein Feld für Skontodaten als überflüssig eingestuft hatte. Daher die Auslegung einer eigenen Spezifikation für Deutschland: Die XRechnung. Diese fügt der EU-Norm ein Feld für Skonto hinzu und legt fest, ob für Deutschland bestimmte Felder der EU-Norm nur vorkommen dürfen oder Pflicht sind. Die Fachbegriffe dazu sind:
- Konformant zur EU-Norm: Das ist der Fall von Deutschland, denn ein Feld wurde hinzugefügt
- Kompliant mit der EU-Norm: Nur das Ein- und Ausschalten von bestimmten Feldern der EU-Norm. Das ist der Fall für die meisten Länderspezifikationen (sogenannte Core Invoice Usage Specifications, CIUS), wo die Norm nur geringfügig angepasst wurde, z.B. durch das Setzen von bestimmten Feldern von optional auf Pflichtfelder oder umgekehrt.
Abbildung: Die XRechnung ist komform zur EU-Norm.
Konkret heißt dies, dass eine deutsche Behörde in der Lage sein muss, die Syntaxen aus der EU-Norm aber auch aus der XRechnung empfangen zu können. Also nicht nur zwei Syntaxe, sondern vier. Alles halb so schlimm, denn im Rechnungseingang lässt sich ein optionales Skonto-Feld leicht abhandeln.
Gäbe es jetzt also nicht bereits ZUGFeRD, würde in Deutschland nun Einheit mit den EU-Vorstellungen herrschen und es gäbe einen klaren Weg in Richtung Peppol.
ZUGFeRD
ZUGFeRD steht für den Zentralen User Guide des Forums elektronische Rechnungen Deutschland. ZUGFeRD ist nicht nur ein langes Akronym, es ist auch die kluge Idee ein strukturiertes und unstrukturiertes Format zu vereinigen. Das PDF-Bild der Rechnung kann als Träger für eine strukturierte XML Rechnung dienen. Der Rechnungsempfänger erhält ein PDF und eingebettet eine strukturierte UN/CEFACT XML. Ihm wird überlassen, ob er das eine oder das andere verwendet, ob er den Rechnungseingang manuell tätigt oder automatisiert. Mit ZUGFeRD 2.x ist die Conformance aber auch je nach Variante zugleich die Compliance zur EU-Norm gesichert. Denn ZUGFeRD gibt es in den Variationen Basic, Comfort, Extended.
Abbildung: Alle Wege der XRechnung
Da ZUGFeRD in Deutschland länger als Peppol bekannt ist und nur wenige deutschen Unternehmen Erfahrungen mit Peppol sammeln konnten, werden Sie oft auf Statements stoßen, die sich wie Halbwahrheiten anhören:
- „Nur ZUGFeRD ist international“ - unterstellend, dass Peppol es nicht ist. Zur Erinnerung stand das Peppol Akronym ursprünglich für Pan-European Public Procurement Online. Mittlerweile hat Peppol die Grenzen von Europa gesprengt: Singapur, Australien und Neuseeland zählen seit 2019 auch zu den Peppol Ländern.
- „Nur ZUGFeRD kann jeder empfangen, weil jeder eine E-Mail Adresse hat.“ Korrekt, aber per E-Mail erhalten sie keine rechtskräftige Empfangsbestätigung. Die E-Mail Verschlüsselung ist für Rechnungssender und Empfänger umständlich und wird daher meistens nicht implementiert.
- „Nur ZUGFeRD ist in Deutschland verbreitet. Meine Kunden verlangen ZUGFeRD, nicht Peppol.“ Korrekt, aber der Wind dreht sich gerade. Viele SAP-Nutzer erhalten derzeit erste Briefe von öffentlichen Auftraggebern, die Peppol als Option auflisten.
Unsere persönliche Prognose: Mehrere EDI-Anbieter in Deutschland werden Peppol bis Ende 2020 unterstützen können und die Pro und Cons werden bald ausbalancierter ausfallen, denn beide Varianten machen Sinn.
Es stellt sich also die Frage: Wo genau sollte man E-Mail bzw. ZUGFeRD und wo Peppol zum Einsatz bringen?
Als Rechnungsteller werden Sie pro Rechnungsempfänger entscheiden wollen und müssen. Welche Eingangskanäle bietet mein Rechnungsempfänger an? Ist Peppol dabei, dann ist es eine bessere Option, denn:
- Rechnungen werden systematisch inhaltlichen Kontrollen unterzogen (sogenannte Schematron-Checks, die nicht nur die Struktur, sondern auch inhaltliche Abhängigkeiten prüfen[6]). Zum Beispiel: Stimmt die Summe der einzelnen Zeilenbeträge mit dem angegebenen Gesamtbetrag der Zeilenbeträge?
- Rechnungen werden sicher und verschlüsselt übertragen.
- Der Empfang beim Dienstleister des Rechnungsempfängers wird mit einer Empfangsbestätigung bestätigt.
- Peppol entwickelt sich funktional weiter. Geschäftsbezogene Ablehnungen von Rechnungen werden demnächst in der Standardumsetzungen vorhanden sein, sowie auch andere Geschäftsdokumente wie Bestellungen und Lieferavise.
- Die technische Umsetzung ist viel einfacher als eine EDI-Anbindung hat aber dieselbe Integrationstiefe wie eine EDI-Rechnung. Lediglich die Peppol-ID des Empfängers ist in den Kundenstammdaten einzupflegen.
Ist der Rechnungsempfänger (noch) nicht im Peppol-Netzwerk angemeldet, dann greifen die Vorteile des E-Mail Versands. Umsetzungsbeispiele z.B. für die Anbindung von Geschäftspartnern in nicht Peppol-Ländern oder mit kleineren Kunden machen sicherlich Sinn. Von daher sollte Ihre Organisation beide Zustellungsverfahren unterstützen, um Kunden leicht von dem einen auf das andere umstellen zu können.
Was bietet die SAP eigentlich für die XRechnung, für Peppol und ZUGFeRD an?
Bereits 2013 bot SAP eine Consulting Lösung für das Versenden von ZUGFeRD Rechnungen an. Seit 2019 gibt es Peppol und E-Mail Delivery in der Form eines Standard Produkts: „SAP Document Compliance, cloud edition“ (bis April 2020 bekannt unter den Namen "SAP Document Compliance, invoicing option for Peppol"). Viele international tätige SAP Anwender kennen SAP Document Compliance als „on-premise edition“, bzw. unter dem ehemaligen Namen „eDocuments“. In Kombination mit der SAP Cloud Platform ermöglicht SAP Document Compliance die Ende-zu-Ende Anbindung von Regierungen oder Geschäftspartnern in mehr als 15 Ländern.
Der Grund für ein separates Peppol/E-Mail Delivery Produkt ergab sich daraus, dass die Ein- und Auslieferung in/aus dem Peppol-Netzwerk nur von zertifizierten Providern, wie SAP, angeboten werden darf.
Abbildung: Implementierungsmöglichkeiten hängen von Länderszenarien bzw. davon ab, ob SAP als Provider auftreten kann/muss.
Die Cloud Edition beinhaltet die Nutzungsrechte des benötigten Mapping-Tools, SAP Application Interface Framework (AIF) und des on-premise Konnektors. Für Nutzer aus den Fachabteilungen sehen die Peppol- und E-Mail-Delivery-Szenarien im Cockpit genauso aus wie Szenarien aus anderen Ländern.
Wichtig ist auch, dass die cloud edition nicht nur Deutschland und die Rechnungstellung abdeckt. Belgien, Niederlande, Norwegen, Schweden sind auch bereits dabei. Österreich und Dänemark werden bis Ende des zweiten Quartals 2020 für den Release an Pilotkunden erwartet[7]. Die Cloud Edition deckt auch den Rechnungsempfang und dessen automatisierte Weitergabe an SAP Invoice Management by OpenText ab. Andere Rechnungsverarbeitungslösungen können in ähnlicher Weise angebunden werden.
Was genau beinhaltet die Cloud Edition für Deutschland?
- Die Rechnungstellung mit den Billing-Modulen SD, FI, IS-U und Convergent Invoicing:
- über die Peppol-Infrastruktur in XRechnung/UBL Syntax für die Rechnungstellung an z.B. inländische Behörden (mittels Leitweg-ID) und Geschäftspartner (mittels USt-ID)
- über die Peppol-Infrastruktur mit dem Peppol-Pflicht-Profil (BIS BIlling 3.0) für die grenzüberschreitende Rechnungstellung von Deutschland aus an ausländische Behörden und Geschäftspartner
- über E-Mail als PDF inklusiv UN/CEFACT XML. Die SAP Lösung folgt der XRechnung-Spezifikation des KoSIT, die von deutschen Behörden vorgeschrieben wird. Mittlerweile entspricht dies ZUGFeRD 2.1 Comfort in XRechnung-Variante.
- Den Rechnungsempfang über die Peppol-Infrastruktur von XRechnungen und von BIS BIlling 3.0 Rechnungen.
Seit März 2019 gibt es für die Installation des SAP Document Compliance ein TCI-Paket, das die Umsetzung für Neukunden deutlich vereinfacht (siehe 2861425 - Transport based Correction Instructions (TCI) for the eDocument Framework (1 to 22) and eD...).
Abbildung: Ende-zu-Ende Peppol-Prozess und dazugehörende -Implementierungspakete
Viele Beratungshäusern, neben SAP Consulting, die SAP Document Compliance bereits weltweit implementiert haben, kennen auch Peppol und können sowohl bei Erst- als auch bei Deltaimplementierungen unterstützen.
Die Produkt-Dokumentation finden Sie unter help.sap.com:
- Peppol Service Guide
- Installing and Configuring the SAP Cloud Platform Cloud Connector
- SAP S/4HANA Customizing für eDocuments, bzw. SAP ECC eDocument für Deutschland
Pferde und Kutschen sind heute nur noch im Sport und als Hobby im Einsatz. Gehen Sie auch bei der elektronischen Rechnung mit der Zeit.
Vertriebliche Informationen zu „SAP Document Compliance, cloud edition“ können Sie über Ihren üblichen SAP Ansprechpartner (Account Executive oder SAP Reseller) erhalten.
[1] Es gibt Feinheiten zum Umfang der Richtlinie. Die Verpflichtung betrifft nur Vergaben, die nach Unionsrecht europaweit ausgeschrieben werden müssen (sogenanntes oberschwelliges Vergabeverfahren). Staaten können den Umfang bei der nationalen/regionalen Umsetzung erweitern.
[2] In Deutschland ist die elektronische Rechnung in der Verordnung über die elektronische Rechnungsstellung im öffentlichen Auftragswesen des Bundes als ein Dokument definiert, das „in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und [dessen] Format die automatische und elektronische Verarbeitung […] ermöglicht.“
[3] Im Fachjargon der Rechnungsexperten auch Business-to-Government (B2G) Verpflichtung genannt.
[4] Übersicht der KoSIT zur Umsetzung der EU-Richtilinie 2014/55/EU: https://www.xoev.de/xrechnung/der_standard_und_unterstuetzende_produkte/rechtliche_grundlagen_der_xr...
[5] PSP München, Die elektronische Rechnung in der öffentlichen Verwaltung – Ein Leitfaden für die praktische Umsetzung (Version 1.4): https://www.psp.eu/artikel/354/die-elektronische-rechnung-in-der-oeffentlichen-verwaltung/
[6] Die SAP Lösung für den E-Mail Versand stellt solche Kontrollen sicher, um auch auf diesem Weg eine hohe Datenqualität zu sichern.
[7] Planungsstand April 2020. SAP behält sich das Recht vor, dies zu ändern.
PS: Dieser Beitrag wurde mit Hilfe von karl.hartmann erstellt. Eine englische Version dieses Blogs ist hier zu finden (for English, click here).
- SAP Managed Tags:
