Das föderale "Architekturkonzept E-Rechnung"

20.06.2017

"DAS ARCHITEKTURKONZEPT eRECHNUNG für die föderale Umsetzung in Deutschland – entwickelt vom Bund und dem Land Bremen" ist da: http://bit.ly/2rAkWAa (Version 1.0 Kooperationsprojekt Bund-Bremen auf Basis der Arbeit des EG 3: Technische Ausgestaltung XRechnung in Deutschland)! Und wie erwartet, wenn die Bremer Freunde dabei sind, wurden alle, ja allen möglichen und denkbaren Sonderlocken der öfffentlichen Verwaltung berücksichtigt. Beginnend beim deutschen Format xRechnung (haben wir da eine europäische Norm die bis Ende 2018 verbindlich umgesetzt werden muss?) über Einreichung mittels De-Mail (ja, wo gibt es denn das?) bis hin zur Signatur-Prüfung mit dem liebgewonnenen TR-ESOR -Verfahren für qualifizierte elektronischen Signaturen (und die Steuerbehörden schreiben eindeutig in den GoBD dass man keine elektronische Signatur bei Rechnungen braucht). Das Konzept führt hierzu aus: "Überprüfung der qualifiziert elektronischen Signaturen der Nachrichten sowie der mitgesendeten Anhänge auf Gültigkeit nach SigG veranlasst. Für die Zertifikatsprüfungen greift der GMM auf die Anwendung Governikus des IT-Planungsrates zu. Damit ist auch die Verifikation europäischer Signaturen und Zeitstempel gewährleistet." Übrigens taucht hier wieder der schon abgeschriebene De-Safe auf und dazu ein De-Ident-Verfahren. Dazu ein Vorgehen, dass nur angemeldete, authorisierte Benutzer E-Rechnungen einreichen lässt, wo natürlich die Verweise auf die Einbindung der eID nicht fehlen dürfen. Und natürlich dürfen auch die Governikus-Komponenten hier ein neues Einsatzfeld finden (immerhin sollen ja auch zukünftig alle europäischen elektronischen Einschreib-Zustelldienste unterstützt werden ... und in Bremen spart man sich so ein Vergabe-Verfahren, weil man schon Vorhandenes nutzt). Ach ja, das xRechnung-Format ist auch noch nicht abschließend definiert, aber dafür soll es ein Webformular geben, um xRechnungs-Daten manuell eingeben zu können. Das ganze zentral implementiert um von dort die E-Rechnung an den Zielempfänger weiterzuleiten - wobei dieser aber unter Umständen die geprüfte xRechnung gar nicht im Freigabecenter seines eigenen System automatisiert empfangen und verarbeiten kann (und im Zweifelsfall die xRechnung dann ausdruckt). Das Ganze hat dann noch den Anspruch: "Das Konzept soll auch von anderen Ländern und Kommunen als Blaupause für die föderale Umsetzung der EU-Richtlinie 2014/55/EU zur Entgegennahme von elektronischen Rechnungen genutzt werden können." Dann doch bitte wenigstens das Europa-weit genormte Format des CEN nutzen oder Lösungen wie PEPPOL bauen (das gibt es nämlich schon und auch hier ist Deutschland als Partner beteiligt).
Es werden also alle Register der elektronischen Verwaltungsbürokratie gezogen.Es wurde ein aufwändiges Verfahren beschrieben und getestet. Ja, technisch geht das vielleicht, aber muss das sein? Wird die E-Rechnung hier tot-bürokratisiert?

P.S. ZUGFeRD gibt es in dem Konzept nicht ... 

 

Kommentare

