Ich greife mal das Thema eRechnung (ZUGFeRD) auf, die ja im Wachstumschancengesetz 2024 als demnächst verbindlich für den Business-to-Business-Bereich festgeschrieben wurde. Die elektronische Rechnung muss dann in Form eines PDF-Dokuments (für Menschen lesbar) und in Form einer XML-Datei (maschinenlesbar) übermittelt werden. Das sind aber zwei Dokumentformate, die mit erheblichen Risiken in Richtung "Verbreitung von Schadsoftware" behaftet sind. Ich werfe mal einen Blick auf dieses Themenfeld.
Anzeige
Elektronische Rechnung wird Pflicht
Ab dem 1.1.2025 wird die Verwendung einer elektronischen Rechnung (kurz eRechnung) zwischen Firmen – sogenannter Business-to-Business-Bereich (B2B) – verpflichtend eingeführt. Das ist im Wachstumschancengesetz 2024, welches im März 2024 verabschiedet wurde, festgeschrieben. Für kleinere Betriebe gibt es aber bis Ende 2027 Übergangsregelungen.
Das Ganze geht wohl auf die EU-Richtlinie 2014/55/EU aus dem Jahr 2014 für Rechnungen bei öffentlichen Aufträgen, die in elektronischer Form erfolgen muss, hervor. Haufe hat hier einige Informationen zusammen getragen, so sind für eRechnungen die Formate XRechnung und ZUGFeRD zulässig bzw. vorgeschrieben.
Was ist ZUGFeRD?
ZUGFeRD steht für Zentraler User Guide des Forums elektronische Rechnung Deutschland, ein grauseliger Name für eine Spezifikation zum Austausch elektronischer Rechnungen. ZUGFeRD-konforme Rechnungen sollen zwischen Unternehmen sowie zwischen Unternehmen und der öffentlichen Verwaltung schnell, komfortabel und einfach elektronisch ausgetauscht werden.
Die Spezifikation sieht vor, dass maschinenlesbares UN/CEFACT-XML in menschenlesbare PDF-Dateien (PDF/A-3) – gemäß der Richtlinie EU/2014/55 und des Standards EN16931 – einbettet werden. Damit sollen elektronische Rechnung noch für einen menschlichen Betrachter lesbar sein, aber auch maschinenlesbar für Software werden, die dann den XML-Datenteil auswerten.
Anzeige
Was ist XRechnung?
Bei XRechnung handelt es sich ebenfalls um einen Standard für elektronische Rechnungen, in dem die Rechnungsdaten in maschinenlesbarer Form (XML) vorliegen. Das ZUGFeRD 2.1.1 Profil "XRechnung" ermöglicht seit 1. Juli 2020 ebenfalls elektronische Rechnungen konform zur XRechnung im XML-Format zu erzeugen und damit für den Versand an öffentliche Auftraggeber zu verwenden.
Potentielle Sicherheitsprobleme und Fallen
Erstmals hat sich heise im März 2024 in diesem Artikel zum Thema geäußert und findet die Pflicht zur eRechnung eine gute Idee, deren Implementierung für Sicherheitsexperten aber kritische Fragen aufwerfen würde. Es wird allgemein auf die Komplexität von ZUGFeRD und das Problem XML-Valisierung eingegangen.
Hochrisikoformat ZUGFeRD?
Blog-Leser Patrick hatte sich in diesem Kommentar dagegen konkreter geäußert und schrieb: "Dafür hat die Bundesregierung ein Hochrisikoformat (PDF) mit einem weiteren Hochrisikoformat (XML) für den Rechnungsdatenaustausch kombiniert und unter dem Namen "Wachstumschancengesetz" ab 2025 verbindlich für alle Businessanwender vorgeschrieben. […] Hier öffnen sich echte Chancen für flächendeckende Cyberangriffe mit Trojanern, die auch alle Kundendaten von Handwerkern, Einzelhändler etc. betreffen." Ich fand den Kommentar spannend, so dass ich einige Punkte in diesem Blog-Beitrag aufbereiten möchte.
PDF-Format als Risiko
Patrick hatte mit seinem obigen Kommentar einerseits das Risiko PDF-Austauschformat im Sinn. Hinsichtlich des Risikos muss man beim Adobe PDF-Datenformation zwei Sachen unterscheiden:
- a) die Möglichkeit, Scripte in JavaScript in die Dokumente einzubetten
- b) die Implementierung der PDF-Reader, die immer wieder durch Schwachstellen auffallen
Beide Punkte stellen ein immanentes Risiko dar, sobald PDF-Dokumente als ZUGFeRD flächendeckend durch die Lande geschickt werden.
XML-Format als Risiko
Bei ZUGFeRD werden zusätzlich XML-Daten für die Rechnung im PDF-Dokument eingebettet. In der Theorie ist XML ein Format zum Datenaustausch, dessen Struktur und Inhalt daraufhin überprüft werden kann, ob diese "wohlgeformt" sind und der Spezifikation entsprechen. In der Praxis muss ein XML-Dokument durch einen XML-Parser eingelesen, validiert und interpretiert werden. Und an dieser Ecke lauern die Risiken, wenn beispielsweise Data-Inhalte im XML-Dokument den XML-Parser aus dem Tritt bringen und zu Pufferüberläufen, Code-Ausführung etc. führen.
Befragt man mal das Web nach XML und Sicherheit, wird man auf das OWASP XML Security Cheat Sheet stoßen. Das Dokument befasst sich mit der Frage, was passiert, wenn der XML-Teil eines Dokuments nicht den Spezifikationen für wohlgeformtes XML entspricht und gibt folgende Antwort:
Unexpected consequences may result from manipulating documents using parsers that do not follow W3C specifications. It may be possible to achieve crashes and/or code execution when the software does not properly verify how to handle incorrect XML structures. Feeding the software with fuzzed XML documents may expose this behavior.
Da ist fast alles (mit Ausnahme der Detonation einer Atombombe) an Schlechtigkeiten drin. Dem XML-Parser kommt also eine zentrale Rolle zu, ob die XML-Daten sicher gelesen und nicht wohlgeformte Dokumente abgewiesen werden. Da wir alle wissen, dass diese Implementierungen mitunter "steil gehen" und erhebliche Sicherheitsrisiken aufreißen, sind wir mitten im Thema.
eRechnung legt Deutschland lahm?
Der oben erwähnte Kommentar von Patrick stellt darauf ab, dass eine mit schädlichen Inhalten gespickte eRechnung im ZUGFeRD-Format für allerlei Angriffe genutzt werden könnte. Massenhaft an Firmen geschickt, könnte man mit eRechnungen – dank der Hochrisikoformate PDF und XML – halb Deutschland lahmlegen.
PDF und eingebettetes JavaScript
Bezüglich PDF ist es vor allem eingebettetes JavaScript, welches zahlreiche Angriffsmöglichkeiten bietet. Ich habe mal ein wenig recherchiert, laut den Empfehlungen des Bundesarchivs zur Anwendung der verschiedenen PDF/A-Versionen ist das Einbetten von JavaScript-Inhalten in PDF/A-3, welches ja bei ZUGFeRD genutzt wird, verboten. Andererseits ist das Einbinden von Dateien beliebiger Dateiformate zulässig. Theoretisch ist durch das Verbot von JavaScript-Inhalten in PDF/A-3 eine große Sicherheitsproblematik entfallen. Praktisch stellt sich die Frage: Halten sich die PDF-Generatoren daran? Und wie sieht das in der Praxis aus?
Problem XML- und PDF-Reader-Bibliotheken
Ein PDF-Reader für die eRechnung müsste also JavaScript-Inhalte in einer PDF-Datei ignorieren oder die Datei sogar abweisen. Ich bin mir aber nicht sicher, ob das so passiert. Im Zweifel setzen die Programmierer auf eine Bibliothek zur Verarbeitung von JavaScript oder auf den Adobe Reader und das wandelnde Sicherheitsrisiko ist im System.
Zudem: Ich gehe davon aus, dass eRechnungen, die beim Empfänger eintrudeln, von diesem in einem normalen PDF-Reader geöffnet werden. Im dümmsten Fall reicht ein Doppelklick auf die Rechnungsdatei, und diese geht im Microsoft Edge mit integriertem PDF-Reader auf (die Integration ist ja angekündigt). Wenn dann noch JavaScript aktiviert ist, wird es lustig.
Heiß zu deutsch: Wenn sich eRechnungen nicht an die Vorgaben von PDF/A-3 halten und der Reader zur Anzeige des PDF-Inhalts patzt, sind damit wunderbar Angriffe ausführbar. Ähnliches gilt für den eingebetteten XML-Dokumentteil der eRechnung. Wenn dieser bösartige Inhalte enthält und nicht vom XML-Parser abgewiesen wird, öffnet dies für Angriffe und Manipulationen Tür und Tor.
Und wir haben es ja nicht mit einer Software a la Adobe Reader oder Adobe Acrobat zu tun, sondern jeder Anbieter, der Buchhaltungssoftware strickt, wird da seine eigene Suppe kochen. Das wird ein gefundenes Fressen für Sicherheitsforscher und ein Alptraum für Leute, die vor gefundenen Schwachstellen warnen und Updates anmahnen.
Allerorten Zwang zu JavaScript …
Administratoren könnten möglicherweise die Unterstützung von JavaScript per Gruppenrichtlinien in Software wie Edge oder im Adobe Reader etc. deaktivieren. Dann wäre ein Angriffsvektor entschärft.
Problem sind dann aber Szenarien, die aktiviertes JavaScript zwingend erfordern. Das ist beispielsweise der Fall, wenn Formulare in PDF-Dokumenten auszufüllen sind. Patrick hat mich in einer Mail beispielsweise darauf hingewiesen, dass die Bundesagentur für Arbeit da in ihrer Hilfe folgendes schreibt.
"Zum Öffnen der auf unseren Internet-Seiten zum Download angebotenen PDF-Dokumente benötigen Sie einen PDF-Reader bzw. PDF-Viewer oder einen aktuellen Browser, der die Ansicht von PDF-Dateien unterstützt.
[…]
Das Ausfüllen interaktiver Formulare im Browser wird aus
Sicherheitsgründen nur eingeschränkt unterstützt. Daher ist in der Regel die Installation eines separaten PDF-Reader erforderlich. Es bieten jedoch nur wenige PDF-Reader zusätzlich komfortable Funktionen zum Ausfüllen von Formularen an, unterstützt wird diese Funktion zum Beispiel vom Adobe Acrobat DC, dem Foxit Reader oder dem Master PDF
Editor für Linux."
Kann man zur Kenntnis nehmen, scheint ja potentiell noch nichts schlimmes. Schaut man aber nach dem empfohlen Adobe Acrobat DC, findet sich bei Adobe bekommt man zur Überschrift "Interaktiv." dann folgende Erklärung:
"Mit JavaScript kannst du deine PDF-Dokumente um Berechnungen, Validierungsregeln und Schaltflächen mit zugewiesenen Aktionen erweitern."
Doch dies ist nicht nur auf die PDF-Reader von Adobe begrenzt. Mittlerweile unterstützen auch aktuelle Browser interaktive Inhalte mit JavaScript verarbeiten, z. B. Firefox (hier ein Verweis auf die Warnung "CVE-2024-4367: Arbitrary JavaScript execution in PDF.js" von Mitte Mai 2024).
Abschließende Gedanken
Patrick wies mich auf das große Problem hin. Weil auch die Webseiten der BfA, der Bundesregierung und den meisten weiteren öffentlichen Stellen ohne JavaScript gar nicht mehr funktionieren, stellt sich die grundsätzliche Frage nach der Cybersicherheit.
Hier fällt mir ein Spruch aus der Bauwirtschaft ein "Beton, es kommt darauf an, was man damit macht", der mir in den 80er Jahren mal untergekommen ist. Im Sinne der eRechnung abgewandelt, heißt es "es kommt darauf an, was man damit macht". Optimisten werden jetzt sagen, das kriegen wir hin. Pessimisten fragen "was kann schon schiefgehen", um dann den Erfahrungswert "alles" nachzuschieben.
Das ist auch der Tenor des oben erwähnen heise-Artikels E-Rechnung und ZUGFeRD: Sollen Menschen XML und PDF vergleichen – srsly?, welcher in der URL die Aussage "Pflicht zur eRechnung als trojanisches ZUGFeRD" enthält.
So einen kleinen Vorgeschmack aus der Praxis liefert Blog-Leser R.S. in diesem Kommentar. Er sei "gerade dabei, den Mist zu implementieren" schreibt der Leser und zieht vom Leder, wo es überall hakt. Läuft mit (der) Sicherheit.
Was mich an dieser Stelle wundert: Das Thema ist mir bisher so nicht in den einschlägigen Medien untergekommen. Ohne den Hinweis von Patrick zu einem Blog-Beitrag, in dem es um die Digitalkompetenz einer großen deutschen Partei ging, wäre mir das "Lichtlein auch nicht aufgegangen".
Anzeige
EDIFACT wäre grundsätzlich die Alternative. Das kommt als reine Textdatei daher und ist zu 99,99% sicher. Die Übermittlung per Mail mit S/MIME und Authentizität und Verschlüsselung wäre damit gewährleistet… Kinderspiel, inbesondere eben bei B2B!
Aber NEIN, der Standard existiert einfach schon zu lange, das ist nicht mehr Hipp.
Hat nicht so eine coole Abkürzung für einen bescheidenen Standard wie ABEGALFTERTERGAUL.
Wundert mich auch, daß die Lobby dafür nicht stärker ist. Nahezu alle großen Konzerne (Baumärkte, MCDonalds..) und vor allem die Automobilindustrie und deren Zulieferer nutzen Edifact. Die Infrastrukur ist zudem kostengünstig zu betreiben (bei Setup sieht das anders aus), einmal eingerichtet ein Selbstläufer.
EDIFACT wird für die elektronische Rechnung sogar ab 2028 verboten, bis dahin gilt eine Zustimmungserfordernis des Empfängers. Wir nutzen EDIFACT auch für Rechnungen und dürften 2028 ein seit Jahren laufendes System abreißen:
"Wir bauen auf und reißen nieder, so haben wir Arbeit immer wieder"
Edifact ist keine gute Idee, jedenfalls nicht für den generellen Rechnungsversand oder -Empfang.
Es ist zwar nicht zwingend vorgeschrieben, aber EDI Nachrichten kommen meist auf einem eigenen Transportweg (AS2 oder früher auch X400).
Außerdem ist der Weg fest verfirewalled. Uns schickst du nicht einfach so eine EDI-Nachricht, da werden Zertifikate ausgetauscht, Testverfahren durchgenudelt, danach kommst du ins Test und erst wenn alles läuft ins Produktivsystem.
Dazwischen hast du dich noch irgendwo mit deinem IT-Dienstleister und deinem ERP oder wenigstens deiner Buchhaltungssoftware amüsieren dürfen, was überhaupt an Nachrichten wie an wen verschickt werden darf. Und überraschenderweise halten die alle die Hände auf und wollen eine Kleinigkeit von dir.
Der Spaß kostet dich sehr schnell fünfstellig.
Das ist er nicht etwas für die Buchhandlung Lieschen Müller.
Davon abgesehen ist es tatsächlich absolut zuverlässig.
Wenn das eine reine Textdatei ist, wie macht ihr das dann mit dem Finanzamt und dem bildgebenden Verfahren für den Beleg?
Bei der Schnittstelle zu DATEV spuckt unser System auch nur CSV-Dateien für DATEV aus. DATEV allein ist zufrieden damit, aber das FA will die entsprechenden Rechnungsbelege als PDF/A oder TIFF, ansonsten stehen sie ganz schnell auf der Matte.
Oder ist das womöglich der Grund, weshalb EDIFACT bis 2028 abgekündigt wird, weil eben das "bildgebende Verfahren" für den Beleg fehlt?
"aber das FA will die entsprechenden Rechnungsbelege als PDF/A oder TIFF"
Nicht nur das FA, sondern auch andere Behörden inklusive der Agentur für Arbeit mit der Jobcentern arbeiten bevorzugt nur mit PDFund können z. B. keine Kontoauszüge im SEPA-XML-Format verarbeiten, obwohl gerade das XML-Format gesetzlich vorangetrieben wird.
Ich arbeite mit dem FA (und allen anderen Behörden und Organisationen) mittlerweile wieder ausschließlich auf dem Postweg, weil es digital hinten und vorne nicht durchgängig funktioniert und die IT-Sicherheit nicht gewährleistet werden kann.
Speziell beim PDF-Format habe ich vor Jahren alle Reader aus den Systemen verbannt, weil neue Sicherheitlücken teilweise bereits mit Sicherheitsupdates bekannt geworden sind und man PDF aus Sicherheitsgründen deaktivieren musste. Dabei ist es vollkommen egal, welche Software man verwendet!
>>> Was mich an dieser Stelle wundert: Das Thema ist mir bisher so nicht in den einschlägigen Medien untergekommen. <<<
Mir schon; bspw. berichtete der deutsche IT-Blogger Günter Born schon 2011 (1) über eine kritische Sicherheitslücke in Microsofts XML Core Services ;-)
(1) http://www.borncity.com/blog/2011/07/13/kritisches-update-xml-core-services/
Zumindest das Thema PDF und XML vergleichen ist doch eher hinfällig, da ich schon davon ausgehe, dass bei Rechnungsübernahme die PDF kurz mit den ins System automatisch eingegebenen Daten kurz quergelesen wird von jemanden?
Ich kenne zumindest keine Buchhalter die hier nicht penibel alles kontrollieren. Zumindest die Tipparbeit wäre dann erspart.
Die Problematik ist richtig, in Bezug auf PDF aber nicht neu und auch kein Problem von ZUGFerD. Es werden ja jetzt schon massig PDF-Rechnungen verschickt, eigentlich fast ausschließlich.
Seh ich auch so.
Wenn wir damit argumentieren, dass die einlesende Software nicht korrekt implementiert ist, trifft das nicht nur auf den XML-Teil von eRechnungen zu sondern auch auf _alles_ andere. Einbetten von JavaScript in Kommentare zu Blog-Posts, entsprechend präparierte Header in Internet-Protokollen usw.
Prinzipiell muss sich aber keiner mehr die PDF-Datei angucken, wenn mein letzter Stand richtig ist, denn dann ist in der eRechnung der maschinenlesbare XML-Teil der führende Informationsträger. Und wenn man dann nur noch XRechnung verwendet, fällt auch das PDF-Format weg und man hat nur noch die "halbe" Angriffsfläche.
Ich kann mich nicht erinnern, wann ich zuletzt eine Rechnung anders als per PDF verschickt habe…
Zum Thema welche Blüten das Thema "Digitalisierung" treibt ein Beispiel aus dem Bereich private Krankenversicherungen. Ärzte versenden Rechnungen in Papierform, zumeist in doppelter Ausfertigung (Original + Kopie bzw. Duplikat). Die Kopie war Früher mal zur Sicherheit für den Versicherten gedacht, falls das Original auf dem Postweg zum Versicherer verloren gehen sollte. Denn der Versicherte muss seine Rechnungen zusammen mit einem Erstattungs-Antrag beim Versicherer Einreichen. Seit geraumer Zeit bieten (manche) Versicherungen auch die elektronische Übermittlung an, zb. mittels einer Smartphone-App, womit man die Papier-Rechungen und Rezepte vom Arzt / Apotheke einfach abfotografieren soll.
Da fragt man sich schon, in welchem Dschungel wir hier eigentlich leben?! Vermutlich ist die Papier-Rechnung gesetzlich verpflichtend vorgeschrieben und deshalb keine PDF oder sonstige elektronische Übermittlung vom Arzt zum Patienten möglich … dito was Rezepte betrifft. Die sind ausschließlich für GKV-Versicherte nun auch elektronisch verfügbar, was beim Bestellen in Online-Apotheken sehr hilfreich sein kann. Da die Original-Papier-Rezepte auf dem Postweg Eingesendet werden müssen, wenn man Online Bestellen möchte.
Der Irrsinn besteht nicht zuletzt darin, das Versicherer Unsummen in die Programmierung der Apps und weiterer IT-Infrastruktur Investierten um Rechnungen und Rezepte elektronisch verarbeiten zu können. Das erspart an anderer Stelle zwar auch Kosten bei der Verarbeitung des Posteingangs, da keine Kuverts mehr geöffnet werden müssen und man die enthaltenen Dokumente nicht selber Scannen muss, weil das mittels der App vom Versicherten erledigt wird … wie bei Banken, wo wir Kunden inzwischen die Arbeit des Eintippens erledigen "dürfen" (Überweisungen/ Daueraufträge).
Bei dem riesen Aufwand der da betrieben wurde/wird, fragt man sich auch, warum es nicht möglich war, das System gleich so umzustellen, das man zw. Arztpraxen und Versicherern eine Schnittstelle geschaffen hätte um Rechnungen direkt zur Versicherung zu senden und nur noch in Kopie zum Patienten?
Deutschland, die Dschungel-Republik mit seinen heiligen Ritualen und Gewohnheiten … oder schlicht inkompetenten Politikern und Führungskräften allerorten …
>>> das System gleich so umzustellen, das man zw. Arztpraxen und Versicherern eine Schnittstelle geschaffen hätte um Rechnungen direkt zur Versicherung zu senden und nur noch in Kopie zum Patienten?
Z.B. weil nicht jeder PKV Versicherte seine Rechnungen einreichen will, weil die Bonuszahlung ohne Einreichung höher ist, als die Erstattung der eingereichten Rechnungen?
Und dann gibt es ja sicher auch jene, die ihrer PKV nicht alles auf die Nase binden wollen?
Wie schon Tegtmeier sang: „Wat man nich selba weiß, dat kann man sich erklä-ären." Auf diese Weise scheint die hahnebüchene Behauptung entstanden zu sein, die Rechnungskopie sei eine Sicherheit gegen Verlust auf dem Postweg. – Das wäre doch unlogisch, weil beides in einem Umschlag verschickt wird. Auch eine eventuelle Kaffeefleck-Hypothese stimmt nicht. Die Rechnungskopie ist zum Einreichen bei Zusatzversicherungen gedacht – bloß nicht der Krankenversicherung damit kommen, die schickt alles postwendend zurück, wo das Wort „Kopie" draufsteht.
So, und nach diesem Lapsus erscheinen die folgenden Ausführungen nicht mehr stichhaltig. Bevor man von „schlicht inkompetenten Politikern und Führungskräften allerorten" schreibt, sollte man sich erst selbst schlau machen!
Grundsätzlich sind PDF-Reader oft "fehlerbehaftet". Auch hier gilt es, zumindest verfügbare Patches zeitnah einzuspielen!
Ich weiss nicht wie es in Deutschland gehandhabt wird. Aber zumindest hier in der Schweiz sind heute über 80% der B2B Rechnungen und wohl über 95% der B2C Rechnungen PDF-Rechnungen. Wie sieht das in Deutschland aus, werden da effektiv in 2024 noch Papierrechnungen versandt?
Sollten Rechnungen, egal in welcher Form, nicht wie ein Teil der Lieferkette betrachtet werden? Hier läuft es ja im Endeffekt auch über Vertrauen, klar wird noch das eine oder andere durch Zertifikate bestätigt, aber im Endeffekt kann ich alles fälschen, also bleibt nur Vertrauen als Basis.
B2C kann man in Deutschland zunehmend seiner Rechnung hinterherrennen.
Für Direktkäufe vor Ort gilt zwar dank Ex-Finanzminister Scholz die sture Bonpflicht: Keine Kugel Eis ohne armlangen Kassenzettel (theoretisch).
Aber bei Online-Bestellungen heißt es immer öfter „Wieso, Sie haben doch die Bestätigungsmail, und für den Rest ist PayPal/Ebay/Ihr Zahlungspartner zuständig. Oder wollen Sie ein Rücksendelabel? Das können Sie sich auf unserer Website generieren." So baut der Verkäufer auch gleich eine Hürde für Gewährleistungsfälle auf, wo man den Kauf datumsgenau nachweisen müsste.
Rechnung per PDF ist Luxus, machen vielleicht 50%, aber auch davon schicken sie manche nicht zu, man muss sie sich erst nach Login und Suchen von der Homepage runterladen.
Ich habe wenig dagegen, Papierrechnungen einzuscannen. Aber dass ich inzwischen mit Screenshots meine Anschaffungen dokumentieren muss, weil Webshops mehr auf Design als auf kaufmännischen Grundgepflogenheiten basieren, ist wirklich frustrierend.
1+
Es gab mal eine Zeit, das unsere kompetenten, Weltmänner von Politikern vorgeschrieben haben, das alle elektronischen Rechnungen mit einer "qualifizierten Signatur" zu versehen sein, ein Milliardengeschäft für die Telekom, die einzigen relevanten Anbieter IIRC. Oder die Rechnung musste im Original in papierform vorliegen, PDF selbst ausdrucken ging gar nicht, man hätte die Zahlen ja ändern können…(komplett hirntot diese Idee des Finanzamts. Das wäre bei der nächsten Buchprüfung aufgefallen, dank USt-ID auf jeder Rechnung).
Was für weltfremde Lösung waren da angedacht.
Dieses Verfahren sehen auch so aus "ich hab da neulich in einer Weiterbildung mal was von XML gehört".
Ach, und außerdem fällt mir da noch die elektronische Zoll-Erklärung ein, Projekt Atlas. Erfordert hochwertige Zertifikate und war im Alltag langsamer als das Papier. Und wurde nach mehrere Jahren des probierens von heute auf morgen Zwang, ohne allerdings gleichzeitig noch ein paar Details an der Schnittstelle zu ändern. Irgendwelche Sicherheitsbedenken wurden meines Wissens nicht diskutiert. Man traute sich ja…
> das alle elektronischen Rechnungen mit einer "qualifizierten Signatur" zu versehen sein, ein Milliardengeschäft für die Telekom, die einzigen relevanten Anbieter IIRC.
Na wohl eher die Aasgeier, äh, ich meine Allgeier SE ;c) Die haben schon vor 20-25 Jahren Mondpreise für Signatur-Krimskrams genommen, als die Telekom gerade so DSL ausrollte, um das Postkupfernetz zu retten.
Ein Sicherheitsrisiko so mit ZUGFeRD bzw. der eRechnung in Kontext zu setzen, finde ich grenzwertig.
Das ist zunächst ein reines PDF-Thema, und PDFs sind heute schon ein Risikofaktor Nummer 1. Wer diese ohne entsprechende Sicherheitsmaßnahmen einfach empfängt und öffnet, hat ohnehin ein Problem. Es werden bereits sehr viele Belege per PDF versendet, das wird also höchstens etwas mehr (aber nicht unsicherer … unsicherer wie es heute schon ist (mit PDF) geht es eh nicht mehr ;-)).
Das Thema XML sollte man wirklich differenzierter betrachten. Rein vom Öffnen einer XML-Datei in einem Editor passiert zunächst gar nichts. Sicherheitsprobleme können erst auftreten, wenn die XML-Datei von einem Parser verarbeitet wird. Ein schlecht gesicherter oder veralteter Parser kann anfällig für Angriffe wie XML External Entity (XXE) Injection oder Denial-of-Service (DoS)-Angriffe sein. Deshalb ist es beim Thema eRechnung unerlässlich, dass alle eingehenden XML-Daten durch einen Validator und entsprechende Sicherheitslösungen geprüft werden, bevor sie weiterverarbeitet werden. Dies ist ohnehin ein notwendiger Schritt, da man sonst nie sicher sein kann, ob man eine konforme eRechnung gemäß EN16931 (also ZUGFeRD ab Version 2.01 oder XRechnung) erhält. So kann sichergestellt werden, dass es sich um ein valides (XML) Format handelt, welches den Anforderungen entspricht und keine schädlichen Inhalte enthält. Zusätzlich müssen die XML-Daten auch visualisiert werden, da die elektronischen Daten bei der eRechnung gegenüber dem bildhaften Teil der PDF führend werden.
Mit Bezug auf den Artikel "Wachstumschancengesetz 2024: Rechnungsdatenformat ZUGFeRD als Risiko?" finde ich die Darstellung des ZUGFeRD-Formats als Risiko grenzwertig, wenn nicht unseriös.
Beispielsweise der Satz:
Beide Punkte stellen ein immanentes Risiko dar, sobald PDF-Dokumente als ZUGFeRD flächendeckend durch die Lande geschickt werden
Diese Darstellung kann technisch weniger informierte Personen leicht in die Irre führen und eine völlig falsche Sicht auf den eigentlichen Bedrohungsvektor vermitteln. Tatsächlich geht es um die eigentlichen Formate PDF (und in Teilen XML), die heute schon absolut verbreitet und einer der Hauptangriffsvektoren sind. Es wäre sinnvoller, sachlich und differenziert über die tatsächlichen Risiken und Sicherheitsmaßnahmen aufzuklären, um eine fundierte Diskussion zu ermöglichen.
Nebenbei schreibt die "Bundesregierung" kein ZUGFeRD Format vor. Es ist halt für den Empfänger einfach "praktisch" noch das klassische Belegbild (PDF) zu erhalten. Und an einem strukturierten Datenformat führt eh kein Weg vorbei. Und egal ob XML oder JSON oder oder oder es bleibt immer ein Risko sobald man Daten verarbeitet. (und das fängt bei einer Mail oder HTML Seite an).
Wenn wirklich Interesse besteht, sachlich in das Thema eRechnung einzusteigen, stehe ich gerne zur Verfügung.
>>> PDFs sind heute schon ein Risikofaktor Nummer 1 <<<
Genau, und ausgerechnet damit will man Rechnungen transportieren, eine Dokumentenart, bei der naturgemäss kaum jemand mehr einem Doppelklick widerstehen kann.
Du scheinst wohl schon zu sehr wirtschaftlich mit der Sache verflochten zu sein. Anders kann ich mir eine Plattheit wie (1) nicht erklären.
(1) "Es wäre sinnvoller, sachlich und differenziert über die tatsächlichen Risiken und Sicherheitsmaßnahmen aufzuklären, um eine fundierte Diskussion zu ermöglichen." nicht erklären"
Diskussion hin oder her, wir werden damit leben müssen.
Die einzigen Papierrechnungen, die ich in den letzten zwei Jahren erhalten habe, kamen vom Arzt. Sonst kommen Rechnungen auf der Arbeit zu einem Drittel als XRechnung, der Rest als PDF. Privat bekomme ich nur noch PDF-Rechnungen.
Naja und was hintert daran sowas verschlüsselt und signiert zu übertragen (verhindert schonmal eine Manipulation von aussen)… man sollte sowieso Daten egal in welchem Format niemals ungeprüft in das eigene System lassen und Rechnungen die ich von Dritten kriege für die kein interne Auftrag existiert werden direkt nach text only gewandelt. (das passiert vollkommen automatisiert) Dann kann der Sachbearbeiter das gefahrlos anschauen.
Eine Leichtigkeit für ein Großunternehmen. Aber wie organisiert man das ordentlich und aktuell für eine typische mittelständische Firma mit 2 Arbeitern, einen Inhaber der auch nur arbeitet und einer Halbtagsbürokraft? Da ich in einer größeren Firma arbeite kenne ich die Antworten oder weiß woher ich die bekomme. Aber besagte Kleinfirma hat halt weder Zeit und das Geld, sich mit sowas zu beschäftigen. Man müsste somit mehr Zeit nehmen und die Kosten dem Endkunden aufschlagen. Bei Kleinbetrieben merkt man den Aufschlag dann auch.
Ist wie immer – aber noch ist dahingehend praktisch nichts passiert:
IT-Sicherheit fängt bei den Herstellern der Softwareprodukte an – dann kommt fünf Lichtjahre lang gar nix – dann irgendwo die Admins und zuletzt die Anwender. Es bleibt beim alten Thema: Die Menschheit benötigt dringend ein Haftungsrecht für (Standard-)Software wenn sie mit der Digitalisierung weitermachen machen. Microsoft mit einem Patch irgendwas kaputt? Das muss sofort eine Zahlungsverpflichtung Auslösen mit einem definierten Mindestwert – also z.B. 1000facher Preis des eigentlichen Produktes, oder den doppelten Betrag des entstanden Schadens – der höhere Wert gilt. Mal sehen wie lange es dauert bis MS wieder eine echte Qualitätssicherungs-Abteilung mit echten Menschen aufbaut…
Da stimme ich voll zu auch für Software muss ein Haftungprivileg her! Dann geht Sicherheit sehr schnell, sehr gut. Wen die Firmen auf einmal ihre Gewinne davon schwimmen sehen.
Also ich beschäftige gerade mal 30 Angestellte bin also alles andere als groß … und es geht, man muss halt nur wollen. Ist ja letztendlich zum Selbstschutz. Ausserdem kann man das ja auch outsourcen wenn man das nicht selbst stemmen möchte. Geht nicht ist ne faule Ausrede!
Bei nem Vorfall ist sonst nämlich so eine 3 Mann Butze pleite!
Sicherheitsvorkommnisse sind eben noch viel zu billig in den Strafen!
Ich habe da mal eine Verständnisfrage die vielleicht etwas OT ist: Bei der ganzen ZUGFERD Geschichte ist, wenn ich es richtig verstehe, ja vorgesehen ein PDF und ein XML Dokument zu verschicken (bzw. ein PDF mit XML drin?), damit das einmal Menschenlesbar und einmal Maschienenlesbar ist. Was theoretisch die Gefahr birgt, dass in beiden unterschiedliche Sachen drin stehen könnten, zumindest wurde das in einigen Kommentaren auch auf anderen Seiten so angemerkt. Weil ja die meisten Leute, die eine Rechnung bearbeiten, den XML Teil nicht interpretieren können werden können die das nicht oder nur schwer mit dem PDF-Teil vergleichen.
Aber warum wäre das überhaupt nötig, bzw. warum muss das überhaupt ein PDF sein? Das XML muss ja von einem Programm eingelesen werden, somit sollte es doch nicht schwer sein, dessen Inhalt dann auch dem Menschen lesbar anzuzeigen, die Daten hat das Programm dann ja schon. Oder übersehe ich hier was grundsätzliches?
Absolut richtig, aber das wird man erst plötzlich und völlig überraschend bemerken, wenn ein paar Firmen abgezogen wurden wo Geld dann an ein ganz anderes Konto rausgegangen ist o.ä.
Deswegen ja meine Frage, ob mir irgendwer plausibel erklären kann, warum man da mit zwei Formaten arbeitet und nicht einfach das Programm, dass die XML einliest, das für den Menschen lesbar aufbereitet. Ich bin kein Programmierer/Entwickler, aber ich stelle es mir jetzt nicht so kompliziert für, da im Programm eine Anzeige der Daten für Menschen in benannten Feldern zu ermöglichen. Es sei denn, ich verstehe irgendwas grundlegendes falsch.
Hast du schonmal erlebt das im #Neuland unser Politik was vernünftiges gemacht hat? Also ich nicht!
Da hat halt wieder irgendein Lobbyverein ihre Vortsellungen "verkauft*"…
*bestochen wäre das korrete Wort ;-P
Es geht um Corporate Design, könnte man zwar mit xml und XSLT realisieren, aber PDF kennen alle.
Zufällig hatte ich vorgestern wg. der eRechnung eine kleine Schulung gemacht. Was mir aufgefallen ist, ist dass für den Rechnungsempfang auch noch einheitliche Email-Adressen benutzt werden sollen. Und zwar immer die erechnung@ Somit brauchen Spamversender nur noch Bots nach Domains suchen lassen und die Emailliste für das schnelle Ausrollen von mit Schadsoftware versehenen Rechnungen ist ein Leichtes. Mühe geben müssen sich die Spammer nun auch nicht mehr, da man die XML-Rechnungen auch nicht mehr direkt anschauen kann. Somit ist es auch ein Leichtes mal eben Rechnungen mit abweichender Kontonummer zu verschicken. Von solchen Massenspamschäden werden wir noch so einiges hören.
"….dass für den Rechnungsempfang auch noch einheitliche Email-Adressen benutzt werden sollen. Und zwar immer die erechnung@…"
Naja, sollen ist nicht müssen.
Ich war nicht an Deiner Schulung, aber vermute mal, dass sich das "einheitlich" auf ein einzelnes Unternehmen bezieht und das "erechnung@" nur als Beispiel gedacht war.
Innerhalb eines Unternehmens ist es ja schon sinnvoll, Rechnungen nur an einer bestimmten Email-Adresse entgegenzunehmen (macht mein Arbeitgeber z.B. ganz ohne E-Rechnung schon lange so). Aber dass jedes Unternehmen dafür den gleichen Prefix verwenden soll, ergibt ja überhaupt keinen Sinn.
Wer sagt, daß diese E-Mail-Adressen benutzt werden sollen?
Ich habe noch keine Rechnung an so eine E-Mail-Adresse geschickt.
Für die grossen Firmen mag das alles eine Erleichterung sein (bis eine verseuchte Datei eingelesen wird…), aber wer denkt eigentlich an die vielen kleinen und mittelständischen Firmen. Die sind jetzt schon mit Bürokratie überfrachtet und jetzt auch noch der digitale Rechnungskram – und wenn der Hersteller der BuHa-Software nicht alles so programmiert, dass verseuchte Rechnungen nicht durchkommen, dann wird es richtig spassig.
Ich hoffe das nach einem Regierungswechsel, der aktuelle Bockmist erstmal gestoppt wird und nochmal (sicher) überarbeitet wird. Alle meine Kunden (alles KMU) warten erstmal ab, ob da noch was geändert oder vielleicht sogar gestoppt wird…
Ich halte dagegen und teile die Sorgen NICHT.
Wer als Verantwortlicher im Jahr 2024 immer noch nicht seine elementarsten Hasuaufgaben zum Absichern seiner Windows-AD Infrastruktur ergriffen hat, der verdient es von einer PDF mit JS-Downloader auch ausgeknipst zu werden. Zurecht! Hoffentlich dann nachhaltig schmerzhaft mit saftigen Schäden oder gar Insolvenzen.
Wer SRPs ausgerollt hat, seine Fachanwendungen/Systeme vom Internet auf Terminalservern isoliert hat, alle ein- und ausgehende Gateways close-monitored, der kann milde über diese Diskussionen lächeln.
Was kann schlimmstenfallls passieren? Ein JS in einer PDF legt eine .exe .ps oder sonstige ausführbare Datei in Appdata oder temp und versucht diese zu starten. Auf einem vom Internet isolierten System passiert genau nichts. Kommt noch SRP hinzu gibt es eine Warnung. So what?
Es gibt wichtigere Diskussionen zu führen also so ein Gaggelfax.
Ich bin endlich froh, dass es einen einheitlichen und verpflichtenden Standard für Unternehmen gibt.
Ich denke, der Kommentar führt ziemlich an der Lebenswirklichkeit vorbei! Wie viele KMUs sind in der Lage, die geforderten ständigen Sicherheitsaktualisierungen und Policies zu implementieren und aktuell zu halten? Oft wird es an Dienstleister irgendwie übertragen, die das dann auch oft nicht beherrschen bzw. aus Preisgründen auch nicht abdecken können.
Aber egal, gibt doch nur zwei Varianten: Es passiert nix – oder Born hat mal wieder die Pferde scheu gemacht. Leben kann einfach sein.
Wie viele KMUs sind in der Lage, die geforderten ständigen Sicherheitsaktualisierungen und Policies zu implementieren und aktuell zu halten? Seltsamerweise alle KMUs, die von mir im letzten Jahrzehnt betreut wurden ;-)
Lass uns mal in einen Diskurs gehen. Was genau soll denn so aufwändiges Hexenwerk und Cyber-Voodoo sein, was ein KMU mit oder ohne eigener IT-Abteilung nicht hinbekommt?
1. (Virtualisierte) Terminalserver für seine Desktops und/oder Fachanwendungen zu betreiben?
2. SRPs im AD auszurollen? (seit 2002 Bestandteil in jedem Windows)
3. Einen eigenen WSUS für automatisch Windows-Updates zu betreiben?
4. Einen zentralen Terminalserver vom Internet zu isolieren?
5. Mailgateways und Web-Proxies verwenden? Idealerweise mit einem IPS oder mindestens einer WAF.
Ich habe in meinem Blog diese sieben Security-Tipps niedergeschrieben, die ich seit Jahrzehnten befolgte und an dieser Front einfach nur Ruhe habe.
https://blog.jakobs.systems/blog/20240506-service-tips-windows/
Vielleicht werde ich auch alt, bin dieses Gejammere von den typischen WWW (Wald-Wiesen-Windows) Admins einfach nur müde. Ich kann diese Ignoranz und Bequemlichkeit immer weniger ertragen mit der so manche meinen Ihren Job zu machen – machen Sie nicht.
Aber was weiß ich schon…
"Seltsamerweise alle KMUs, die von mir im letzten Jahrzehnt betreut wurden ;-)"
Trifft es genau: Flächendeckend sichergestellt, oder eher die Firmen, die von dir und einigen fitten Kollegen betreut werden? Sieh es mir nach, wenn ich skeptisch bin – lasse mich aber gerne überzeugen, dass "IT aus der Hölle" nur ein Hirngespinnst ist.
Alles gut, Skeptik ist angebracht. Ich verweigere mich nur der Annahme, dass alle Admins und IT Verantwortlichen in KMUs da draussen dumm, bequem und ignorant sind. Das sind ganz viele genau nicht. Doch das wäre genau Dein Narrativ dann.
Wer seinen Job richtig macht, hat nichts zu befürchten. Das ist die Message bei jeder Neuerung oder Verbesserung. Ängstlich sind nur die wirklich dummen, faulen und unverbesserlichen.
Und diese müssen einfach evolutionär Aussortiert werden. Damit diese nie mehr wieder in die Nähe von irgendwas mit Tastatur oder Internetanschluß kommen.
Naja dann sind wir mal so frei … KMU die die Grundlagen nicht gebacken kriegen… verschwinden am besten heute als morgen!
Ist jetzt hart ausgedrückt, trifft aber den Nagel auf den Kopf… Wenn du dein Geschäft nicht beherrschst, hast du in der Geschäftswelt (IT) nix verloren!
Kommt dann auch dem Kunden zugute der geschützt ist.
Und wenn du das nicht selbst stemmen willst ja dann sourced du das halt aus(aber an jemand ders auch kann und nicht jemand der nur billig ist)
Und die Organisationen und Unternehmen, die durch einen Cyberangriff lahmgelegt werden, nehmen wir dann auch vom Markt? Dann bleibt wohl bald nicht mehr viel übrig von der Wirtschaft in Europa.
PDF + XML annehmen zu müssen ist eine digitale Bastellösung! Dazu bestehende digitale Verfahren (EDIFACT) nicht mehr zu erlauben spricht aus meiner Sicht auch nicht von Kompetenz.
Wenn ich mir die hier eingehenden E-Mails der vergangenen Monate und Jahre so anschaue, kämpfen alle noch mit der grundlegenden Technik in Sachen Internet …
>>> SRPs im AD auszurollen? (seit 2002 Bestandteil in jedem Windows) <<<
Baseline aus (1): "Software Restriction Policies were deprecated beginning with Windows 10 build 1803 and also applies to Windows Server 2019 and above."
Und dann das von Herrn Born penibelst dokumentierte Hickhack unter (2)!
Mit Deiner rhetorischen Frage "… was ein KMU … ohne eigener IT-Abteilung nicht hinbekommt?" hast Du Dich wohl vergaloppiert.
(1) learn.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies
(2) borncity.com/win/2023/02/24/software-restriction-policies-safer-still-possible-under-windows-11-22h2/
Das haben Sie recht. KMUs können sich in der Regel diesen Sicherheitsaufwand kaum leisten und verfügen auch nicht über die entsprechenden Spezialisten. Die Dienstleister kennen nicht die gesamte Netzwerkumgebung, sondern nur bestimmte Bereiche, für die sie gebucht wurden.
"Was kann schlimmstenfallls passieren? […] Auf einem vom Internet isolierten System passiert genau nichts. […]"
Ich schließe mich Günter mit Blick auf Kleinunternehmer und Freiberufler (Journalisten, Künstler etc.), die oft einen einzelnen Computer für Ihre Arbeit, die Verwaltung und das Online-Banking (!) verwenden, ebenfalls an. Ein vom Internet isoliertes System ist so gar nicht möglich.
Meine Kritik am PDF-Format, das mit der gesetzlichen Regelung zur elektronischen Rechnung im XML-Format als Vorrang überflüssig wird, wird durch die zahlreichen Sicherheitsmeldungen bestätigt. Dazu kommt noch das Problem der nicht verfügbaren Anzeigemöglichkeit auf allen Systemen, weil üblicherweise das DIN-Druckausgabeformat fest eingestellt ist. Damit fällt auch die mögliche Barrierefreiheit weg. (Ich arbeite ausschließlich im Terminalmodus und bevorzuge Text-WWW-Browser, weil Texte viel angenehmer lesbar sind.)
Die Zwangsdigitalisierung der Eingangsrechnungen bedeutet auch für mich einen Medienbruch, weil der Rest der Verwaltung durchgehend auf Papier stattfindet und selbst die Behörden sich bis heute lieber Belege auf Papier vorlegen lassen oder diese sogar verlangen. (Der Umfang ist etwa ein Ordner – für 10 Jahre!) Ab 2025 wird es damit spannend, wenn nicht alle Behörden XML-Daten verarbeiten können …
Ich bin nicht gegen die Digitalisierung, aber es gibt Grenzen und man muss immer auch den Aufwand und den Nutzen im Blick haben. Gerade hin zu sehr kleinen Organisationen ist die Schnittstelle auf Papier oft bis heute die bessere Lösung.
In einer perfekten oder aber auch Traumwelt wäre das schön, die Realität sieht aber anders aus.
Ein hohes Sicherheitsrisiko stellen die zudem verlangten einheitlichen Anfänge der Emailadressen an. Die Crawler müssen dann nur noch nach den Domainendungen suchen und haben dann ruck zuck schöne Listen fertig. Zudem müssen sich die Spam-Versender bei XML-Rechnungen keine Mühe mehr beim Kopieren von Rechnungsdesign geben. Kontonummern sind außerdem direkt in den Rechnungen enthalten und werden automatisch ausgelesen. Wenn man alles bedenkt, wird einem schnell klar, dass wir hiervon noch eine Menge in diesem Blog hier lesen werden.
"einheitlichen Anfänge der Emailadressen"? Das habe ich noch gar nicht gehört?
Kannst du das konkretisieren?
Danke
Beispielsweise als Mailadresse immer erechnung@tld
Kommt eine ZUGFERD-Rechnung auf einer anderen Mailadresse rein, vom Mailserver automatisch abweisen lassen.
Und Whitelisting auf die erechnung@tld.
Nur Firmen, bei denen mn tatsächlich etwas gekauft hat, kommen in die Whitelist.
Damit hält man sich dann schon einmal die allermeisten Schädlinge von der Mailadresse fern.
Beim Thema PDF sehe ich auch ein Risiko, was aber im wesentlichen an Adobe liegt.
XML ist erstmal auch nur Text. Ob ein anderes Format mit neugeschriebenen Parsern sicherer wäre, wage ich zu bezweifeln.
Generell mag ich es nicht, dass es zwei Datensätze mit evt. unterschiedlichen Inhalten gibt. Auch wenn man sagt, dass der XML-Datensatz verbindliche ist, ist es ja genau der, der in der Anzeige schwieriger ist. Da sind Probleme durch den Menschen ja vorprogrammiert.
Auch in der von uns genutzen Software gibt es diese Möglichkeit. XML wird erstellt und daneben ein Word, dass wiederum in PDF gewandelt wird. Bei der Kontrolle sieht der Anwender aber nur das PDF, ob der XML-Datensatz korrekt ist, kann man nur hoffen.
das ding wird über e-rechnungsportale laufen..
die hoffentlich quer scannen…
zudem landen die rechnungen dann noch (hoffentlich) in den clouds der buchhaltungsprogramm-anbietern, die quer scannen.
das ding wird vermutlich allemal sicherer, als die jetzige pdf-schubserei.
zudem war hier noch nie ein (komplexes) konzept bis zu ende durchgedacht. die ersten waren immer schon betatester.. also nichts neues.
Das Thema gibt es nicht nur in Deutschland.
Das Format der XRechnung entspricht nahezu exakt dem französischen Format Factur-X.
Und in Frankreich müssen ab 1.7.24, also in etwas mehr als 1 Woche verpflichtend im B2B-Bereich alle Unternehmen das Format annehmen können und Großunternehmen auch ausstellen können.
Ab 1.1.25 müssen es alle mittleren Unternehmen auch ausstellen können und ab 1.1.26 auch Kleinunternehmen.
Und z.B. in Italien gibt es E-Rechnungen schon seit 2007, afaik seit 2018 ist die verpflichtend im B2B-Bereich.
Das Thema kommt EU-weit und wird von der EU auch vorgeschrieben.
Das Wachstumschancengesetz 2024 ist nur die nationale Umsetzung der EU-Verordnungen in geltenes Recht.
Was die Kritik am Format angeht:
Ja, die ist berechtigt.
Und böswillige Akteure werden das nutzen, um Fakerechnungen mit bösartigem Inhalt zu versenden. Die kümmern sich natürlich nicht z.B. um das Verbot, JavaScript einzubinden.
Da sind dann Systeme gefragt, die solche Sachen abfangen, noch bevor ein Anwender die Fakerechnung zu Gesicht bekommt und öffnen kann.
Beispielsweise Whitelisting im Mailserver, der Mails nur von Mailadressen in der Whitelist annimmt.
Macht z.B. ein großer Kunde von uns jetzt schon bei einigen Mailadressen so.
Da kommt dann, wenn man nicht auf der Whitelist steht, eine Rückmail, das die Mail abgewiesen wurde, weil man nicht auf der Whitelist steht. Und dann der Hinweis, das man sich an XY wenden soll, um auf die Whitelist gesetzt zu werden.
ZUGFeRD / FakturX sind 100% identisch. X-Rechnung wird von der KoSIT entwickelt und ist abweichend.
https://www.ferd-net.de/standards/was-ist-factur-x/index.html
Website funktioniert im ordentlich abgesicherten Browser mit deaktiviertem JavaScript nicht!
So viel zum Thema.
Schau mal in den Quelltext!
Da ist noch eine Browserweiche für den IE7, IE8 und IE9 mit drin!
Das das noch in 2024 zu finden ist!
Ich kann nur berichten, dass die elektronische Rechnung als XML über das "Sistema di interscambio" ("Austauschsystem") in Italien sehr gut funktioniert. Seitdem hatte ich auch tatsächlich nie mehr eine länger offene Kundenforderung, da das ganze System mit digitalen Signaturen und qualifizierten Zustellbestätigungen für die XML-Dateien arbeitet.
Die Verbuchung der Ein- und Ausgangsrechnungen ist praktisch ein Selbstläufer. Trotz ansonsten gesteigerter Bürokratie (auch) in Italien konnten wir damit mehr als zwei Drittel der für die Fakturierung und Verbuchung nötigen Zeit einsparen.
Mehr Infos hier:
https://www.agid.gov.it/en/platforms/electronic-invoicing
Hier geht es wohl "nur" um den Datenaustausch von elektronischen Rechnungen mit der öffentlichen Verwaltung. In Deutschland soll ab 2025 wirklich jeder, der sich beruflich engagiert, mit der Digitalisierung auseinandersetzen müssen. Darunter sind auch Menschen, die kaum ein Smartphone bedienen können, aber sich in ihrem Beruf durchaus gut auskennen.
Dazu kommt ab einem gewissen Alter die 10-Jahre-Aufbewahrungspflicht aller Buchhaltungsdaten im Ruhestand mit allen Anforderungen an die IT-Sicherheit, Updates … Im Kleinen ist immer noch das Papier organisatorisch und umwelttechnisch im Vorteil! (Das jetzt nicht nur in Bezug auf den funktionierenden Teilbereich bei der digitalen Rechnungsabwicklung!)
Falls irgendwer glaubt, das die Elektronische Rechnung den Handel und die Produktion erleichtern soll, sollte Mal gucken auf welchem Stern er lebt…
Der Hintergrund ist natürlich, das die Finanzämter bei Betriebsprüfungen schneller werden wollen. Ein Knopf Druck, und das Mehrwertsteuer-Karussell ist entlarvt.
Auch könnten so irgendwann ständige Steuerprüfungen erfolgen, vollautomatisch, im Hintergrund.
So wie es ja schon bei Rentnern geschieht,wo das Bundesamt für Steuern sämtliche Konten und deren Bewegung und die Höhe der Rentenzahlungen kennt, sammelt und an das zuständige FA weiterleitet, das dann nach 5 Jahren den Bürger mit saftigen Strafen anschreibt.
Aber cybercyber ist die größte Gefahr.
Eine gute Digitalisierung geht einfacher + sicherer, wie ich im Rahmen der intensiven Beschäftigung mit "plain text" festgestellt habe und mit einer Website am Redaktionssystem realisiere. Nur müssen wir uns wieder von den übermächtigen IT-Konzernen, die uns mit ihren Produkten eingefangen haben, lösen können.
Wem 'plain text' alleine nicht reicht, kann sich z. B. mit Markdown (https://daringfireball.net/projects/markdown/), Org-Mode (https://orgmode.org/) etc. beschäftigen.
Mit diesem Hintergrundwissen können einfache Textdateien geschrieben werden, die auf Computern mit und ohne grafischer Oberfläche einfach direkt lesbar sind, ausgedruckt und digital verarbeitet werden können.
Dem entgegen hat es das Bundesfinanzministerium seit Februar 2024 nicht geschafft, mir auf eine E-Mail-Anfrage zur Umsetzung der Vorgaben aus dem "Wachstumschancengesetz" zu antworten. Vielleicht scheitert dies am einfachen Textformat der E-Mail ohne Anlagen?