XRechnung ZUGFeRD - Zahlungsmethode - Vorkasse

[user69]

Hallo,

Wie bildet man denn in Der XRechnung die Zahlungsmethode Vorklasse (per Überweisung) ab?
Ich konnt dazu in „UNTDID 4461 Payment Means Code„ nichts recht finden.

Und wie würde online bezahlt (also auch Vorkassse) per Kreditkarte am besten sein?
Laut UNTDID 4461 Payment Means Code kämen wohl 3 in Frage:
68: Online Payment Service
54: Credit Card
55: Debit Card
Ich denk 68 wäre hier am besten, da ich eh nicht weiß, ob nun Kreditkarte oder Debitkarte genutzt wurden und online Payment service das gut beschreibt.

Hatte das Problem schon wer?

[sh17]

Streng genommen würde Vorkasse ja bedeuten, dass man erst die Zahlung leisten muss. Wenn das Geld da ist, dann wird die Rechnung geschrieben. Einen Zahlungsweg braucht man dann nicht mehr.

[hstreicher]

Guten Morgen

wir (Grosshandel) erstellen erst eine Vorkasse Rechnung
senden sie dem Kunden zu und er überweist

mfg Hannes

[sh17]

Es spielt eigentlich keine Rolle, ob es sich Vorkasse nennt oder nicht. Es ist eine Rechnung und es wird ein gewünschter Zahlungsweg vorgeschlagen, unter dem man die Zahlung erwartet.

Sollten weitere Bedingungen gelten (wie Auslieferung nach Zahlungseingang), kann man das in den InvoiceNotes vermerken.

[user69]

Ja ich habe auch schon im Internet recherchiert, dass wohl die Vorkasse wie eine Teilrechnung (zu 100%) wäre.
Dann müsste ich aber wohl immer noch ein Endrechnung mit der Summe 0 und dem eigentlichen Leistungsdatum schicken. Das muss ja irgendwo hin. Ich muss da den Steuerberater noch mal genau fragen.

Bisher haben wir die Vorkasse als proforma invoice (wie ein Angebot halt) geschickt.
Dann nach Zahlungseingang geliefert und die Rechnung geschickt. Auf der Rechnung war vermerkt: Rechnung ist bezahlt per Vorkasse. Ohne Zahlungsziel.

Geht sowas dann und man lässt den Zahlungsweg einfach leer?

[sh17]

Es gibt den Code 386 Vorauszahlungsrechnung.

Vielleicht passt der ja. Wenn das alles so funktioniert, bekommt der Kunde am Ende noch einmal
die Rechnung mit der selben Rechnungsnummer? Wie funktioniert das mit der Steuer? Ist eine proforma Rechnung
vorsteuerberechtigt?

[user69]

Ich muss die Vorkasse im Detail noch mal mit dem Steuerberater besprechen.
Genau deine Fragen sind auch meine, ich denk am ende werden wir das Verfahren hier etwas abändern, dass die Vorkasserechnung wohl wie eine Teilrechung (100%) behandelt werden muss.

Aber wie wären die korrekten Einträge in dem xml für eine Bestellung im Onlineshop per Kreditkarte oder paypal?
Da kann ja nur eine Rechnung (im Nachhinein) gestellt werden und diese muss auf bezahlt gesetzt werden, da sie ja bereist (per unbekannter karte/paypal/whatever) bezahlt wurde.

[sh17]

Nutzt Du XRechnung-for-Delphi? Dann gibt es hier Beispiele

https://github.com/LandrixSoftware/X...2TestCases.pas

[johndoe049]

Zitat:

Zitat von sh17 (Beitrag 1544231)

Es gibt den Code 386 Vorauszahlungsrechnung.

Vielleicht passt der ja. Wenn das alles so funktioniert, bekommt der Kunde am Ende noch einmal
die Rechnung mit der selben Rechnungsnummer? Wie funktioniert das mit der Steuer? Ist eine proforma Rechnung
vorsteuerberechtigt?

Keine Ahnung, ob das so richtig ist, aber wir buchen Proforma Rechnungen ohne Vorsteuer ein und wandeln dann in Rechnung mit Vorsteuer um, wenn die richtige Rechnung ankommt. Wenn keine richtige Rechnung kommt, wandeln wir auch um, schreiben aber in den Buchungskommentar, dass wir keine richtige Rechnung erhalten haben. Hat bisher weder Finanzamt noch Steuerberater bemängelt.

Zitat:

Zitat von user69 (Beitrag 1544233)

Ich muss die Vorkasse im Detail noch mal mit dem Steuerberater besprechen.
Genau deine Fragen sind auch meine, ich denk am ende werden wir das Verfahren hier etwas abändern, dass die Vorkasserechnung wohl wie eine Teilrechung (100%) behandelt werden muss.

Aber wie wären die korrekten Einträge in dem xml für eine Bestellung im Onlineshop per Kreditkarte oder paypal?
Da kann ja nur eine Rechnung (im Nachhinein) gestellt werden und diese muss auf bezahlt gesetzt werden, da sie ja bereist (per unbekannter karte/paypal/whatever) bezahlt wurde.

