Erster Fall von falscher E-Rechnung

[#1]

Hallo zusammen. Ich habe am Freitag die erste Reklamation aufgrund einer falschen E-Rechnung erhalten, der erst auffiel, als die Zahlung schon gelaufen war. Das ist sehr ärgerlich und hängt auch mit der DATEV Belegfreigabe zusammen.

Der Lieferant hat eine ZUGFeRD Rechnung gesendet, welche in der Belegfreigabe mit der visuellen PDF freigegeben wurde. Hier wurde von einem Rechnungsstorno gesprochen die Beträge waren negativ. Der Sachbearbeiter hat die Rechnung freigegeben.

In DATEV Rechnungswesen habe ich den Beleg gebucht, hier wird zunächst Seitenweise strukturierte Daten angezeigt und die Erfassungsmaske wird vorbelegt. Da für mich rechtlich gesehen der Datensatz Vorrang hat und hier als Belegtyp "Rechnung" stand und die Beträge positiv waren fiel der Fehler nicht auf, bei dem Lieferanten beziehen wir Ware, 30-40 Positionen die man nicht mehr großartig durchgeht. Also wurde der Beleg gebucht.

Die Zahlung erfolgt über den Zahlungsvorschlag in Datev Rechnungswesen (nicht Unternehmen online), so dass hier das "Rechnugnsstorno" getarnt als Rechnung zur Zahlung vorgeschlagen wurde.

Natürlich kann man rein theoretisch runterscrollen was bei 20-30 Positionen allerdings sehr unbequem und ehrlich gesagt, hat es mich bisher auch nicht interessiert, da der Vorrang die sturkturierten Daten haben (es könnte ja auch einfach eine XRechnung sein, OHNE dass es ein PDF zum anschauen gibt.

Es ist ziemlich schlecht gelöst, dass in der Belegfreigabe die Kollegen ausschließlich die PDF Anzeige haben, während der Buchhalter in der Buchungserfassung die strukturierten Daten vorgesetzt bekommt. Hier sollte DATEV dringend etwas ändern. Ja, es ist für den Freigeber etwas neues, wenn da nicht mehr das Logo der Firma erscheint, bei der er eingekauft hat, sondern immer das selbe Formular für die Aufbereitung der XML-Daten, aber die Gesetzeslage hat sich zugunsten der E-Rechnung geändert und da müssen eben alle einmal durch.

Das ist sehr ärgerlich, wenn man 2000 Euro überweist, anstatt diese in Abzug zu bringen, weil hier Buchhaltung und Belegfreigeber unterschiedliche Informationen erhalten.

Gruß

Lucien Berger

[#2]

Sind die XML-Daten/Informationen grundsätzlich falsch oder wurden die nur falsch übernommen?

[#3]

Ich habe mir die empfangene e-Mail vom Lieferanten angeschaut.

Die XML Datei enthält die 380 als TypeCode für denRechnungstyp, was eine Rechnung ist, die Rechnungswerte sind alle postiv (in der PDF negativ)

Damit wird die Rechnung nach den Regeln als Rechnung interpretiert. 

Man kann die 380 mit negativen Rechnungswerten nutzen, dann wird das laut Dokumentation von ZUGFeRD als  Rechnungskorrektur interpretiert. Alternativ kann man auch den TypeCode 384 verwenden für eine Rechnungskorrektur. Der Fehler liegt also eindutig in der Datei, an dieser spielt von uns keiner rum (und sollte ja auch nicht möglich sein)

Was mich an dieser Stelle ärgert ist, dass der Freigeber die PDF sieht, und ich die strukturierten Daten. Hätte der Freigeber die strukturierten Daten vor sich, dann würde er die Rechnung nicht freigeben, weil er dann eine Rechnung mit positiven Werten vor sich hätte und er erwartet entweder eine Rechnung mit negativen Werten oder den Typ Rechnungskorrektur.

[#4 · Accepted solution]

Die Anzeige hatten Sie ja bereits 01.2025 vorgeschlagen.

Lt. DATEV-News soll es ja auch entsprechend kommen/umgesetzt werden, ist ja schon aufgeführt:

- Datenvisualisierung der strukturierten Daten aus der XML-Datei einer E-Rechnung

- Hinweis auf invalide E-Rechnung anzeigen

bspw.: https://apps.datev.de/help-center/documents/1026682

Meine Rückfrage bezog sich darauf, ob ein Bug vorhanden ist (hätte ja auch sein können) oder "nur" der Freigabe-Prozess (in dem Fall die Darstellung) umgestellt werden muss.

Evtl. war auch nur der Code BT-_ falsch und wäre als 380 negativ gar nicht umsetzbar.

---

Wie sind Gutschriften und Rechnungs­korrekturen anzugeben?

Im Bereich der Rechnungserstellung kann es notwendig sein, unterschiedliche Formen einer Gutschrift beziehungsweise einer Rechnungskorrektur auszuweisen. Die elektronische Rechnung erleichtert die Interpretation der enthaltenen Rechnungsdaten bereits durch Auswertung des Rechnungstyps im Feld BT-3:

• Rechnungs­berichtigung: Eine bereits übermittelte Rechnung muss korrigiert oder storniert werden. Hierzu wird eine Gutschrift ausgesprochen.
  Code in BT-3: „384“ (corrected invoice)
  Anmerkung: Eine Referenz auf die zu korrigierende Rechnungs­grundlage ist anzugeben (PRECEDING INVOICE REFERENCE, BG-3).

• Kauf­männische Gutschrift: Dem Rechnungs­steller wird unabhängig von vorher­gehenden Rechnungen eine Gutschrift oder ein Gutschein zugeschrieben. Dies kann z.B. der Fall sein, wenn ein bestimmter Kunde in einem bestimmten Zeitraum ein gewisses Umsatz­volumen erzielt hat, was nun zur Erstattung oder Gutschrift führt.
  Code in BT-3: „381“ (credit note)
  Anmerkung: In diesem Fall sollte der Rechnungs­betrag kein zusätzliches negatives Vorzeichen tragen.

• Vom Leistungs­empfänger selbst erstellte Gutschrift: Der Leistungs­empfänger erstellt eine Gutschrift gemäß § 14 Abs. 2 Satz 2 Umsatzsteuer­gesetz, bei der es sich um die Abrechnung einer Lieferung oder Leistung handelt.
  Code in BT-3: „389“ (self billed invoice)

---

Quelle: https://www.e-rechnung-bund.de/faq/e-rechnung/

Wie der Lieferant nun das Chaos beseitigen will, wird bestimmt auch lustig, denn der bisherige Beleg müsste ja auch ersetzt werden und wie es dort überhaupt zu so einem Fehler kommen kann?

Denn grundsätzlich haben Sie ja Recht ...

Rechtliche Relevanz: Im ZUGFeRD-Format ist das XML-Dokument rechtlich bindend, da es die strukturierten Daten enthält, die den Anforderungen an elektronische Rechnungen gemäß der EU-Richtlinie 2014/55/EU und der Norm EN 16931 entsprechen.

allgemeine (Rand-) Bemerkung noch - weil dies wird oft auch nicht berücksichtigt bei "eigenem E-Mail-Account":

B2C-Bereich
E-Mail Transportverschlüsselung unzureichend, Ende-zu-Ende-Verschlüsselung erforderlich
OLG Schleswig, Urt. v. 18.12.2024 - Az.: 12 U 9/24
B2B-Bereich
OLG Karlsruhe, Urt. v. 27.07.2023 - Az.: 19 U 83/22

[#5]

---

@march  schrieb:

allgemeine (Rand-) Bemerkung noch - weil dies wird oft auch nicht berücksichtigt bei "eigenem E-Mail-Account":

B2C-Bereich
E-Mail Transportverschlüsselung unzureichend, Ende-zu-Ende-Verschlüsselung erforderlich
OLG Schleswig, Urt. v. 18.12.2024 - Az.: 12 U 9/24
B2B-Bereich
OLG Karlsruhe, Urt. v. 27.07.2023 - Az.: 19 U 83/22

---

Auch DATEV verstößt dagegen beim Versand aller E-Rechnungen über das eigene E-Rechnungsportal:
https://www.datev-community.de/t5/IT-Club/IT-Club-Fr%C3%BChjahresrunde-2024/m-p/410408#M1910

[#6]

@march 

Oh, danke für den Hinweis, je schneller DATEV hier liefert um so besser 😁

Eine Anmerkung habe ich übrigens noch dazu ob eine Rechnung (BT-3 = 380) negative Rechnungssummen haben darf.

Laut Factur-X Version 1.07.2 (ZUGFeRD v. 2.3.2) vom 15. November 2024 ist es möglich das der Betrag einer Rechnung (380) negativ ist und damit ein Rechnungsstorno ist.

---

7.1.6 Umgang mit Gutschriften
Es gibt zwei Möglichkeiten, mit Gutschriften umzugehen:

▪ Die Negativrechnung:
Hierbei handelt es sich um eine Rechnung, deren Gesamtbetrag einschließlich
Steuern negativ ist, weil entweder die Rechnung negative Positionen enthält, deren Summe im
absoluten Wert größer ist als die Summe der positiven Zeilen (insbesondere Schlussrechnungen nach
einer Reihe von Rechnungen für Zahlungen im Voraus oder nach früheren Rechnungen mit
Voranschlägen wie etwa bei Energierechnungen).

Oder sie enthält nur Negativpositionen und storniert die Rechnung allgemein. Es handelt sich also um eine Gutschrift, die sich auf die Rechnung bzw. den Zeitraum beziehen muss, auf den sie verweist. Auf Positionsebene ist der Stückpreis positiv und die Mengen negativ. Die Berechnungsregeln bleiben gleich und führen zu negativen Positionen und entsprechend zu negativen Summen (einschließlich der Mehrwertsteueraufschlüsselung auf die Grundlagen ohne Steuern und die Steuerbeträge).

In diesem Fall werden auch die Beträge der Zu und Abschläge umgekehrt (sind also negativ). Die Arten von Dokumenten (BT-3-Daten), die somit Gegenstand dieses Prozesses sein können, sind diejenigen, die Rechnungen entsprechen (also keine Gutschriften), nämlich 380 (Handelsrechnung), 384 (Korrekturrechnung) und 389 (Gutschriften), 386 (Vorauszahlungsrechnung) sowie 751 (Rechnungsinformationen für die Buchhaltung)

Schöner ist natürlich, wenn der Betrag negativ wird, dass der Code für BT-3 dann auch entsrpechend sich ändert. Es ist dann Eindeutig für den Anwender.

[#7]

hm hier teile ich die Meinung nicht ganz.

(habe die Rechnung/Vorgang aber auch nicht vor mir liegen, um dies abschließend zu bewerten)

Wie dem von Ihnen o.g. kopierten Text ja zu entnehmen ist:

- Vorauszahlung(en)/Abschläge die zum Minus führen - Rechnung grundsätzlich im Plus

- negative Artikel-Anzahl müsste explizit ausgewiesen sein (nicht Betrag) 

Des Weiteren steht direkt im weiteren Verlauf des Textes:

In Frankreich kodifiziert man üblicherweise eine Gutschrift, durch die eine Rechnung storniert wird, durch
den Typ "Gutschrift". Auf diese Weise stimmen alle Daten der Gutschrift mit denen der stornierten Rechnung
überein. Nur die Rechnungsnummer der Gutschrift (die der wie bei Rechnungen chronologisch sein muss),
das Datum und die Rechnungsnummer, die durch die Gutschrift storniert wird, werden geändert. Sie müssen
ausgefüllt werden (in der PDF-Darstellung und vom Profil BASIC WL in BT-25-Daten).

Die Darstellung „Negative Rechnung“ wird verwendet, wenn sie sich aus einer Rechnungskalkulation ergibt,
die aufgrund von Storno auf vorangegangene Rechnungen (Voranschläge, Vorauszahlungen, Leergut-,
Palettenrückgabe etc.) zu diesem Ergebnis führt.

Dies ist jedenfalls die von Chorus Pro verwendete Praxis (Gutschriften, die Rechnungen des Typs 381
stornieren und Annahme negativer Rechnungen, wenn sie aus einer Abrechnungskalkulation aufgrund von
Stornierungen resultieren).

Lediglich nach den o.g. Ausführungen kommt der Einwand:

Es gibt jedoch Länder in Europa, die ausschließlich Negativrechnungen verwenden (auch bei Gutschriften,
die lediglich eine Rechnung stornieren)

Die dort gemachten Ausführungen sind also allgemeiner Natur und muss evtl. noch für Deutschland (Länderleitlinie?)  bzw. von der Finanzverwaltung/DATEV o.ä. konkretisiert (Fallbeispiel ähnlich 7.1.7-7.1.11) werden.

Zurück zu #1 der Lieferant hat einen Fehler gemacht, der diesen dringend analysieren sollte.