ZUGFeRD XML erstellen

[BlueStarHH]

Zitat von Rollo62:

Eine andere Frage ist auch, ich bekomme viele Rechnungen aus dem Ausland, [..] Wenn ich die als Firmenkunde zur Vorsteuer einreiche, wird das dann nicht mehr akzeptiert?

E-Rechnungen werden nur B2B im Inland eingeführt. Alles andere bleibt, wie es ist.

Zitat von Rollo62:

Das Problem mit Rundungsfehler verstehe ich nicht ganz, das ist doch generell da und wird gelöst. Das hat doch nichts mit XML zu tun.

Genau es hat nichts mit XML zu tun. Sondern mit der Festlegung, dass in der E-Rechnung Nettopreise verwendet werden müssen. Wenn man mit Nettopreisen rechnet, (egal wo, auch auf dem Papier) gibt es durch Rundungsfehler bestimmte Bruttopreise nicht. Wenn ich jetzt einem Privatkunden aber etwas zu einem bestimmten Bruttopreis verkaufe, habe ich ein Problem.

[bcvs]

Zitat von BlueStarHH:

Die E-Rechnungen können nur Nettopreise.

Wieso das? In der XML stehen genau wie auf einer Papierrechnung Netto, USt-%, USt-Betrag und Brutto drin.

[BlueStarHH]

Zitat von bcvs:

Zitat von BlueStarHH:

Die E-Rechnungen können nur Nettopreise.

Wieso das? In der XML stehen genau wie auf einer Papierrechnung Netto, USt-%, USt-Betrag und Brutto drin.

Es geht um die Positionspreise. Die sind in der XML nur netto.
Auf einer B2B-Papierrechnung sind die Positionspreise netto. Davon wird die Nettosumme gebildet und dann die MwSt. addiert um den Bruttobetrag zu ermitteln.
Auf einer B2C-Rechnung (z.B. Kassenbon im Supermarkt) sind die Positionspreise Brutto. Davon wird die Bruttosumme gebildet und die Mwst. abgezogen um die Nettosumme zu ermitteln.

[Rollo62]

Ich meine es gibt die Felder
Netto-Preis (BT-131): Rechnungspositionsbetrag ohne Steuern.
Steuersatz (BT-152): BT-152 repräsentiert den Mehrwertsteuersatz, der auf die Position angewendet wird (19% od 7%).
Steuerbetrag (BT-136): BT-136 ist das Feld für den Mehrwertsteuerbetrag auf Positionsebene.

Diese Werte sind als dezimaler Datentyp (Amount; XML-Datentyp: xs:decimal) eingebbar, mit meiner Meinung nach einer festen, definierbaren Stellenanzahl.

D.h. der Bruttopreis ist einfach BT-131 + BT-136, ebenfalls ein Dezimalwert mit definierter Stellenzahl.
Da sollte es keine Rundungsfehler geben.

Das ist aber nur was ich so aus Versuchen herausgefunden habe, das Kleingedrückte der Normen kenne ich nicht.

https://www.arbeitsagentur.de/datei/...e_ba030920.pdf

[BlueStarHH]

Zitat von Rollo62:

Da sollte es keine Rundungsfehler geben.

Doch gibt es. Ich verkaufe nicht seit gestern Rechnungssoftware Ich mache Dir nachher mal ein Beispiel mit konkreten Zahlen.

[BlueStarHH]

Ein Beispiel auf die Schnelle:

Privatkunde kauft ein Teil für 14,- EUR brutto.

Bruttorechnung:
14,00 / 1,19 = 11,76 netto

Wie soll das ganze in einer Nettorechnung aussehen? Geht nicht:
11,76 * 1,19 = 13,99 (1 Cent fehlt)

Einfach den Nettopreis erhöhen geht nicht, denn:
11,77 * 1,19 = 14,01 (1 Cent zu viel)

Hier ein Hinweis:

Zitat:

Die europäische Norm 16931 schreibt den Nettopreis als verbindliche Preisinformation vor. E-Rechnungen können daher nur auf Basis von Nettopreislisten erstellt werden.

Quelle auf die Schnelle: https://apps.datev.de/help-center/documents/1008456

[Rollo62]

Zitat von BlueStarHH:

ein Beispiel mit konkreten Zahlen.

Ja, Du meinst wahrscheinlich dass auf zwei Stellen gerundet wird.

Ausgangsdaten mit 2-Stellen nach dem Komma
11,560000 //2-Stellen
02,196400
13,756400

in der Rechnung zu 2-Stellen gerundet

11,56 // dies ist der passende Nettopreis
02,20 //
13,76 // zu diesem Bruttopreis

oder sehe ich das falsch?

Wenn Du von 3-Stellen nach dem Komma ausgehst und diese dann auf 2-Nachkommastellen rundest,
dann könnte es wohl Abweichungen geben.

Aber ist es nicht genau das, was es aktuell schon auf jeder Rechnung in gleicher Weise gibt?
Ist das eigentliche Problem, dass es dann keine "festen" Nettopreise im System gibt?

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Sorry für meine blöden Fragen, aber ich schreibe halt nur "simple" Rechnungen an meine Kunden, und es gab da niemals Probleme bzgl. Runden.
Vermutlich ist das bei Saturn und Aldi anders.

[BlueStarHH]

Zitat von Rollo62:

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Nein. In der E-Rechnung ist es eben nicht möglich, wenn ich dem Privatkunden etwas zu eimem bestimmten Bruttopreis verkaufen möchte/muss. Siehe mein Beipsiel oben. Der Kunde kauft etwas für 14,- Brutto. Es ist in diesem Fall nicht möglich eine E-Rechnung mit einer Gesamtbrutosumme von 14,- EUR auszustellen, da die E-Rechnung mit Nettopreisen auf Positionsebene arbeitet. Das gilt auch für Papiererchnungen, wenn es Bruttorechnungen sind.

[Harry Stahl]

Zitat von BlueStarHH:

Zitat von Rollo62:

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Nein. In der E-Rechnung ist es eben nicht möglich, wenn ich dem Privatkunden etwas zu eimem bestimmten Bruttopreis verkaufen möchte/muss. Siehe mein Beipsiel oben. Der Kunde kauft etwas für 14,- Brutto. Es ist in diesem Fall nicht möglich eine E-Rechnung mit einer Gesamtbrutosumme von 14,- EUR auszustellen, da die E-Rechnung mit Nettopreisen auf Positionsebene arbeitet. Das gilt auch für Papiererchnungen, wenn es Bruttorechnungen sind.

Privatkunden schickst Du sowieso keine X-Rechnung, da können die nichts mit anfangen. Die Verpflichtung gilt nur für B2B und B2G, Privatkunden kannst Du Rechnungen wie bisher zusenden.

[Rollo62]

Ok, sorry, ich muss das doch nochmal versuchen zu klären.

Ich meine es gibt zwei Methoden zur Berechnung, die Rück-Differenz-Methode (horizontale Methode) und Rück-Multiplikation (vertikale Methode).



Es kommt natürlich immer eine Differenz beim Runden raus, von 0.01 Ct, was das Finanzamt aber normalerweise akzeptiert wenn es konsistent ist.

Hat sich da was geändert seit X-Rechnung?