Da macht die EU 2014 eine E-Invoice-Richtlinie (RL 2014/55/EU ), die ab 2019 verpflichtend ist und vom CEN gesetzte Standards erfüllen müssen, und Deutschland macht einen zweiten nationalen Sonderweg neben ZugFERD auf? Wie soll das für ein Unternehmen in der EU aussehen? Für alle Mitgliedstaaten soll ein Unternehmen ein oder mehrere (wie in D) Standards erfüllen können müssen, um eine Rechnung elektronisch stellen zu können?
https://www.computerwoche.de/a/die-e-rechnung-wird-pflicht-was-nun,3326…
Das ist nicht mehr nur ein Schildbürgerstreich, sondern aktive Sabotage der EU. So wie wir beim letzten Mal die EU sabotiert haben, in dem wir bei der EU-Dienstleistungsrichtlinie 2009 gefordert haben, dass die EU-Bürger, die ach Artikel 8 einfach und aus der Ferne ihr Gewerbe in Deutschland anmelden wollten, dieses gefälligst nach §3a VwVfG mit einer qualifizierten Signatur zu machen hätten, die es für EU-Bürger nicht im Ausland gibt, also der deutsche Gesetzgeber öffentlich auf die EU geschissen hat?
Bei den Rechnungen hatten wir eine Zeitlang auch die Pflicht, dass sie nach §14 Umsatzsteuergesetz gefälligst qualifiziert signiert werden müsste,. bis dem Finanzminister dieser schwachsinnige Unfug zu blöde wurde und die Signaturpflicht ersatzlos gestrichen wurde.
Hier wird Schindluder bei der Digitalisierung getrieben: Boykott und Sabotage sind die leitmerkmal statt Vereinfachung und Effizienzsteigerung.
Weiss die Kanzlerin eigentlich, dass ihre Verwaltung die Digitalisierung so langjährig und nachhaltig hintertriebt zum Schaden der Bundesrepublik? Vom Normenkontrollrat wird sie es jedenfalls nicht erwarten. Der verweigert seit Jahren seine Aufgabe, dass er bestehende Gesetze zu evaluieren hat, ob sie den erwarteten Bürokratieabbau erbracht haben. Statt dessen ruft er nach Verfassungsänderung und dem starken Mann, der in Bund, Ländern und Gemeinden gegen unsere Verfassung mit harter Hand zentralistisch durch regiert. So wie früher. Vor der Digitalisierung.
Es ist eine nationale Schande, dass EU-Vorgaben so absurd und schädlich national hintertrieben werden.

Diese Woche gab es viele Entscheidungen, die uns in der Informationgesellschaft noch beschäftigen werden. Von Abhörgesetzen über das eIDAS-Gesetz, die Diskussion um freie WLAN-Hotspots bis eben zur Entscheidung des IT-Planungsrates für das XRechnung-Format, das Grundlage für 

Die Vorlage wurde am 22.6.2017 verabschiedet: Darin enthalten:

TOP5 Verbindliches Meldeverfahren zum Informationsaustausch über Cyberangriffe

TOP6 Erneuerung des IT-Grundschutzes

TOP7 Umsetzung des Richtlinie 2014/55/EU (elektronische Rechnungsstellung - eRechnung) - Thema dieses Diskussionsstranges

TOP12 Fortschreibung der Verwaltungsvereinbarung GDI-DE

und 

TOP17 Anforderungen an die Ausgestaltung von Experimentierklauseln im E-Government

 

Wie es mit dem europäischen Format weitergeht und wie es in das XRechnungsformat einfließt ist eine andere Frage. Aber die Frage nach ZUGFeRD dürfte sich in Bezug auf die öffentliche wohl erledigt haben.

Sehr geehrter Herr Dr. Kampffmeyer,
es freut uns, dass Sie sich mit dem „Architekturkonzept eRechnung für die föderale Umsetzung in Deutschland“ beschäftigen! Wir, die Firma Schütze Consulting AG, durften das Bundesministerium des Innern bei der Erstellung des Architekturkonzepts beratend unterstützen. Gerne gehen wir im Folgenden auf die von Ihnen vorgebrachten Kritikpunkte ein.

> Und wie erwartet […] wurden alle, ja allen möglichen und denkbaren Sonderlocken der öfffentlichen Verwaltung berücksichtigt. Beginnend beim deutschen Format xRechnung (haben wir da eine europäische Norm die bis Ende 2018 verbindlich umgesetzt werden muss?) […]

Sie spielen auf die CEN-Norm 16931 zum semantischen Datenmodell elektronischer Rechnungen an. Diese Norm besteht aus einem verpflichtenden Kernmodel und möglichen Einschränkungen beziehungsweise Erweiterungen. Mit der XRechnung wird das Kernmodel entsprechend der Norm adaptiert und auch ihre Bitte erfüllt, „dann doch bitte wenigstens das Europa-weit genormte Format des CEN“ zu nutzen. Der IT-Planungsrat hat XRechnung dementsprechend als maßgeblich für die Umsetzung der „eRechnungs-Richtlinie“ (Richtlinie 2014/55/EU) in Deutschland beschlossen.

Damit wären wir auch bereits bei ZUGFeRD, das Sie im Konzept vermissen. Während XRechnung CEN-konform ist, gilt das für ZUGFeRD gegenwärtig noch nicht. Aus diesem Grunde ist ZUGFeRD nicht im Konzept berücksichtigt. Wenn ZUGFeRD in zukünftigen Versionen CEN-konform ist, wird auch dieser Standard hinsichtlich einer Berücksichtigung im zentralen Rechnungseingang geprüft.

