ZUGFeRD: XRechnung: Rundungsdifferenzen BT-114 horizontal/vertikal

[Rollo62]

Hallo zusammen,

sorry, sorry, sorry, ich muss dieses unschöne Thema nochmal auf den Tisch bringen.
Hier wurde das Thema schonmal behandelt
https://www.delphipraxis.net/192985-...erstellen.html

Ich hänge gerade bei der Überlegung USt-Berechnung: Horizontale oder Vertikale Methode, beides sollte ja OK sein.
Hier ein passendes Beispiel:
https://github.com/ZUGFeRD/mustangproject/issues/144

Im großen und Ganzen denke ich aber, dass nur die horizontale Methode wirklich für alle Fälle korrekt funktioniert.

Warum? Ich meine nur die horizontale Methode bildet verschiedene USt-Sätze in einer Rechnung korrekt ab.

Mit der vertikalen Methode ist realistisch nur ein USt-Satz abzubilden, wenn man sich nicht irgendie logisch verbiegen will.


Ich könnte zwar mit dem Durchschnitt für Vertikal (in blau) rechnen, aber nur, wenn alle USt Raten auch gleich sind.
Gibt es verschiedene USt Positionen, wie könnte man das Vertikal berechen, mit dem Durchschnitt wohl eher nicht?
Bisher habe ich nur die horizontale Methode in Betracht gezogen, trotzdem würde mich interessieren wo Vertikal dann Sinn macht.

Das mal vorab, weshalb ich denke die horizontale Methode ist aus meiner Sicht die natürlichere Methode, welche weniger Probleme verursachen kann und deswegen generell zu bevorzugen sein sollte.
Wenn ich da falsch liege und horizontal / vertikal grundsätzlich immer exakt austauschbar wären, oder es da andere Meinungen zu gibt, bitte eine Erklärung wie das gehen könnte.

Rundungsdifferenzen generell:
Es gibt die Hinweise zu Rundungsdifferenzen generell, welche in anderen Ländern bis zu 5 Ct akzeptiert werden.
Z. B. hier
https://github.com/ZUGFeRD/mustangproject/issues/239

Zitat:

Der Technical Appendix zu ZUGFeRD 2.1.1 beschreibt das rounding amount auch als "In einigen europäischen Ländern werden die ermittelten Rechnungsendbeträge z.B. auf volle 5 Cent gerundet. Die sich dadurch ergebende Differenz kann im Element RoundingAmount aus den Belegsummen abgebildet werden.

Gibt es da auch so eine "Obergrenze" in Deutschland?
Ich gehe da von akzeptierten Differenzen von 1 Ct bis womöglich max. 2 Ct aus, aber nur gefühlt.

Rundungsdifferenzen BT-114:
In der XRechnung gibt es dazu das spezielle, optionale Feld BT-114.
Wie sollte das genutzt werden, ich finde dazu keine wirkliche Anwendungsregel und weil es optional zu sein scheint, kann man es wohl einfach weglassen.
Treten Rundungsdifferenzen auf ( quasi immer ), ab wann MUSS man BT-114 einsetzen?

Speziell in ZUGFeRD oder bisherigen PDF Rechnungen ist mir ein solcher Posten noch nie aufgefallen.
Wenn das irgendwo verlangt wird, würde es ja heißen, dass dieses BT-114 auch auf der PDF-Rechnung erscheinen muss, oder nicht?

Wenn es nicht verlangt wird, dann kann es nicht einfach auf "nicht vorhanden" gesetzt werden, das wäre genauso falsch wie "0.0",
denn es gibt ja IMMER Rundungsdifferenzen.
Was macht man mit BT-114 in der Praxis, komplett ignorieren?

[sh17]

Also ich wäre auch an einer Lösung interessiert. Die Sache mit der Rundungsdifferenz ist meiner Meinung nach im Falle einer hybriden ZUGFeRD-Rechnung nicht der richtige Weg, weil sich dann XML und PDF unterscheiden würden.

Auch die Diskussion hier
https://github.com/ZUGFeRD/mustangproject/issues/641

Mich würde ja mal ein offizielles XML-Beispiel interessieren.

[Rollo62]

Meine Lösung wäre ja, alle genutzten BT-Felder auch entsprechened auf dem PDF anzuzeigen,
damit mache ich gerade ein paar Versuche.

Es ist aber schon so, dass dann z.B. Summe der Positionen (BT-106), Summe der Nachlässe (BT-107), Summe der Zuschläge (BT-108), Payed amout (BT-112), usw. auflisten müsste, auch wenn diese 0.00 sind.
Denn die Formeln für Rechnungsbetrag BT-115 usw. beinhalten ja alle diese Felder auch.

