ZUGFeRD - einheitliches Format für elektronische Rechnungen.

https://www.haufe.de/steuern/g…05558.html

ZUGFeRD 2.2 / Factur-X 1.0.06 vom 01.03.2022- Vereinheitlichte Spezifikation https://www.ferd-net.de/standa…d-2.2.html
Order-X vom 13.04.2021 https://www.ferd-net.de/standa…x-1.0.html

Bundesrat stimmt zu: E-Rechnungspflicht für Firmen kommt ab 2025​
Das umstrittene Wachstumschancengesetz, das auch die E-Rechnungspflicht für Firmen ab 2025 vorsieht, hat nun auch im Bundesrat grünes Licht bekommen.
https://www.heise.de/news/Bund…63131.html

https://www.heise.de/news/Bund…65246.html

konform zur Europäischen Norm EN16931, müssen die Eingangsrechnungen ja validiert/geprüft werden und somit div. Mindeststandards/Daten erfüllen.

Ua. werden von den aktuellen Tools folgende Eingabe-Felder idR. angezeigt: USt-Id-Nr. und Steuer-Nr.
In Kürze wird sich zudem hier bestimmt noch die Wirtschafts-Identifikationsnummer (W-IdNr.) hinzufügen und sogar evtl. EBID-Nummer.
Quelle: https://www.destatis.de/Verwal…nhalt.html


was man jedoch festhalten kann, dass wahrscheinlich die Banking-Programme noch weitere Felder (wie o.e. div. ID-Felder) schaffen müssen, um die Daten für die nachgelagerte Verarbeitung zu liefern.

Hinzu kommt, dass 2028-2030 dies dann grundsätzlich gefordert wird, da ja dann die Rechnungen zum automatischen Abgleich ans FA übersandt werden müssen.

Dann war es aber nach meinem Wissen nicht ZUGFeRD sondern XRechnung. ZUGFeRD ist PDF mit darin embedded XML. Man braucht also keine separate XML-Datei. Da aber die im PDF angezeigten Daten nicht mit dem embedded XML verknüpft sind, ergibt sich hier aus meiner Sicht ein noch höheres Sicherheitsrisiko. Denn man importiert arglos ein solches PDF. Das Tool liest das darin enthaltene XML aus, welches aber u.U. einen völlig anderen Betrag oder gar eine andere IBAN enthält.

Szenario:
Firma kriegt Rechnung als PDF. Chef/Prokurist öffnet das PDF im regulären PDF-Viewer. Empfänger und Betrag sind korrekt.
Er leitet die Rechnung per Mail an die Buchhaltung zur Überweisung weiter. Die wissen, dass PDFs neuerdings direkt in der Zahlungssoftware importiert werden können (den technischen Hintergrund kennen die natürlich nicht). Das embedded XML enthält aber völlig andere Daten. Die im Zahlungsprogramm angezeigten Daten werden aber vor der Ausführung nicht mit dem PDF verglichen - denn die Prüfung hat der Chef/Prokurist ja bereits getan. Schwupps. Hohe Summe an Betrüger überwiesen.

Ich finde dieses Szenario ziemlich gefährlich und verstehe nicht, warum das in den Medien bisher noch nirgends thematisiert wurde.

Ah ok. Dann hatte ich dich falsch verstanden.
In dem Zusammenhang: In Hibiscus ist es in der Tat so, dass ein PDF immer als Überweisung importiert wird. Eine Gutschrift ist damit gar nicht möglich. Das müsste dann ja als Lastschrift importiert werden. Wobei hier ja eher unwahrscheinlich ist, dass man mit dem Geschäftspartner ein Mandat hat und eher der Geschäftspartner zurücküberweisen muss.

Es wäre in der Tat sinnvoll, einen Warnhinweis anzuzeigen, wenn es sich bei der Rechnung um eine Gutschrift handelt. Weisst du, wie das in dem XML dargestellt war? Also woran genau man erkennt, dass es eine Gutschrift ist?

so auch die DATEV hat die "Änderung" - also statt PDF = .xml-Datenvisualisierung freigeschalten:
bspw.: 16.05.2025 - Neuerung in DATEV Unternehmen online: Datenvisualisierung

Informations-Video inkl. div. Erläuterungen: Datenvisualisierung von E-Rechnungen in den DATEV-Programmen