Gesetzentwurf zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen

8. Juli 2016 10:52 Uhr  |  PROJECT CONSULT Webmaster  |  Permalink


Der neue Gesetzentwurf zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen wurde vom BMI am 1. Juli 2016 veröffentlicht. Mit dem Entwurf will das Bundesministerium für Inneres die Vorgaben der EU Richtlinie 2014/55/EU in deutsches Recht umsetzen. 

Ziel der Richtlinie und des Gesetzes (BMI Mitteilung http://bit.ly/eRechnungGesetz; Gesetzestext http://bit.ly/ERechnungGesetz) ist es, eine verbindliche Rechtsgrundlage für den Empfang und die Verarbeitung – zukünftig verbindlicher –  elektronischer Rechnungen durch öffentliche Auftraggeber zu schaffen. Dies bedeutet für Unternehmen, dass ihre Rechnungen an die öffentliche Verwaltung nur akzeptiert werden, wenn die relevanten Daten in maschinenlesbarer Form vorliegen, z.B. als XML-Datensatz; da die automatisierte Rechnungsverarbeitung einer der großen Vorteile elektronischer Rechnungen ist, deren reibungslose Funktion nur durch eine standardisierte Dateneingabe ermöglicht, –- und durch die Rechnungsstellung per PDF oder ähnlicher, nicht maschinenlesbarer Verfahren –,  unnötig ausgebremst wird. Über das Projekt elektronische Rechnung ind er öffentlichen Verwealtung finden sich hier weitere Informationen. Zum Projekt E-Rechnung gibt es auch eine entsprechende Planung des IT-Planungsrates.

Der Gesetzentwurf beinhaltet zudem die Möglichkeit für die Bundesregierung weitere Anforderungen an die Rechnungsstellung, die verwendeten Datenmodelle sowie die Verbindlichkeit der elektronischen Rechnung zu stellen. Dies ist die Öffnungsklausel für das europäische Rechnungsformat, dass bis 2018 eingeführt werden soll.

In einem Punkt geht der deutsche Entwurf über die Vorgaben der EU-Richtlinie hinaus. Anders als von der EU verlangt, sieht der Entwurf des BMI vor, das gesamte öffentliche Auftragswesen zu digitalisieren, nicht nur Aufträge eines gewissen Volumens. Letzterers würde zu weiterer Unterscheidungsnotwendigkeit führen, welche das Verfahren nach Meinung des BMI nur belasten würde.

Die einheitliche Regelung soll allen Beteiligten zu Gute kommen – auch wenn die deutsche SOnderreglung ZUGFeRD im Raum steht. Die Hoffnung ist, den Verwaltungsaufwand zu reduzieren und gleichermaßen Konformität und Rechtssicherheit in der elektronischen Welt zu erhalten. 

Der IT Planungsrat hat zudem ein Planspiel zum Testen der Umsetzbarkeit des Entwurfs organisiert, in dem die Tauglichkeit des geplanten deutschen „XRechnung“ Standards sowie der gesetzlichen Regelungen geprüft werden sollen. Die Teilnahme unterschiedlichster Parteien ermöglicht von Anfang an eine breite Akzeptanz unter den Umsetzenden und einen reibungslosen Übergang in die neue Regelung.

Das in Deutschland favorisierte hybride ZUGFeRD Format erfüllt diese Anforderungen von EU und deutscher Umsetzung eigentlich nur eingeschränkt, beinhaltet aber zusätzlich die Rechnung als Dokument im PDF-Format. Auf europäischer Ebene wird an einem einheitlichen XML-Datenformat gearbeitet, dass als europäische Norm für elektronische Rechnungen für alle Verwaltungen Europas verbindlich wird. Die deutsche XRechnung wie auch das europäische Format werden Auswirkungen auf die XML-Profile von ZUGFeRD haben.

Weitere Informationen zum Thema Elektronische Rechnung in Europa finden sich in unserem Beitrag http://www.project-consult.de/ecm/news/2015/e_invoicing

8 Kommentare zu “Gesetzentwurf zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen

  • Was tut sich eigentlich beim Thema "Elektronische Rechnung"?
    17. Juli 2016 um 14:25
    Permalink

    Da müsste doch inzwischen auch in Deutschland etwas in Bewegung geraten sein.

    Mit den entsprechenden EU-Richtlinien für die öffentliche Verwaltung im Bereich der Beschaffungen (siehe z.B. das "Gesetz zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen", das am 13.07.2016 vom Bundeskabinett verabschiedet wurde (BMI-Mitteilung http://bit.ly/eRechnungGesetz; Gesetzestext http://bit.ly/ERechnungGesetz) wurden für die öffentliche Verwaltung entsprechende Grundlagen geschaffen.
    Die BMI-Pressemitteilung hierzu:
    <Zitat> "…die Vorschriften zur elektronischen Rechnungsstellung im E-Government-Gesetz des Bundes wieder. Sie treten ab dem 27.11.2018 für Bundesministerien und Verfassungsorgane in Kraft. Für alle übrigen Behörden gilt die Neuregelung ab dem 27.11.2019. Zugleich verpflichtet sich die Bundesverwaltung selbst, zukünftig Rechnungen an Bürger und Unternehmen in elektronischer Form anzuzeigen, wenn der Rechnungsstellung ein elektronischer Bestellvorgang vorangegangen ist; beispielsweise im Webshop einer Bundesbehörde. </Zitat>

    Der zweite Meilenstein, die  Veröffentlichung des Entwurfes für den europäischen E-Rechnungs-Standard "Electronic invoicing – Semantic data model of the core elements of an electronic invoice (prEN 16931:2015)";siehe z.B. unseren Post zu http://bit.ly/29JivCy), ist dagegen in Deutschland wenig bekannt. Hier befinden (oder befanden) sich die Ansätze von "rein XML" (z.B. Peppol) und "hybrid" (z.B. ZUGFeRD) bisher im Widerstreit.

    Aber auch ZUGFeRD bewegt sich, wie die Mitteilung "ZUGFeRD und UN/CEFACT auf dem gleichen Stand" (siehe unseren Post http://bit.ly/22XFjny) zeigt.

    Dennoch, gemessen am Potential der elektronischen Rechnung in Bezug auf Medienbruch-freie Prozesse und automatisierte Verarbeitung tut sich zu wenig und die Akzeptanz von ZUGFeRD dümpelt weiterhin vor sich hin. Auch der eco Verband meint, es reiche nicht aus, technische Standards wie ZUGFeRD zu promoten, sondern den gesamten Prozess des E-Procurement durchgängig zu betrachten. Auch in unseren Vorträgen auf den E-Rechnungsgipfeln in Wiesbaden (Folien des Vortrags) und Barcelona (Folien des Vortrags) haben wir versucht, die elektronische Rechnung in einen Gesamtkontext zustellen.

    Es gilt überall elektronische Rechnungen automatisiert in der Finanzbuchhaltungssoftware zu erstellen, verarbeitungsfähig zu übermitteln (Versand oder Download) und automatisiert beim Empfänger wieder in die Finanzbuchhaltung einzuspielen. Hiervon ist ZUGFeRD noch weit entfernt und EDI ist zumindest bei größeren Unternehmen immer noch das Format der Wahl.

    Antwort
    • Brauchen wir noch mehr Regulierung?
      19. Juli 2016 um 13:37
      Permalink

      Hallo Uli,
      ich kenne da noch einen Standard ;-): Im Umfeld der Energiewirtschaft wird schon seit 2006 durch ein eigenständiges Format (!!!), das durch die Bundesnetzagentur vorgegeben worden ist (siehe https://www.bundesnetzagentur.de/DE/Service-Funktionen/Beschlusskammern/1BK-Geschaeftszeichen-Datenbank/BK6-GZ/2006/2006_0001bis0999/2006_001bis099/BK6-06-009/BK6-06-009_Beschluss_BKV.html) Rechnungen automatisch erstellt, empfangen und verarbeitet. Hier hat 2006 im Rahmen der Regulierung des Energiemarktes eine starke Vorgabe der Behörde gegeben, die auch mit einem Umsetzungsdatum und einem definierten Format verbunden wurde. Ist das eine Vorgehensweise auch für andere Branchen?

      Ich denke, wir sind uns einig, das eine Automatisierung der Rechnungsverarbeitung dringend notwendig ist, um für alle Beteiligten die gegebenen Effizienzgewinne und damit die Einsparungen zu nutzen.

      Am Beispiel der Energiewirtschaft sieht man ja das es geht, soweit ich das überschauen kann.

      Warum nicht in anderen Bereichen?

      Viele Grüße
      Michele

      Antwort
      • EDI-Format für elektronische Rechnungen
        19. Juli 2016 um 14:26
        Permalink

        Hallo Michele,

        das ist doich eines der bekannten Branchen-EDIFACT-Formate, sprich EDI, wie bei mir ganz am Schluss erwähnt. Das Format für die Energie-Wirtschaft wurde in Bezug auf die Nachrichtentypen und Attribute einige Male angepasst. Und es kann natürlich deutlich mehr, als nur elektronische Rechnungen zu übermitteln 😉

        Merci und schöne Grüße,

        Uli   

        Antwort
        • EDI-Format für elektronische Rechnungen
          20. Juli 2016 um 7:01
          Permalink

          Hallo Uli,

          das stimmt, es ist ein EDI-Format. Das ungewöhnliche, soweit ich das beurteilen kann, ist, dass die Bundesnetzagentur nicht nur das Format vorgegeben hat, sondern auch den Termin bis zu dem dieses Format von allen Markteilnehmern benutzt werden soll, so dass zwischen den Unternehmen in der Energiewirtschaft der Rechnungsaustausch so weit wie möglich automatisch läuft.

          Die Frage, die ich mir dazu stelle ist, brauchen wir diesen Eingriff des Staates, damit das offentsichtlich effizienteste auch z. B. für Zugferd oder den anderen Formaten vorgegeben wird? Das das öffentliche Auftragswesen nun aufgrund der EU-Richtlinie elektronische Rechnungen akzeptiert, muss nicht unbedingt eine flächendeckende Motivation für alle Branchen und Unternehmen bedeuten.

          Zumindest sehe ich das aus der Vergangenheit heraus. Die Initiative des Staates an der Stelle ist genau richtig. Übertägt sich jedoch dieser Ansatz soweit wie möglich auch auf alle Unternehmen ohne Terminvorgabe z. B. über eine GOBD 2 ;-)?

          Gruß Michele

          Antwort
          • Formate für elektronische Rechnungen
            20. Juli 2016 um 15:38
            Permalink

            Hallo Michele,

            1. Für die Energie-Branche wurde das durchgedrückt (und manche benutzen nicht einmal X.500 für EDI sondern schicken sich die EDI-Dokumente per E-Mail 🙂 ). Immer dann, wenn es eine starke Lobby gibt, wird auch etwas gemacht. Hier geht es um das klassische EDI-Verfahren, das eine automatisierte Erstellung beim Absender und eine automatisierte Verarbeitung bem Empfänger ermöglicht. Dies geschieht auf Basis gesetzter Standards und Verträge. Eine solche automatisierte Verarbeitung wünschen wir uns natürlich auch für andere elektronische Rechnungen (die Rechnung per PDF kann hier nur ein Zwischenschritt sein). 
               
            2. ZUGFeRD als Rechnungsformat ist nicht allein. Es konkurriert mit anderen Formaten in Deutschland und besonders in Europa. Für die öffentliche Verwaltung in Deutschland wurde das XRechnung-Fomat definiert. Auf europäischer Ebene wird gerade an der europäischen Norm EN 16931:2015 gearbeitet, die 2018 in Europa für alle Ebenen der öffentlichen Verwaltung verbindlich wird. Daneben gibt es bereits Lösungen, die nicht nur die elektronische Rechnung, sondern den gesamten E-Procurement-Prozess abdecken – z.B. PEPPOL.
               
            3. Dein Hinweis auf eine mögliche GoBD2 … in den GoBD steht in einem Beispiel auch ZUGFeRD drin. Dies wird gern von den Protagonisten von ZUGFeRD dahingehend interpretiert, dass die GOBD ZUGFeRD "wollen" und dass es "gesetzt" sei (Zitate). Dies ist nicht der Fall. Natürlich sind auch EDI, XML-basierte Rechnungen, PDF-Rechnungen und andere elektronische Formate weiterhin zulässig. Sie müssen halt nur die formalen Kriterien einer Rechnung erfüllen. Wenn es wirklich zu einer gesetzlichen Regelung oder einer Verankerung in einer neuen Version der GoBD kommen sollte, dann würde natürlich die ZUGFeRD-Fraktion mit aller Macht versuchen, sich dort "reinzuhängen". Ob das positiv für unsere Wirtschaft im gloablen Wettbewerb ist, wage ich zu bezweifeln.

            Schöne Grüße,

            Uli

          • Nationaler Alleingang beim europäischen/globalen eInvoicing?
            8. August 2016 um 15:57
            Permalink

            Ich bin jetzt verwirrt. Im Jahre des Herrn 1999 (sagt meine Festplatte) haben wir als GE-Tochter mit GEIS-Schwester evaluiert, was sich in der elektronischen Prozesskette von Produkt-Katalog/-Preise über Order Basket zur Bestellung, über Lieferung, Rechnung und Bezahlung neben EDI (UN/EDIFACT) so (in USA) tut. ANSI X.12 war das bis 810 INVOICE wohl definiert. Aber XML kam auf, insbesondere z.B. cXML (Ariba, Microsoft). Für SAP-zu-SAP konnte man das IDOC nutzen. In den USA sagte das Verteidigungsministerium, ihr dürft mir Rechnungen nur noch elektronisch schocken. Dabei der Pizza-Bäcker beim Catering nicht zu kurz kam, wurde für den ein Web-EDI-Interface eingebaut, wo der wenigstens händisch seine Rechnung eingeben konnte, EDI drunter lag und das DoD seine Prozesse digitalisierte.
            In Deutschland haben die Saboteure erst mal den §14 Umsatzsteuergesetz missbraucht und mit einer qualifizierten Signatur die Digitalisierung hinterfotzig hintertrieben. Ich will ja gar nicht so weit gehen, auch noch Jobcard/Elena zu erwähnen, wo man Lohnbescheinigungen mit PEM aus SAP rausgeblasen hat. Den Blödsinn mit §14 UStG hat man weider weggemacht, weil da nichts lief. Erfordernis der qualifizierten Signatur einfach weg. Nun kann jeder in Deutschland seine Rechnungenb auch als PDF verschicken mit und ohne eingescannter Signatur. Was ich mit UK schon lange mache.
            Nun sagt die EU 17 Jahre nach den USA (siehe oben) mit der eINVOICE-Richtlinie 2014/55/EU, dass Behörden in der EU-gefälligst auch maschinenlesbare Rechnungen zu akzeptieren hätten. Was machen die Saboteure als erste? SIe schaffen für eine EU-Richtlinie einen nationalen Standard ZugFERD, der weder EU-kompatibel ist und schon bei einfachen Nachbarn wie Österreich, die oral die selbe (oder ähnliche) Sprache verwenden, inkompatibel ist, mit der Option, das später mal kompatibel zu machen. Soll es so beshcuert laufen wie bei der qualifizierten Signatur: erst man man sie zur Pflicht, dann hebt man die Pflicht auf und dann hebt man das Signaturgesetz wegen eIDAS ganz auf?
            Als wäre das nicht schon genug Irrsinn, setzt man noch eines drauf:
            Der IT-Panungsrat ruft ein weiteres Gremium ins Leben, das einen *nationalen* IT-Standard kreieren soll, zur Umsetzung eine EU-Richtlinie.
            http://www.it-planungsrat.de/DE/Projekte/Steuerungsprojekte/E-Rechnung/E-Rechnung.html
            Ja wie zynisch sollen denn Wirtschaft und Bürger hier sabotiert werden. Sollen die Unternehmen denn etwa 29 nationale XRechnungsstandards implementieren? Das ist das Gegenteilen des gemeinsamen Marktes in der EU und schon erst recht gegen die globalen Märkte unserer Wirtschaft gerichtet. Avarto aus Gütersloh liefert auch in den öffentlichen Dienst in UK. Das soll offenbar durch die Spinner verhindert werden, dass das digital einfach fakturiert werden kann.
            Die Unternehmen sollten erst mal gar nichts tun, bis man weiss, ob ZugFERD oder XRechnung im öffentlichen Dienst verbindlich wird und dann gegebenfalls gegen diesen abartigen Bürokratieaufwuchs in kleinstückigem Nationalismus bei 29 EU-Staaten. Es ist nicht zu fassen, wie in Deutschland die Bürokratie mit aller Kraft versucht, die Digiatliserung zu verhindern, wie wir es schon bei der qualifizierten Signatur gesehen haben, die jetzt Mal ums Mal bei der Bundesrechtsanwaltkammer gegen die Wand gefahren wird, wo Anwälte in UK und USA ihre Schriftsätze einfach mit User/Passwort auf einen Gerichtsserver hochladen, wo in D die Anwälte zum Bürokratieaufwuchs mit QualSig verdonnert werden bei einem gegen seine gesetzliche Aufgaben durchpennenden Normenkontrollrat.

          • PEPPOL, ZUGFeRD, EN 16931, XRechnung, EDI, UN/CEFACT ...
            22. Juli 2016 um 16:12
            Permalink

            In unserer XING-Gruppe Information & Document Management gibt es jetzt einige interessante Beiträge zu PEPPOL: http://bit.ly/PEPPOLinDE  Zu ZUGFeRD und XRechnung hat sich dort leider noch niemand gemeldet … 

    • Elektronische Rechnung - unterschiedliche Meinungen
      8. August 2016 um 15:09
      Permalink

      Während hier bei uns im PROJECT CONSULT Blog http://www.project-consult.de/ecm/news/2016/gesetzentwurf_zur_elektronischen_rechnungsstellung_im_%C3%B6ffentlichen_auftragswesen_ver%C3%B6ffent#comment-2898 eher viele Fragezeichen stehen, ist auf Linkedin eher von Lobeshymnen auf ZUGFeRD zu lesen https://www.linkedin.com/pulse/tut-sich-eigentlich-beim-thema-elektronische-rechnung-kampffmeyer und auf XING in der Gruppe Information & Document Management https://www.xing.com/communities/posts/was-tut-sich-eigentlich-beim-thema-elektronische-rechnung-1011649104 eher PEPPOL. Wie sagte mir jemand heute dazu am Telefon – "wir machen einfach PDF-Rechnungen, ohne all die sogenannten Standards ringsherum".

      Wir hatten seinerzeit angesichts ZUGFeRD die Frage aufgeworfen, warum nicht XML einfach in den Header eines PDF/A2 zu schreiben – dann habe man auch ein vernünftiges Archiv-Format. Genauso kann man natürlich auch in eine XML-Datei eine PDF einbetten. Es gäbe also andere Varianten ohne ein kompliziert zusammengesetztes PDF/A3+PDF+XML[XML-Schema]. Unsere Wunschliste für ZUGFeRD ist weitgehend unerfüllt geblieben: http://www.project-consult.de/ecm/news/2013/zugferd_standard_f%C3%BCr_die_elektronische_rechnung

      Und wenn man wissen will, wie das hybride Format von ZUGFeRD international gesehen wird, dann lese man den Beitrag von Tim McGrath auf Linkedin "Time to move on with e-Invoicing" http://bit.ly/eINVOICING . Die USA sind auch auf dem Weg zu einem einheitliche E-Invocing-Verfahren: http://bit.ly/US-eInvoice. Und auch Australien hat einen neuen eInvoice-Standard: http://bit.ly/Aus-eInvoice. Und Europa (EN 16931 …), und Deutschland (ZUGFeRD, XRechnung …)? Global wird sich Deutschlands E-Rechnung-Standard ZUGFeRD nie positionieren können und auch ein europäischer Standard wird seine Probleme haben, wenn sich global etwas anderes durchsetzt: wenn die großen Internet-Companies sich auf einen Standard und ein Verfahren einigen.

      Antwort

Schreibe einen Kommentar zu uli Antworten abbrechen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich stimme zu, dass die von mir eingegebenen Daten einschließlich der personenbezogenen Daten an PROJECT CONSULT übermittelt und dort zur Prüfung der Freischaltung meines Kommentars verwendet werden. Bei Veröffentlichung meines Kommentars wird mein Name, jedoch nicht meine E-Mail und meine Webseite, angezeigt. Die Anzeige des Namens ist notwendig, um eine individuelle persönliche Kommunikation zu meinem Beitrag zu ermöglichen. Anonyme oder mit falschen Angaben eingereichte Kommentare werden nicht veröffentlicht. Zu Nutzung, Speicherung und Löschung meiner Daten habe die Datenschutzerklärung zur Kenntnis genommen.

Ich versichere, mit meinem Kommentar alle gültigen Vorgaben des Urheberrechts beachtet zu haben. Ich habe keine Bilder, Grafiken, Texte oder Links in meinem Beitrag verwendet, die durch CopyRight, Leistungsschutzrecht oder Urheberrecht geschützt sind. Für den Inhalt meines Kommentars bin ich trotz Prüfung und Freischaltung durch PROJECT CONSULT ausschließlich selbst verantwortlich. Meine Rechte am Beitrag werden bei PROJECT CONSULT nur durch die CC Creative Commons by-nc-nd Vorgaben gewahrt.