Das man alle diese Zusatzfelder mit ins PDF bringt wird etwas unübersichtlicher, aber scheint trotzdem noch ganz gut zu passen.

Ich habe auch die Meinung, dass das PDF solche optionalen Daten durchaus mit sehr kleiner 6Pt Schrift anzeigen kann,
denn das PDF ist ja vektorbasiert elektronisch und ist gar nicht mehr für Print vorgesehen.
Deshalb häte ich da mit kleineren Schriften erstmal kein Problem, denn das Dokument ist ja immer elektronisch lesbar.
Oder gibt es da womöglich eine Mindestschriftgröße?

Edit:
Hier mal als Beispiel, was ich meine:

Zitat:

BR-CO-16
Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).

Das heisst ja auch, dass nicht nur BT-115 auf die PDF gehören, sondern alle anderen auch, selbst wenn sie 0.00 sind.
Sollte sich PDF und XML unterscheiden wird das als zwei Rechnungen angesehen, also im Umkehrschluss:
Alle relevanten BT-Felder der XML gehören auch in die PDF, meiner Meinung nach, und ich versuche in der PDF auch die BT-Kennung dabeizuschreiben.
Damit würde man ersmal unangreifbar für mögliche "Unterschiedsfeteschisten".

[omnibrain]

Das Problem der Rundungsdifferenzen hat man schon immer. Früher haben sich halt "nur" die Rechnung und die Kontenbuchungen unterschieden.

Zitat von sh17:

Also ich wäre auch an einer Lösung interessiert. Die Sache mit der Rundungsdifferenz ist meiner Meinung nach im Falle einer hybriden ZUGFeRD-Rechnung nicht der richtige Weg, weil sich dann XML und PDF unterscheiden würden.

Zumindest für das Finanzamt sollte es, wenn ich das aktuelle Schreiben des BMF vom 15.10.2024 Ausstellung von Rechnungen nach § 14 Umsatzsteuergesetz (UStG); Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025 Punkt 2.3.2 (Randnummer 32) richtig verstehe kein Problem sein.

[Rollo62]

Zitat von omnibrain:

Zumindest für das Finanzamt sollte es, wenn ich das aktuelle Schreiben des BMF vom 15.10.2024 Ausstellung von Rechnungen nach § 14 Umsatzsteuergesetz (UStG); Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025 Punkt 2.3.2 (Randnummer 32) richtig verstehe kein Problem sein.

Wie genau argumentierst Du das denn aus diesem Satz?
Laut 32:

Zitat:

Enthält der Bildteil dagegen abweichende Rechnungsangaben (z. B. aufgrund manipulativer Eingriffe eine andere Leistungsbeschreibung Seite 11 oder einen abweichenden Umsatzsteuerbetrag), stellt er ggf. eine weitere (sonstige) Rechnung
dar, für die die Voraussetzungen des § 14c UStG zu prüfen sind.

Ich würde da so argumentieren, dass z.B. die XML BT-Felder enthalten kann, welche in der PDF nicht enthalten sinbd, weil diese üblicherweise irrelevant oder 0.0 sind.
Könnte man dann nicht annehmen, dass XML und PDF unterschiedlich sind, auch wenn am Ende USt und Endbetrag die gleichen Werte haben?
Der Satz betrifft ALLE abweichenden Rechnungsangaben ( meiner Meinung nach auch die intern, implizit damit zusammenhängenden Berechnungen).

Geht es dabei nur um konsistente, übliche Rechnungs-Angaben nach außen, oder muss man nicht auch alle Elemente die in Berechnungen relevant sind berücksichtigen, auch wenn Sie erstmal in der Summe neutral sind?

Das lässt sich nicht explizit ausschliessen und macht die PDF damit erstmal angreifbar.
Ob und wie relevant dass dann wird ist mal eine andere Frage.

Zur Frage BT-114, wenn man die Rundungsdifferenz explizit berechnet ( welches Verfahren genau? ) und im XML angibt, wie muss dies dann weiter in der PDF angegeben werden um konform zu sein?

[omnibrain]

Zitat von Rollo62:

Zitat von omnibrain:

Zumindest für das Finanzamt sollte es, wenn ich das aktuelle Schreiben des BMF vom 15.10.2024 Ausstellung von Rechnungen nach § 14 Umsatzsteuergesetz (UStG); Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025 Punkt 2.3.2 (Randnummer 32) richtig verstehe kein Problem sein.

