Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[stalkingwolf]

Zitat von sh17:

Also eine ZUGFeRDExtendedVersion_232 Version kann man mit dem XRechnung Validator nicht testen.

Das hatte bis Ende 2024 einwandfrei funktioniert z.b mit https://sbw.landbw.de/serviceportal ( ist heute Morgen in Wartung ).
angeblich hab es eine Änderung am 1.1.2025 gegeben bezüglich Specified Document.

https://portal3.gefeg.com/invoice/validation lief auch einwandfrei durch. Auch das bringt nun einen Fehler

Evtl bin ich auch aktuell mächtig auf dem Holzweg.

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

[sh17]

Zitat von stalkingwolf:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Man kann alle Formate in die PDF packen, man muss es nur richtig tun.

[AuronTLG]

Zitat:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Das hängt von den geschäftlichen Umständen ab.

Ich persönlich benutze das ZUGFeRD-Profil XRECHNUNG. Dieses besteht darin, dass man eine XRechnung (auf Grundlage des XRechnungsformates) in die PDF steckt.
Hintergrund ist, dass meine Kunden häufig ERechnungen an öffentliche Stellen schicken, die nur reine XRechnungen und keine ZUGFeRDs akzeptieren während die Geschäfts- oder Privatkunden ihre normalen PDFs haben wollen. Mit dem ZUGFeRD-Profil XRECHNUNG erzeugt man in allen Fällen gültige XRechnungen, die man entweder in eine PDF stecken kann, für B2B oder B2C, oder auch nicht, wie eben im Falle einer öffentlichen Stelle als Empfänger. Man muss also nur ein Format pflegen.

Edit: Ups, glaube ich habe das missverstanden. Es geht nicht darum, ein ZUGFeRD-Erzeugung bereitzustellen, sondern nur darum, selbst ZUGFeRDs an Kunden zu verschicken, oder?

[stalkingwolf]

Zitat von AuronTLG:

Zitat:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Das hängt von den geschäftlichen Umständen ab.

Ich persönlich benutze das ZUGFeRD-Profil XRECHNUNG. Dieses besteht darin, dass man eine XRechnung (auf Grundlage des XRechnungsformates) in die PDF steckt.
Hintergrund ist, dass meine Kunden häufig ERechnungen an öffentliche Stellen schicken, die nur reine XRechnungen und keine ZUGFeRDs akzeptieren während die Geschäfts- oder Privatkunden ihre normalen PDFs haben wollen. Mit dem ZUGFeRD-Profil XRECHNUNG erzeugt man in allen Fällen gültige XRechnungen, die man entweder in eine PDF stecken kann, für B2B oder B2C, oder auch nicht, wie eben im Falle einer öffentlichen Stelle als Empfänger. Man muss also nur ein Format pflegen.

Edit: Ups, glaube ich habe das missverstanden. Es geht nicht darum, ein ZUGFeRD-Erzeugung bereitzustellen, sondern nur darum, selbst ZUGFeRDs an Kunden zu verschicken, oder?

Hallo. Danke für die Info. Wir haben das ganze umgestellt und damit hat es direkt funktioniert.
Die Datei werden ohne Warnings akzeptiert.

[Rollo62]

Ist vielleicht auch interessant, zum Thema Kleinunternehmer
https://www.onlinehaendler-news.de/r...men-verwirrung
http://www.dstv.de/stellungnahmen-po...vom-18.03.2025
https://www.bundesfinanzministerium....cationFile&v=3

[sqlman]

Hallo zusammen,

auch wir sind, wie viele andere, gerade in der Implementierungvon ZUGFerD, XRechnung usw.

Erst einmal vorweg vielen Dank an die vorherigen Verfasser, das ihr euer Vorgehen hier darstellt. Ich bleibe mit meiner Frage daher mal hier im Thread (wenn falsch, bitte Hinweis), da es - so denke ich - hier ganz gut reinpasst (Zukunft mit XRechnung/ZugPferd).

Unser aktuelles Vorgehen wird sein, die aktuelle PDF-Rechnungserzeugung mit dem XML-Rechnungsanhang zu versehen. Für unsere Kunden scheint das momentan der einfachste Weg.

Folgende Dinge, liegen aber bei uns noch im Nebel verborgen. Zumindest hatte ich bei diesen Frage Probleme, das hier im Thread herauszulesen:

Validierung: aktuell gehe ich davon aus das diese nur während der Implementierung beim Test nötig ist? Manchmal klingt es, als ob jede Rechnung nach Erzeugung validiert werden sollte? Das verstehe ich da dann doch falsch, oder?

Ausgehend davon, das nicht jede Rechnung validiert werden muss: Was passiert eigentlich, wenn die XML dann mal "kaputt" ist? Storno der Rechnung und neue Rechnung unter neuer Rechnungsnummer mit korrigierter Programmversion erzeugen? Oder wird nur die Rechnung wie früher als Duplikat gedruckt und der XML-Teil korrigiert?
Geht ja auch nicht, weil ja nach dem Druck/erzeugen der Rechnung diese unveränderbar archiviert werden sollte. Im obigen Beispiel habe ich dann eine fehlerhafte ZugFerd-Rechnung im Archiv. Was erst einmal seltsam ist, aber (Annahme) aus Prüfersicht richtig, weil die ja ganz normal storniert und neu erzeugt würde?

Wie oft sind solche Fälle (Rechnung ist im XML-Format fehlerhaft und wirft beim Kunden Probleme auf) in euren Implementierungen vorgekommen und wie seid ihr damit umgegangen?

Kurze Info: Unser Softwareprojekt ist eine Software für Heizkostenabrechner/Energielieferanten/Stadtwerken. Von Sachbearbeitern werden hunderte Rechnungen erzeugt, die meisten davon automatisiert.

Danke im voraus
Gruß
Ralf

[BlueStarHH]

Jede Rechnung sollte validiert werden. Durch andere Inhalte könnte die Rechnung ja ungültig werden.