Des Weiteren bemängeln Sie die Auswahl der Übertragungskanäle. Der Anspruch des Architekturkonzepts ist es, Rechnungsstellern möglichst viele Übertragungswege zu bieten, auch im Vergleich zu anderen europäischen Ländern. Neben Webservices zählen dazu unter anderem E-Mail, De-Mail und die Eingabe über Webformulare.
Ähnlich verhält es sich mit der von Ihnen angesprochenen Signatur-Prüfung.
> […] bis hin zur Signatur-Prüfung mit dem liebgewonnenen TR-ESOR -Verfahren für qualifizierte elektronischen Signaturen (und die Steuerbehörden schreiben eindeutig in den GoBD dass man keine elektronische Signatur bei Rechnungen braucht).
Das Architekturkonzept sieht analog zur GoBD keine verpflichtende Signierung vor. Vielmehr soll Rechnungsstellern die Möglichkeit zur Signierung und Verschlüsselung angeboten werden, falls sie eine erhöhte Transportsicherheit wünschen.

Unabhängig vom Übertragungskanal stellen Sie die vorgesehene Authentisierung in Frage. Diese hat folgenden Hintergrund: Einerseits können Eingangsrechnungen eindeutig korrespondierenden Rechnungsstellern zugeordnet werden, wodurch die weitere Bearbeitung der Rechnung erleichtert wird. Andererseits erhalten Rechnungssteller dadurch die Möglichkeit, verfahrensspezifische Daten zu hinterlegen, zum Beispiel erwünschte Übertragungskanäle für ausgehenden Nachrichten. Dabei müssen Rechnungssteller keine separaten Zugangsdaten für die eRechnung anlegen, sondern können bestehende durch die Anbindung von Servicekonten nachnutzen.

Ihre Anmerkung, dass die Rechnungsfreigabe im Rahmen des Architekturkonzepts nicht betrachtet wird, ist korrekt. Die rechtlichen Vorgaben sehen aber explizit vor, dass die Weiterverarbeitung elektronischer Rechnungen bei den öffentlichen Auftraggebern so gestaltet wird, dass Medienbrüche vermieden und Potenziale elektronischer Rechnungsstellung genutzt werden. Die Empfänger sind somit dafür verantwortlich, eine elektronische Freigabe zu gewährleisten – und haben dafür mit der zentralen Prüfung und Bereitstellung der eRechnungen durch den Bund beste Voraussetzungen.

Eine zentrale Vorgabe im Rahmen des Architekturkonzepts ist eine möglichst weitgehende Nachnutzung bestehender Systeme und Komponenten. Vor diesem Hintergrund sollen unter anderem die Governikus-Komponenten nachgenutzt werden. Das von Ihnen angesprochene PEPPOL wird aktuell tatsächlich hinsichtlich der Nutzung für einen einheitlichen sowie sicheren Webservices geprüft.

Wir hoffen, dass wir mit unseren Ausführungen Klarheit schaffen konnten.

Mit freundlichen Grüßen
Schütze Consulting AG

Sehr geehrter Herr Schütze,

vielen Dank, dass Sie in unserem Blog Stellung genommen haben.

Hieraus ergeben sich aber für mich noch ein paar Folgefragen:

