Versuche E-Rechnung zu verschicken, doch die Rechnung kommt als pdf

[#1]

Hallo zusammen,

ich versuche mich ins Thema E-Rechnung einzuarbeiten mit AW next und stosse auf folgendes Problem:

Ich verschicke eine vermeintliche E-Rechnungen, doch sie kommen beim Kunden im Anhang als pdf an.

In AW next habe ich im Reiter "Kunde" die E-Rechnung angeklickt und auch unter >Einstellungen >E-Rechnung ausgewählt. Trotzdem kommt die Rechnung als PDF an.

Was mache ich verkehrt?

[#2]

ich denke mal nix, wenn das PDF im Acrobat Reader geöffnet ist, dann sieht man die dazugehörige xml Datei so:

[#3]

Sehr gut! Danke.

Wäre das nicht einfacher, die SML-Datei befindet sich direkt im E-Mail im Anhang?

Ich schätze, einige meiner Kunden geht es auch so, dass sie nicht wissen wo die Datei zu finden ist ...

[#4]

Einfacher ja, richtig nein, da dies nicht dem ZUGFeRD-Standard entspräche. Wir haben hier ein Hybrides Dateiformat welches die XML-Rechnung in einem PDF Container mit Sichtkomponente verpackt. Alternative wäre eine X-Rechnung welche nur aus einer XML-Datei besteht und ein Programm benötigt um lesbar gemacht zu werden.

Wieso sollte man wissen wo der maschinenlesbare Teil der Rechnung zu finden ist? Das menschliche Auge kann damit sowieso nicht viel anfangen. Einfach mal den XML-Anhang öffnen, dann verstehst du was ich meine.

[#5]

Ok, verstehe. Danke für die Ausführung.

Ich hatte mir es so vorgestellt, dass eine PDF Datei zu Ansicht und ein xml-Datei für die Maschinenlesbarkeit zur Verfügung stehen wird. Also zwei Dateien. Doch dann könnten vermutlich in der einen andere Inhalte stehen, als in der anderen und das wäre wiederum eine Einladung für Lug und Trug ...

[#6]

---

@Renate-2025  schrieb:

Doch dann könnten vermutlich in der einen andere Inhalte stehen, als in der anderen und das wäre wiederum eine Einladung für Lug und Trug ...

---

Ironischerweise kann auch bei ZUGFeRD etwas anderes in der XML stehen, als in der PDF-Sichtkomponente. Die Einladung für Lug und Trug ist also trotzdem gegeben. Daher empfiehlt es sich immer anhand der XML-Daten zu buchen, da diese rechtlich Vorrang haben.

[#7]

---

@Renate-2025  schrieb:

Doch dann könnten vermutlich in der einen andere Inhalte stehen, als in der anderen und das wäre wiederum eine Einladung für Lug und Trug ...

---

Schaut man sich dafür beim Verbuchen nicht den Beleg an?

Dann sollte man doch sehen, dass bei der Belegverbuchung aus der xml-Datei z.B. 1.000,00 Euro übernommen wurden aber der Sichtbeleg nur 100,00 Euro.

[#8]

---

@m_brunzendorf  schrieb:

Schaut man sich dafür beim Verbuchen nicht den Beleg an?

Dann sollte man doch sehen, dass bei der Belegverbuchung aus der xml-Datei z.B. 1.000,00 Euro übernommen wurden aber der Sichtbeleg nur 100,00 Euro.

---

Ja, würden die Werte konsequent aus der XML Datei übernommen werden, könnte man die Buchungszeile einfach mit der Sichtkomponente abgleichen. Leider ist das aktuell nicht der Fall. Da Werte aus der Sichtkomponente übernommen werden, muss also ein Abgleich mit der XML Visualisierung vorgenommen werden um Gewissheit zu haben.

Ist das absolut unsinnig? Ja.

Kostet uns das wertvolle Zeit, die wir nicht haben? Ja.

Hat sich die Datev dafür Arbeit gespart? Ja.

Das ist eben das Ergebnis, wenn man in letzter Minute irgendwas zusammen programmieren lässt, von Leuten die absolut keine Ahnung von den praktischen Anforderungen an die Software haben. Ist leider keine Ausnahme.

[#9]

---

@Renate-2025  schrieb:

Ok, verstehe. Danke für die Ausführung.

Ich hatte mir es so vorgestellt, dass eine PDF Datei zu Ansicht und ein xml-Datei für die Maschinenlesbarkeit zur Verfügung stehen wird. Also zwei Dateien. Doch dann könnten vermutlich in der einen andere Inhalte stehen, als in der anderen und das wäre wiederum eine Einladung für Lug und Trug ...

---

Wir haben es ursprünglich in unserem ERP so gelöst, dass sowohl Zugferd (pdf+xml) sowie X-Rechnung (xml) parallel verschickt wurden, sodass der Kunde sein Lieblingsformat wählen kann.

Hat jetzt aber bereits zu Reklamationen geführt, da die (teilweise automatische) Rechnungsverarbeitung bei großen Kunden das dann als zwei Rechnungen erkannt hat, daher verschicken wir jetzt nur noch Zugferd, weil es im Alltag für beide Seiten einfacher zu handeln ist und ich bin froh, dass die DATEV Lösungen auch auf Zugferd setzen.

[#10]

---

@unklarer_Posten  schrieb:

Wir haben es ursprünglich in unserem ERP so gelöst, dass sowohl Zugferd (pdf+xml) sowie X-Rechnung (xml) parallel verschickt wurden, sodass der Kunde sein Lieblingsformat wählen kann.

---

Ist aus meiner Sicht auch nicht richtig so, da dadurch zwei Rechnungen für eine Leistung entstehen und im Zweifelsfall doppelt Umsatzsteuer geschuldet werden könnte. Wenn die Gegenseite fälschlicherweise beide Rechnungen verarbeitet und doppelt Vorsteuer zieht, könnte das Finanzamt Sie für den Schaden haftbar machen. (Keine Steuerberatung, ich knabber Wachsmalstifte)