Wie genau argumentierst Du das denn aus diesem Satz?
Laut 32:

Zitat:

Enthält der Bildteil dagegen abweichende Rechnungsangaben (z. B. aufgrund manipulativer Eingriffe eine andere Leistungsbeschreibung Seite 11 oder einen abweichenden Umsatzsteuerbetrag), stellt er ggf. eine weitere (sonstige) Rechnung
dar, für die die Voraussetzungen des § 14c UStG zu prüfen sind.

Indem ich weiterlese:

Zitat:

Dabei werden technisch begründete geringfügige Abweichungen, konkretisierende oder ergänzende Informationen (z. B.
aus Gründen der Darstellung verkürzte Leistungsbeschreibung oder Rundungsdifferenzen)
nicht beanstandet, wenn der Charakter als inhaltlich identisches Mehrstück nicht verloren
geht.

Aber am Ende gilt: Vor Gericht und auf Hoher See ist man in Gottes Hand. Von daher hoffe ich, dass auf allen Seiten schnell die Einsicht wächst, dass eine hybride Rechnung Mist ist und es viel besser ist nur noch die "strukturierte" Rechnung (das XML) zu verschicken.

[Rollo62]

Zitat von omnibrain:

Aber am Ende gilt: Vor Gericht und auf Hoher See ist man in Gottes Hand.

So ist es wohl, damit ist man aber bisher auch immer gut gefahren.
Leider ist heute alles in Finanzamt-Händen

Ich frage mich nur, wenn es B2B und B2C Kunden gibt und ich dem einen XML und dem anderen PDF schicke, wie ich das am sinnvollsten integrieren und umsetzen würde.
Es mag noch 1000 Sonderfälle geben, die man nicht alle im Vorhinein durchschauen kann.
Zumindest finde ich keine große Zahl an Beispielen, die das durchexerzieren.

Nicht immer weiss ich vorher genau, ob ein Kunde B2B oder B2C ist, manchmal stellt sich das erst im Nachhinein heraus, wenn er vielleicht eine Rechnung mit UStId anfordert.

Ist die Lösung im Vorfeld hart auf B2B und B2C zu unterscheiden und dann nie mehr zu ändern?

[Rollo62]

Zitat von omnibrain:

Zitat:

Dabei werden technisch begründete geringfügige Abweichungen, konkretisierende oder ergänzende Informationen (z. B.
aus Gründen der Darstellung verkürzte Leistungsbeschreibung oder Rundungsdifferenzen)
nicht beanstandet, wenn der Charakter als inhaltlich identisches Mehrstück nicht verloren
geht.

Ich versuche da nochmal eine Merkmalsanalyse:
- technisch begründete geringfügige Abweichungen
==> Das ist kein Argument für das Auslassen von Infos in der PDF, denn technisch gibt es keinen Grund auch alle BT-Felder mit in das PDF aufzunehmen

- konkretisierende ... Informationen (z. B. aus Gründen der Darstellung verkürzte ... )
==> Das Argument "verkürzte" kann man nicht so auslegen, dass die PDF Felder komplett weglässt

- ergänzende Informationen (z. B. ... Rundungsdifferenzen )
==> Gut, Rundungsdifferenzen sind damit klar, die sind aber sowieso direkt errechenbar und daher redundant.
==> Es gibt aber viele andere Informationen, bei denen es nicht so klar wäre, wie Nachlässe/Zuschläge.


- wenn der Charakter als inhaltlich identisches Mehrstück nicht verloren geht.
==> Ja, ich bin da ganz Deiner Meinung, so wie wir alle wahrscheinlich.
Die Frage ist aber, ob das rechtlich wirklich Bestand hat, wenn man alle Merkmale oben exakt analysiert, genau da bleibt eine Menge Grauzone.

Warten wir auf Gottes Entscheidung, der wird es wohl salomonisch richten

[haentschman]

Hallöle...

Zitat:

Von daher hoffe ich, dass auf allen Seiten schnell die Einsicht wächst, dass eine hybride Rechnung Mist ist und es viel besser ist nur noch die "strukturierte" Rechnung (das XML) zu verschicken.

[überspitztes Scenario]
...das erzähle mal der Oma die irgendwann ihre Stromrechnung nur als XML bekommt und auf der Sparkasse die Rechnung bezahlen will...wenn sie überhaupt eine E-Mail / Mobiltelefon hat.
Lösung (nicht ernst gemeint ):
faltbare USB Sticks für Einmalverwendung die per Post verschickt werden können.

[DeddyH]

XRechnung etc. gelten doch nur für B2B, da ist die Oma doch eh außen vor.