"CEN-Norm 16931"
Hier wird offenbar der Kern um weitere - Deutschland-spezifische Teile - ergänzt. Wie gehen Sie denn mit elektronischen Rechnungen von ausländischen Dienstleistern dann um, die nicht dem vollständigen xRechnung-Format entsprechen? Außerdem gehören zur Norm 16931 auch noch weitere Normteile (siehe http://www.project-consult.de/news/2017/cen-einvoincing-standards), auf die Sie nicht näher eingehen.

"Der IT-Planungsrat hat XRechnung dementsprechend als maßgeblich für die Umsetzung der „eRechnungs-Richtlinie“ (Richtlinie 2014/55/EU) in Deutschland beschlossen."
Warum wird hier ein eigene Umsetzungsrichtlinie gefertigt, da die europäische Richtlinie ja 1:1 in Deutschland gilt (http://www.project-consult.de/comment/6042#comment-6042)? Wurde dies nur gemacht um die - in der europäischen Richtlinie nicht direkt benannten "Sonderlocken" wie De-Mail, qeS usw. - nunmehr namentlich zu verankern? 

"ZUGFeRD"
Nein, ich "vermisse" ZUGFeRD nicht, sondern weise nur darauf hin, dass das vom Bundesministerium für Wirtschaft und Energie favorisierte Format noch nicht einmal erwähnt wird - was natürlich in der freien Wirtschaft, die hier bereits erhebliche Investitionen getätigt hat, zu vielen Fragezeichen führt. Also warten wir Ihre Prüfung ab, denn natürlich werden sich FeRD, BMWE, AWV etc. bemühen, als weitere Profile (zu den bestehenden 3 Profilen) dann auch noch CEN und xRechnung aufzunehmen. Übrigens bedeutet "CEN-Konformität" umgekehrt noch nicht "xRechnung-Konformität" - oder habe ich das überlesen? Denn wenn "xRechnung" insgesamt identisch mit CEN wäre bräuchten wir ja keinen eigenen deutschen Standard, oder?

"De-Mail" 
Welche ausländischen europäischen sicheren Mail-Systeme unterstützt die Lösung, bzw. Governikus?
Wie sieht z.B. mit unabhängigen Anbietern wie RegMail aus?
Wird vom föderalen Server dann an die Behörde auch per De-Mail weitergeleitet um die Integrität und Prüfbarkeit auch beim tatsächlichen Empfänger sicherzustellen? Wie verarbeitet dieser die eingehende Rechnung automatisch, wenn er diese erst aus seinen De-Mail-Postfach holen muss?

"Signatur-Prüfung"
Prüfen Sie alle nach eIDAS zugelassen Formate für Signaturen, Siegel, Zeitstempel usw. aller europäischer Staaten?
Was passiert nach der Prüfung einer deutschen qeS-Signatur nach (ehemaligen) deutschen Signatur-Gesetz - wird die Signatur nebst Zertifikat-String beim Empfänger mitgespeichert? Und muss dann beim Empfänger nach TR-ESOR während der Aufbewahrungsfrist nachsigniert werden?

"Vielmehr soll Rechnungsstellern die Möglichkeit zur Signierung und Verschlüsselung angeboten werden, falls sie eine erhöhte Transportsicherheit wünschen."
Meinen Sie im Ernst, man solle die qualifizierte elektronische Signatur für die Verschlüsselung von E-Mails oder Rechnungsdokumenten benutzen? Stellen Sie mit ihrer zentralen Verarbeitungsstelle entsprechend GoBD dann sicher, dass alle Schlüssel zum Entschlüsseln entsprechend den Aufbewahrungsfristen vorgehalten werden - oder überlassen Sie das dem Endempfänger (Entschlüsseln müssen Sie dennoch, um die Rechnung verarbeiten - ist eine Rechnung im korrekten xRechnungsformat drin - und zuleiten zu können, oder?). Wie entschlüsselt das Endempfänger-System solche Rechnungen um diese dann automatisiert verarbeiten zu können? Woher kommt denn die "erhöhte Transportsicherheit"? Wird die Rechnung dadurch sicherer zugestellt? Oder heißt dies, dass keiner den Rechnungsinhalt oder die E-Mail mit dem Rechnungsdokument oder die De-Mail mit dem Rechnungsdokument oder oder ... lesen kann? Wäre nicht ein einfacher Weg ohne unnötige Optionen (De-Mail, qeS) sinnvoller gewesen?

"Authentisierung"
Wenn Sie eine solche Form der Authentisierung mit Anmeldung vorsehen, stellen sich mir zwei Fragen: 
Ist die Erfassung der Angaben für die Authentisierung schon in alle offiziellen europäischen Sprachen mit entsprechenden Spezialformaten für ausländische Adress-, Steuernummer- und andere Informationsformate implementiert (oder schließen Sie wie bei der Dienstleistungsrichtlinie ausländische Unternehmen vom Zusenden von Rechnungen aus?)?
Wie läuft das mit der Authentisierung, wenn der Absender einen Dienstleister für Formaterstellung, Konvertierung und Versand benutzt, da er selbst keine xRechnung erstellen kann (oder will)? Reicht es, dass sich dann ein solcher Dienstleister authentifiziert und alle Rechnungen seiner Kunden dann automatisch durchgereicht werden oder muss sich jeder seiner Kunden trotzdem selbst authentifizieren? 

"Service-Konten"
Was meinen Sie mit "anderen Service-Konten"? Welche sind das, wofür, und wer kann diese nutzen? Nur persönliche, weil deutscher Staatsbürger mit qeS? Unternehmen mit Siegel oder Zeitstempel? Reicht es bei einem Dienst wie Elster mit allen Unternehmensdaten bereits registriert zu sein - da hat man ja den Nachweis das es den Rechnungssteller gibt und dass dieser ordentlich versteuert? Gibt es so etwas wie Post-Ident-Verfahren? Welche personenbezogenen Daten werden dort verarbeitet und gespeichert, die der EU DSGVO unterliegen? 

"Rechnungsfreigabe im Rahmen des Architekturkonzepts nicht betrachtet"
Es geht nicht nur um die Rechnungsfreigabe sondern beispielsweise um die vorgeschriebenen EU-Ausschreibungsprozesse inkl. Rechnungen etc., die dann ja beim Endempfänger implementiert sein müssten. Wer kein automatisches Einlesen hat, wird manuell nacherfassen oder gar ausdrucken. Z.B. wie bekomme ich eine solche Rechnung automatisch in SAP-System, wenn dort ein signiertes, verschlüsseltes Objekt angeliefert wird, in dem ein xRechnungs-Format enthalten ist? Ach übrigens, weist der föderale Server schon Rechnungen an den Absender zurück, die nicht korrekt formal dem XRechnung-Format entsprechen oder nicht korrekt verarbeitet werden können - oder macht das erst der Endempfänger? Erfährt der Endempfänger, dass die Rechnung ihm nicht zugestellt wurde und so Zahlungsfristen oder Vertragskonditionen nicht eingehalten werden können?

"Nachnutzung"
Wird jetzt Governikus mit all seinen Komponenten auf alle denkbaren Wege, Formate, Inhalte, Signaturen, Siegel, Zeitstempel, sichere Mail-Systeme, eIDs etc. , entsprechend eIDAS, aller europäischer Staaten aufgebohrt? Ist das dann nicht ein komplett neues System? Governikus ist aktuell nur auf die Behandlung deutscher Standards eingerichtet. Sollen hierdurch - ohne Ausschreibung - neue Mittel für die Weiterentwicklung von Governikus beschafft werden?

"PEPPOL"
Schön, dass Sie zumindest dass vom Bund mit geförderte PEPPOL, das deutlich mehr kann als nur die Rechnung, auch betrachten wollen. PEPPOL ist in vielen Staaten bereits implementiert, gibt es auch als "Open" Version und kann auch den CEN-Standard (die neue openPEPPOL BIS (4A) wird EN 16931-1 entsprechen). Wäre denn PEPPOL in Bezug auf xRechnung (und alle Wege die Sie unterstützen wollen) sowie in Bezug auf die Governikus-Funktionalität eine Alternative? Oder ist die deutsche Altlast zu groß? Oder wurden mit dem "föderalen Server" zu viele neue Hürden aufgebaut?

"Ausgangsrechnungen"
Und eine Frage habe ich noch generell: was dem Einen sein Eingang, ist dem Anderen sein Ausgang. Wenn jetzt eine Behörde einer anderen Behörde eine "Rechnung" sendet geht das doch seinen Weg über den föderalen Server, oder? Wenn jetzt aber die Behörde Bescheide mit Zahlungsaufforderung an Bürger, Unternehmen usw. sendet, kommen die auch dort per E-Mail oder De-Mail als xRechnung beim föderalen Server an oder gehen die direkt an den Endempfänger? Oder ist das ganze E-Rechnungskonzept etwa nur eine Einbahnstraße für Rechnungen rein in die Behörden?

 

Mit freundlichen Grüßen
Dr. Ulrich Kampffmeyer

Ich verstehe die Sabotage vom IT-Planunsgrat immer noch nicht.
Vor einiger Zeit haben Macron und Gabriel vereinbart, einen gemeinsamen Standard für elektronische Rechnung einzuführen:
http://www.ferd-net.de/aktuelles/meldungen/eine-gemeinsame-elektronisch…
Warum der IT-Planungrat nun gegen Europa gerichtete, nationale Standards zusätzlich mit XRechnung schafft ohne eine WiBe vorzulegen und ohne die von der Verfassung gebotene Verhältnismäßigkeit zu wahren, ist nicht nach zu vollziehen.
Agitieren BMI und Bremen gegen Europa? Nationalistischer Trumpismus? Wo der deutsch-französische Standard auf ZugFERD basiert, siehe III 7 hier:
https://www.de.digital/DIGITAL/Redaktion/DE/Downloads/deutsch-franzoesi…
Zudem verstößt das BMI gegen seine eigenen Vereinabrungen (von 2013):
http://www.verwaltung-innovativ.de/SharedDocs/Publikationen/Organisatio…

Die Deutsche Bahn hat sich auf das ZugFERD-Format geeinigt:
http://www.deutschebahn.com/file/de/11995782/DQp6-8IqrNT1fryUEulgA816yl…

Dataport in Norddeutschland und die Datev im Süden unterstützen ZugFERD so wie viele andere. Warum wird nun gegen die Wirtschaft und gegen Europa mit einem neuen Standard agitiert?
http://www.ferd-net.de/zugferd/unterstuetzerliste/zugferd-unterstuetzer…

Breitet sich hier etwa destruktiver Zynismus als Sabotage der Digitalisierung aus getreu dem spasshaft gemeinten Zitat von Andrew Tannebaum: "The nice thing about standards is that you have so many to choose from. "
Für den Steuerzahler ist dieser Zynismus ein teures Abenteuer ohne Nutzen. Nicht aus den gefloppten Projekten qualSig, eID/nPA und De-Mail mit ihren nationalistischen Sonderbehandlungen gelernt. Schade.

Lieber Herr Schütze,
vielen Dank für die Erhellung. Salopp formuliert verstärken Sie bei mir den Eindruck, dass die Verhinderungstechnologien in Deutschland auf dem Rückzug sind (qualSig, eID, De-Mail).
Zwei Fragen hätte ich dennoch:
1.) Warum brauchen wir in Deutschland zur Umsetzung der EU-Invoice-Richtlinie zwei Standards (eRechnung und ZugFERD)? Dürfen jetzt Staat und Wirtschaft pokern, welcher sich durchsetzen wird und müssen Unternehmen, die viele öffentliche Kunden haben, davon ausgehen, dass sie für deutsche Kunden zwei Technologien vorhalten müssen?
2.) Warum macht man für eine EU-Richtlinie nationale Umsetzungen? 20-30 disjunkte Implementierungen schaden doch massiv dem gemeinsamen Binnenmarkt, den die EU haben will? Oder sind es nur perfide Bemühungen, EU-Vorgaben durch nationalstaatliche Umsetzungen zu boykottieren? Letztlich schadet das doch der Wirtschaft, dem Staat und dem Anbieter, der mit seinen nationalistischen Lösungen nicht reüssieren kann, wie wir bei qualSig z.B. gesehen haben, wo Banken, Telekom und Post wieder ausgestiegen sind, nachdem die 10 Mio DM Invest jeweils sich nicht rückspülten?
Beste Grüße
Wolfgang Ksoll

