Gutschrift (Selbstabrechnung)
Das Gutschriftverfahren nach § 14 Abs. 2 UStG: Der Leistungsempfänger rechnet ab, nicht der Lieferant. Zwei Positionen, zwei Steuersätze, keine Zu- und Abschläge – und als einziger Unterschied zu einer gewöhnlichen Handelsrechnung der Dokumenttyp 389.
Grundlage ist die offizielle Beispielrechnung
E10_01_Gutschrift aus der Factur-X-/ZUGFeRD-Dokumentation
(FeRD-Beispielpaket, ZUGFeRD 2.5.0). Der Code unten erzeugt genau diesen
Beleg, Feld für Feld und in derselben Reihenfolge.
Einige Verweise auf dieser Seite führen in die vertiefende Dokumentation im Kunden-Bereich und verlangen eine Anmeldung.
Zwei Dinge, die „Gutschrift“ heißen
Das deutsche Wort trägt zwei völlig verschiedene Bedeutungen, und die Verwechslung ist der häufigste Fehler in diesem Bereich:
| Gutschriftverfahren (389) | Gutschrift im Sinne einer Stornierung (381) | |
|---|---|---|
| FactoorSharp | InvoiceType.SelfBilledInvoice |
InvoiceType.CreditNote |
| Wer stellt aus? | Der Leistungsempfänger rechnet für den Lieferanten ab. | Der Lieferant selbst. |
| Beträge | positiv – der Beleg sieht aus wie eine Rechnung | positiv, das Dokument spiegelt die Rechnung als Ganzes |
| Rechtsgrundlage | § 14 Abs. 2 UStG (self-billed invoice) | Korrektur einer Forderung |
| Diese Seite | behandelt diesen Fall | siehe Rechnungskorrektur (Typ 384) für die Abgrenzung |
Beim Gutschriftverfahren bleiben alle Beträge positiv. Wer hier negative Mengen setzt, weil „Gutschrift“ nach Rückabwicklung klingt, baut einen fachlich falschen Beleg. Negative Beträge gehören in die Rechnungskorrektur.
Profil COMFORT statt EXTENDED
Anders als die übrigen Beispiele auf diesen Seiten liegt dieser Beleg im Profil
Profile.Comfort – der Guideline-ID
urn:cen.eu:en16931:2017, also dem reinen EN 16931-Profil ohne
Erweiterung. Das ist keine Nachlässigkeit der Referenz, sondern die Aussage,
dass dieser Geschäftsvorfall ohne EXTENDED-Felder auskommt.
Folgerichtig fehlen hier alle Felder, die die Erweiterte Warenrechnung vorführt: Dokumentenname (BT-X-2), Testkennzeichen, Verpackungsangaben (BT-X-9) und die erweiterten Steuerbasen. Sie zu setzen wäre kein Fehler – der Writer würde sie im Profil COMFORT stillschweigend verwerfen.
1. Belegkopf
Nummer, Datum und Währung wie bei jeder Rechnung. Die einzige Zeile, die den
Beleg zur Gutschrift macht, ist invoice.Type.
2. Freitexte
Vier Notizen in ram:IncludedNote (BG-1). Die erste kommt ohne
subjectCode aus, zwei tragen REG für regulatorische
Angaben, die letzte ACB für die Formatkennzeichnung.
3. Verkäufer mit zwei Steuerregistrierungen
AddSellerTaxRegistration lässt sich mehrfach aufrufen. Hier steht
zuerst die nationale Steuernummer (FC, BT-32), dann die USt-IdNr.
(VA, BT-31). Die Reihenfolge im XML folgt der Aufrufreihenfolge.
4. Käufer – mit eigener Steuernummer
Hier zeigt sich das Gutschriftverfahren im Datenmodell: Weil der Leistungsempfänger abrechnet, trägt auch er eine USt-IdNr. im Beleg (BT-48). Bei einer gewöhnlichen Handelsrechnung bleibt dieses Feld meist leer.
5. Belegpositionen
Zwei Positionen (BG-25) ohne jeden Artikelrabatt. Brutto- und Nettopreis sind
deshalb identisch – die Referenz schreibt trotzdem beide Elemente aus.
Bemerkenswert ist, dass beide Positionen in derselben Steuerkategorie
S liegen und sich nur im Satz unterscheiden: 19 % für
Büromaterial, 7 % für Lebensmittel.
6. Zahlungsweg
SEPA-Überweisung (TypeCode 58) und das Konto des Zahlungsempfängers. Weitere Zahlungswege und deren Felder beschreibt Laden und Speichern.
7. Umsatzsteueraufstellung
Ohne Zu- und Abschläge auf Dokumentenebene ist die Bemessungsgrundlage schlicht
die Summe der zugehörigen Positionen – kein
allowanceChargeBasisAmount, keine Korrekturrechnung:
| Feld | 7 % (Pos. 2) | 19 % (Pos. 1) |
|---|---|---|
basisAmount |
275,00 | 198,00 |
taxAmount |
275,00 × 7 % = 19,25 | 198,00 × 19 % = 37,62 |
Die Spaltenfolge ist kein Versehen: Die Referenz führt 7 % vor
19 % auf, also nicht in der Reihenfolge der Positionen.
FactoorSharp gibt die Steuergruppen in der Reihenfolge der
AddApplicableTradeTax-Aufrufe aus und sortiert nicht nach. Wer
die Referenzdatei zeichengenau treffen will, muss die Aufrufe entsprechend
anordnen.
8. Zahlungsbedingung
Nur ein Fälligkeitsdatum, kein Skonto. Dass description hier
null ist, ist Absicht: Der Writer gibt ram:Description
dann gar nicht erst aus, statt ein leeres Element zu schreiben.
9. Gesamtsummen
| BT-Code | Parameter | Rechenweg |
|---|---|---|
| BT-106 | lineTotalAmount |
198,00 + 275,00 = 473,00 |
| BT-107 / BT-108 | allowanceTotalAmount / chargeTotalAmount |
0,00 – keine Zu- oder Abschläge |
| BT-109 | taxBasisAmount |
473,00 |
| BT-110 | taxTotalAmount |
19,25 + 37,62 = 56,87 |
| BT-112 | grandTotalAmount |
473,00 + 56,87 = 529,87 |
| BT-115 | duePayableAmount |
529,87 − 0,00 = 529,87 |
10. Speichern
Hier steht Profile.Comfort statt Profile.Extended
– der einzige Unterschied zu den übrigen Beispielen an dieser Stelle:
11. Gegenprobe
Die erzeugte Datei muss dieselbe Baumstruktur haben wie
E10_01_Gutschrift.xml aus dem FeRD-Beispielpaket. Zahlen vergleicht
man numerisch, damit 9.90 und 9.9000 als gleich gelten.
Ob der Beleg darüber hinaus dem Regelwerk entspricht, prüfen Sie entweder im Browser oder direkt aus Ihrem Code heraus. Für den Blick eines Menschen auf den Beleg erzeugt der Visualizer eine Lesefassung:
Das ist eine reine Ansicht, kein Rechtsdokument und kein hybrides ZUGFeRD-PDF – Details dazu unter Bildliche Darstellung.