Rechnungskorrektur
Die Korrektur einer zu viel berechneten Warenlieferung: Dokumenttyp 384, alle Beträge negativ, die Stückpreise dagegen positiv. Schritt für Schritt aufgebaut, mit dem Blick auf die Stellen, an denen sich eine Korrektur von einer Gutschrift unterscheidet.
Grundlage ist die offizielle Beispielrechnung
X14_01_Rechnungskorrektur aus der Factur-X-/ZUGFeRD-Dokumentation
(FeRD-Beispielpaket, ZUGFeRD 2.5.0, Profil EXTENDED). Der Code unten
erzeugt genau diesen Beleg, Feld für Feld und in derselben Reihenfolge.
Korrektur oder Gutschrift?
Das ist die Frage, an der die meiste Zeit hängen bleibt, und sie entscheidet über jedes Vorzeichen im Dokument. Beide Belegarten reduzieren eine Forderung, aber sie tun es auf entgegengesetzte Weise:
| Rechnungskorrektur (384) | Gutschrift (381) | |
|---|---|---|
| FactoorSharp | InvoiceType.Correction |
InvoiceType.CreditNote |
| Mengen (BT-129) | negativ | positiv |
| Stückpreise (BT-146 / BT-148) | positiv | positiv |
| Summen, Steuern, Rabatte | negativ | positiv |
| Lesart | Der Beleg korrigiert die ursprüngliche Rechnung um einen Differenzbetrag. | Der Beleg spiegelt als Ganzes die ursprüngliche Rechnung. |
Das Vorzeichen steckt in der Menge, nicht im Preis. Ein negativer Stückpreis bei positiver Menge ergibt rechnerisch dieselbe Positionssumme, ist fachlich aber unsauber und fällt bei vielen Empfängern auf. Die Referenz macht es umgekehrt, und diese Seite ebenfalls.
Die folgenden Abschnitte bauen aufeinander auf und gehören zu einem Programm. Wer FactoorSharp noch gar nicht kennt, fängt besser bei Los geht’s an – hier liegt der Schwerpunkt auf dem, was die Korrektur besonders macht. Zu jeder BT- und BG-Nummer finden Sie das zugehörige XML-Element in der Factur-X-Referenz.
1. Rechnungskopf
Neben Nummer, Datum und Währung fallen zwei Dinge auf: der Dokumenttyp und der Geschäftsprozess (BT-23), den dieses Beispiel im Gegensatz zur Warenrechnung setzt.
2. Freitexte
Dieselben Notizarten wie in der Warenrechnung, aber in anderer Reihenfolge: die
AAK-Notiz mit ContentCode steht hier vorn. Da die Gegenprobe gegen
die Referenz auch die Reihenfolge prüft, ist das kein Detail, sondern Vorgabe.
3. Verkäufer und Käufer
Unverändert gegenüber einer normalen Rechnung – eine Korrektur wechselt die Rollen nicht. Verkäufer bleibt Verkäufer, auch wenn Geld zurückfließt.
4. Belegverweise
Hier zeigt sich, worauf sich die Korrektur bezieht. Zwei zusätzliche Dokumentenreferenzen (BT-18 / BG-24) mit TypeCode 130 tragen den Reklamationsvorgang und die ursprüngliche Rechnungsnummer.
Für den Verweis auf die korrigierte Rechnung gibt es mit
ram:InvoiceReferencedDocument (BT-25/BT-26) auch ein
spezialisiertes Element. Die FeRD-Referenz nutzt es an dieser Stelle nicht,
deshalb steht es hier ebenfalls nicht im Code – wer sich nicht an die
Vorlage binden muss, ist damit aber präziser unterwegs.
5. Waren- und Rechnungsempfänger
Auch die abweichenden Empfänger bleiben, wie sie in der Originalrechnung standen.
6. Positionen
Hier steckt die eigentliche Korrektur: fünf Flaschen und zwei Packungen gehen zurück. Die Stückpreise bleiben unverändert positiv, die Mengen werden negativ, und daraus ergeben sich die negativen Positionssummen.
Die Artikelrabatte aus der Originalrechnung (BT-147) bleiben ebenfalls positiv. Sie sind Bestandteil des Preises, nicht ein Betrag auf der Rechnung: 1,50 − 0,03 − 0,02 = 1,45, und erst die negative Menge dreht das Ergebnis.
7. Rechnungsrabatte auf Dokumentenebene
Die Rabatte drehen sich mit: ein Rabatt auf eine Rückabwicklung ist eine Rückforderung, also sind Bemessungsgrundlage und Betrag negativ. Wie in jeder Rechnung mit gemischten Steuersätzen braucht jeder Rabatt eine eigene Zeile je Satz – aus zwei Rabatten werden vier Aufrufe.
8. Umsatzsteueraufstellung
Die Rechenwege sind dieselben wie in jeder Rechnung, nur mit umgekehrten
Vorzeichen. Der eine Punkt, der beim Lesen stolpern lässt: ein negativer
Rabatt erhöht die Bemessungsgrundlage wieder, deshalb ist
allowanceChargeBasisAmount hier positiv.
| Feld | 19 % (Pos. 1) | 7 % (Pos. 2) |
|---|---|---|
lineTotalBasisAmount |
−5,00 | −2,90 |
allowanceChargeBasisAmount |
−(−0,10) − (−0,05) = +0,15 | −(−0,06) − (−0,02) = +0,08 |
basisAmount |
−5,00 + 0,15 = −4,85 | −2,90 + 0,08 = −2,82 |
taxAmount |
−4,85 × 19 % = −0,9215 → −0,92 | −2,82 × 7 % = −0,1974 → −0,20 |
9. Gesamtsummen
Am Ende steht ein negativer Zahlbetrag – das ist das Kennzeichen einer Korrektur, und für den Empfänger die Aussage, dass Geld zurückfließt.
| BT-Code | Parameter | Rechenweg |
|---|---|---|
| BT-106 | lineTotalAmount |
−5,00 + (−2,90) = −7,90 |
| BT-107 | allowanceTotalAmount |
−0,10 − 0,06 − 0,05 − 0,02 = −0,23 |
| BT-109 | taxBasisAmount |
−7,90 − (−0,23) = −7,67 |
| BT-110 | taxTotalAmount |
−0,92 + (−0,20) = −1,12 |
| BT-112 | grandTotalAmount |
−7,67 + (−1,12) = −8,79 |
| BT-115 | duePayableAmount |
−8,79 – der Betrag geht an den Kunden zurück |
10. Speichern und prüfen
Gespeichert wird wie jeder EXTENDED-Beleg – Version, Profil und Syntax gehören zusammen:
Das Ergebnis muss dieselbe Baumstruktur haben wie
X14_01_Rechnungskorrektur.xml aus dem FeRD-Beispielpaket.
Ob der Beleg darüber hinaus dem Regelwerk entspricht, prüft der Validator – im Browser oder direkt aus Ihrem Code heraus. Eine Lesefassung für Menschen erzeugt der Visualizer. Beides sowie die ausführliche Dokumentation dazu finden Sie im Kunden-Bereich; wie Sie dorthin kommen, steht unter Los geht’s.