1. Es gibt eine Norm, die CEN-Norm, die am 28.06.2017 veröffentlicht wurde.
2. Die Verwaltung hat die CEN-Norm übernommen, und hat 16 Felder, die in CEN optional sind, als verpflichtend erklärt. Das ist für Branchen/Unternehmen ganz normal, dass sie ihren Geschäftspartnern mitteilen, was eine an sie gestellte Rechnung alles enthalten muss.
3. Der Bund(!), nicht die Länder, hat im Entwurf seiner E-Rechnungs-Verordnung erklärt: "Daneben kann auch ein anderes Datenaustauschformat verwendet werden, wenn es mindestens den Anforderungen der europäischen Norm für die elektronische Rechnungsstellung entspricht."
4. Jede Rechnung im CEN-Format, die die von der Verwaltung gewünschten Angaben enthält, wird von der Verwaltung als XRechnung bezeichnet und von Bund, Ländern und Kommunen akzeptiert.
5. Wird eine CEN-Rechnung an den Bund geschickt (beispielsweise aus dem Ausland, wo die Wünsche der Verwaltung nach Pflichtangaben nicht bekannt sind), dann werden die fehlenden Felder angereichert, bevor die Rechnung (dann als XRechnung) in den weiteren Workflow geht.
6. Was in den E-Rechnungs-Verordnungen der einzelnen Länder stehen wird, ist noch nicht bekannt. Vermutlich werden einige Länder auf vollständige Pflichtangaben bestehen.
7. In der Begründung zum E-Rechnungsgesetz heißt es: "Die Interoperabilität kann beispielsweise durch einen nationalen Verwaltungsstandard XRechnung erfolgen, der seinerseits auf den in der Wirtschaft bereits genutzten, jeweils aktuellen ZUGFeRD-Standard verweist. Das gilt nur, soweit die Konformität mit der europäischen Norm sichergestellt ist."
8. Das FeRD hat angekündigt, die CEN-Norm 1:1 in das ZUGFeRD-Profil Comfort von ZUGFeRD 2.0 zu übernehmen.
9. Wird die Ankündigung des FeRD umgesetzt, dann gilt analog zu 4. : Jedes XML einer Rechnung im ZUGFeRD 2.0-Format Comfort, das die von der Verwaltung gewünschten Angaben enthält, wird von der Verwaltung als XRechnung bezeichnet und von Bund, Ländern und Kommunen akzeptiert.
10. Die Bezeichnung XRechung hat zwei Bedeutungsdimensionen. Erstens ist XRechnung für die Verwaltung intern (Bund und Länder) tatsächlich ein Standard, der in die Systematik von XÖV (http://www.xoev.de/) eingeordnet ist. Zweitens bedeutet XRechnung nach außen die Definition von Pflichtangaben innerhalb der CEN-Norm, wofür der Begriff Format-Standard fehl am Platze ist.

Fazit: Es gibt in Deutschland keine Formatvielfalt und keinen nationalen Sonderweg. Es werden in Deutschland zukünfig Rechnungen nach CEN-Norm verschickt. Wenn diese bestimmte Pflichtangaben enthalten, können sie auch als XRechnung bezeichnet werden. Die CEN-Norm ist integrales Element der Zugferd-Systematik, die breiter angelegt ist als die CEN-Norm und über diese hinausgeht (Profil Extended, weitere Dokumente wie Bestellung im Fokus).

Was auf alle Fälle katastrophal ist: die Kommunikation über die aufgezeigten Zusammenhänge und die Normierungs- und Standardisierungsthematik.

Lieber Gerhard,

danke für Deine Ergänzungen und Klärungen, die aber mit der tatsächlichen Situation nicht überall übereinstimmen. Das ZUGFeRD "Comfort" Profil ist dann CEN pur. Und auch die gemeinsame Entwicklung der französischen E-Rechnung und ZUGFeRD werden in Bezug auf CEN wohl 1:1 compliant sein (zu dem die Regeln zum Aufbau auch noch über UN/CEFACT veröffentlicht werden, damit ein internationaler Standard daraus werden kann). ZUGFeRD 2.0 heißt in der deutsch-französischen Variante auf europäischer Ebene "Factur-X". XRechnung in Deutschland kann man dann ebenso wie ZUGFeRCH in der Schweiz "zur Familie der CEN-kompatiblen Rechnungsformate" zählen. 
Aber im hier diskutierten Dokument "DAS ARCHITEKTURKONZEPT eRECHNUNG für die föderale Umsetzung in Deutschland – entwickelt vom Bund und dem Land Bremen" kann ich allerdings nicht den geringsten Hinweis auf ZUGFeRD entnehmen. Aber OK, ich verstehe, wenn eine ZUGFeRD-2.0-Rechnung dann den CEN-Basis-Standard plus verpflichtende Zusatzfelder erfüllt, heißt sie in der deutschen öffentlichen Verwaltung xRechnung. Übrigens, hätten die Bremer nur eine Woche gewartet, hätten sie reinschreiben können, dass die CEN EN 16931-1 für elektronische Rechnungen fertig und veröffentlicht ist (war gestern und das Datum war schon lange angekündigt).

Da Du ja im Bereich GoBD und elektronische Rechnung firm bist, möchte ich eine andere Frage loswerden: zur Erfassung von Rechnungen über das Web-Interface. Dies soll ja eine Hilfestellung für kleinere Unternehmen sein, einzelne Rechnungen zu erfassen und der öffentlichen Verwaltung im XRechnung-Format (hier Format) zuzustellen. Auch kleinere Unternehmen setzen ja Buchhaltungssoftware ein. Vorgang: das Kleinunternehmen gibt die Daten der Rechnung manuell in das Web-Interface ein (was sind eigentlich die anderen erwähnten Service-Konten?).

Zwei einzelne Aspekte:

a) Der Kleinunternehmer erfasst die Rechnungsdaten in seiner Buchhaltung und schreibt die Informationen vom Bildschirm ab, um sie im Portal zu erfassen. Wie sieht denn dann der elektronische Beleg zur Buchung aus, den das Web-Portal ihm ja elektronisch (da ja originär elektronisch entstanden) eigentlich zur Speicherung zur Verfügung stellen muss? Reicht es hier seitens des Steuerpflichtigen vor dem Absenden der Daten einen Screenshot der Webeingabe als Beleg zu machen? Er hat doch eigentlich dann keine ordentliche Ausgangsrechnung? Wird ein Steuerprüfer das als Beleg zum Buchungssatz akzeptieren? 