Ein Kunde von uns verwendet bei bereits gezahlten Rechnungen das Feld BT-113 für Angabe des gezahlten Betrages und trägt die Zahlungsart als Kommentar oder als Zahlungmethode ein. OK, der hat viel mit Behörden oder Generalunternehmern zu tun. Die wollen schon seit einiger Zeit XRechnung haben...

[Olli73]

Zitat:

Zitat von johndoe049 (Beitrag 1544245)

Keine Ahnung, ob das so richtig ist, aber wir buchen Proforma Rechnungen ohne Vorsteuer ein und wandeln dann in Rechnung mit Vorsteuer um, wenn die richtige Rechnung ankommt. Wenn keine richtige Rechnung kommt, wandeln wir auch um, schreiben aber in den Buchungskommentar, dass wir keine richtige Rechnung erhalten haben. Hat bisher weder Finanzamt noch Steuerberater bemängelt.

Soweit ich weiß, darf man Vorsteuer aber nur dann Absetzen, wenn man eine "ordentliche!" Rechnung hat.

Und da gibt es auch noch Vorgaben, was alles drauf muss. Fehlt z.B. die Rechnungsnummer oder die Steuernummer (bzw. alternativ Umsatzsteuer-ID) o.Ä., dann ist das nix "ordentliches" mehr.

[Redeemer]

Zitat:

Zitat von sh17 (Beitrag 1544231)

Es gibt den Code 386 Vorauszahlungsrechnung.

Interessant. Hatte ich vorher noch nie gesehen diesen Typ.
Wir hatten das Problem letzte Woche und waren zu dem Entschluss gekommen, dass XRechnung vielleicht nicht mal anwendbar sei, da eine Anzahlungsrechnung keine Rechnung ist.

[user69]

Zitat:

Zitat von sh17 (Beitrag 1544236)

Nutzt Du XRechnung-for-Delphi? Dann gibt es hier Beispiele

https://github.com/LandrixSoftware/X...2TestCases.pas

Danke das hilft schon mal ungemein.

Ich setzte für die Rechnungen nicht delphi ein, da es mir doch recht aufwendig ist ein Rechungsprogramm nachzubauen.

Wir nutzen da sevdesk, besser gesagt stellen gerade darauf um. Aber da die xRechnung noch recht neu ist haperts da doch noch bei einigem. Ich musste aber auch erst mal verstehen was bei der xRechnung geht und wie wir dies abbilden. Gerade für die Vorkassen ist wohl unser derzeitiges Verfahren so nicht mehr nutzbar und wir müssen umdenken. Bei den online shop Rechungen muss sevdesk nachbessern, da die keine Zahlungsmethode dafür haben und eigene fürs xml (verständlicherweise) nicht gehen.

Grundsätzlich finde ich die xRechnung gut, aber die Umsetzung der Rechungsprogramme in letzter Minute (mit zu erwartenden Problemen) finde ich schlecht. So bleibt keine Zeit für Verbesserungen im Vorfeld.

Und ja, ich bin ja noch nicht zur xRechnung verpflichtet, aber große Kunden drängen jetzt schon drauf und wollen normale pdfs per email zukünftig nicht mehr annehmen, nur noch per post.

[Redeemer]

386 führt zu folgender Warnung:

Zitat:

[BR-DE-17] Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).

Gut, ist nur 'ne Warnung.

[sh17]

in XRechnung mag das sein. Ist das in einer ZUGFeRD 2.3.2 oder XRechnung 3 gekommen?

[Redeemer]

Validiert habe ich eine XML, die mit deiner Bibliothek im Format XRechnungVersion_30x_UBL erstellt wurde.
Sie gehört zwar zu einem ZUGFeRD, aber validiert habe ich sie einzeln.

[AuronTLG]

Ich würde aufgrund kürzlicher Erfahrungen dazu raten, auf Warnungen zu achten, wenn öffentliche Auftraggeber im Spiel sind.

Bei nem Kunden wurde neulich eine XRechnung von einer öffentlichen Stelle zurückgewiesen. Überprüfung ergab, dass alle Validatoren sie als valide eingestuft haben, es aber zwei Warnungen gab, die für die öffentliche Stelle wohl ausschlaggebend waren.
Das wird wahrscheinlich nicht bei jeder Art von Warnung der Fall sein, ist aber eine Möglichkeit.

Es könnte also unter Umständen passieren, muss aber nicht, dass eine öffentliche Stelle keinen Code 386 haben will.

[Redeemer]

Aber was macht man dann mit Anzahlungsrechnungen? 325 würde vielleicht auch passen, aber das wird ebenfalls nicht empfohlen.
326 ist die Teil-Schlussrechnung, aber Anzahlungsrechnungen sind definitiv keine Schlussrechnungen.

[user69]

Ok, nach Rücksprache mit dem Steuerberater ändern wir unser vorgehen:
Es wir immer gleich eine normale Rechnung ausgestellt (bei Vorkasse mit Leistungsdatum in der Zukunft). Dazu gib es dann später einen Lieferschein. Eine Endrechnung ist nicht erforderlich.
PS: das ist unsere Lösung - keine Steuerberatung.

Falls ein Kunde nicht bezahlt könne wir diese sogar einklagen oder aber stonieren.