b) Der Kleinunternehmer erfasst die Rechnungsdaten in seiner Buchhaltung und druckt die Rechnung auf Papier aus. Nun schreibt er die Rechnung ab, gibt die Daten in das Webinterface ein und sendet ab. Jetzt gibt es zwei Rechnungen - Papier und elektronisch. Ist es zulässig die gleiche Rechnungsnummer zu haben oder sind es wirklich zwei Rechnungen, wo jetzt der steuerpflichtige Kleinunternehmen zwei Mal Umsatzsteuer zahlen muss? Es ist doch kein identisches Mehrstück - einmal nur Daten und einmal ein echter papierner Beleg?

Aus der Antwort der Schütze Consulting ergeben sich noch eine ganze Reihe anderer Fragen, z.B. zum Signieren der Rechnungen, zum Verschlüsseln von Rechnungen, zu Rechnungsversand per De-Mail usw., die ich mir aber heute schenke.

Den Schuh mit der "katastrophalen Kommunikation" in meinem Post ziehe ich mir aber an. Mea Culpa.

Mit den besten Grüßen,
Uli
 

 

 

Den Schuh, Uli, mit der "katastrophalen Kommunikation" musst Du Dir nicht anziehen. Damit ziele ich auf die, die dafür verantwortlich sind, dass in der Öffentlichkeit der Eindruck entstehen konnte: deutscher Sonderweg, Irrweg, ...

In den letzten Wochen wurde von der Verwaltung ja nicht nur das Architekturkonzept E-Rechnung veröffentlicht, sondern noch manches mehr. Und das muss alles im großen Zusammenhang gesehen werden:
- Architekturkonzept E-Rechnung
- E-Rechnungs.Gesetz des Bundes
- Referentenentwurf E-Rechnungs-Verordnung
- Spezifikation XRechnung

Wer wie ich am Dienstag und Mittwoch dieser Woche beim E-Rechnungsgipfel in Wiesbaden war (inhaltlich mitverantwortet vom BMI), der tut sich mit einer Gesamtsicht und Gesamtwürdigung leichter. Da wurde deutlich, wie sich alles in die E-Government-Strategie des Bundes einordnet, welch dicke Bretter es zu bohren galt und weiterhin gilt, welch bedeutsame Fortschritte bis heute erreicht wurden (die man dem föderal aufgestellten Staat so nicht ohne weiteres zutrauen würde) und welch große Aufbruchstimmung bei der digitalen Transformation des Rechnungsaustauschs aktuell in der Verwaltung herrscht.

Dass da noch nicht jedes Detail ausgefeilt oder ausführlich beschrieben ist, ist nicht verwunderlich. So wie Deine Fragen zum Web-Interface. Da das BMF in die Entwicklung des Architekturkonzeptes mit eingebunden war, gehe ich einmal davon aus, dass sich die Fragen beantworten lassen.

Vielleicht richtest Du Deine Fragen einfach einmal an das FeRD. Das ist ja als Mulit-Stakeholderform konzipiert, da sind BMI und BMF sowie die Wirtschaft vertreten und da gibt es auch ein Arbeitspaket "Internationale Vernetzung & Rechtsfragen". Von dort müsstest Du eigentlich eine befriedigende Antwort bekommen können.

Einen Aspekt, der in der Diskussion hier bisher noch nicht angesprochen wurde, finde ich äußerst interessant. Während sich manch einer heute brüstet, mit der Parole "digital first!" Treiber der digitalen Transformation zu sein, sagt die Verwaltung schnörkellos und knallhart "digital only!". Weg mit der analogen Rechnung: kein Papier, kein PDF, keine hybride Rechnung. Strukturierte Daten pur! Und schon beginnen sich in der Wirtschaft Kräfte zu formieren, die den Digitalisierungselan des Staates einbremsen wollen: Lasst uns doch - auf jeden Fall in der hybriden Rechnung! - die liebgewonnene analoge Welt konservieren!

Ein sonniges Wochenende

Gerhard

Hallo Gerhard,

danke für Deinen Kommentar, auch wenn die eigentlich gesuchten Antworten nicht drin waren. Bei der FeRD- wie auch bei den XRechnungs- und Minsterien-Vertretern werde ich mich nicht "einmischen". Die werden wohl auch selbst schon auf die Probleme gestoßen sein.

Aber offenbar haben meine Antworten in diesem Blogbeitrag den Eindruck erweckt, ich sei gegen XRechnung und daher pro ZUGFeRD.
Dies ist keineswegs der Fall.
In all meinen Beiträgen, Vorträgen und Blogs habe ich immer die Ansicht vertreten, dass die elektronische Rechnung nur Sinn macht, wenn sie
a) automatisch von FiBu/ERP-Systemen erzeugt, als reiner Datensatz übermittelt wird um dann wiederum automatisch in das FiBU/ERP-System des Empfängers zu gelangen; und
b) nur als ein Baustein in Geschäftsprozessen betrachtet wird, da zur vollständigen digitalen Abarbeitung weitere Datensätze (Dokumente) und Prozesse benötigt werden.

So gesehen sind beide Ansätze, das "Föderale Architekturkonzept E-Rechnung" wie auch "ZUGFeRD" meiner Meinung nach nicht geeignet, die Digitalisierung voranzubringen, da sie Medienbrüche und zusätzliche Hürden bringen (zu ZUGFeRD siehe z.B. meine "Wunschliste von 2014 http://www.project-consult.de/comment/2462#comment-2462). Bei der "XRechnung" wird über Signaturen, Verschlüsselung, De-Mail usw. fabuliert (siehe den Kommentar von Schütze Consulting) und bei "ZUGFeRD wird weiter das leider hybride Format favorisiert, bei dem ein XML-Datensatz, ein Abbild der Daten als PDF und beides dann in ein weiteres PDF eingepackt wird. Letzteres muss dann auch wieder beim Empfänger ausgepackt werden. Dies ist kontraproduktiv in Zeiten von Automatisierung und Digitalisierung.

Eigentlich reicht es, den Datensatz nach CEN EN16931 zu erzeugen und an eine Empfängeradresse zu versenden, wo der Datensatz, die elektronische Rechnung, weiterverarbeitet wird.

Und man darf auch nicht ignorieren, dass die Mehrzahl der Rechnungen im B2C als PDF oder HTML versendet wird. 

Und man darf nicht ignorieren, dass es bereits Lösungen gibt, die schon funktionieren und eingesetzt werden können (z.B. PEPPOL).

 

Uli

Neuen Kommentar schreiben