Skonto in E-Rechnungen korrekt abbilden

Ein Skonto sieht auf einer Papierrechnung trivial aus: „2% innerhalb von 10 Tagen, sonst netto 30“. Ein Mensch liest es, rechnet im Kopf und zahlt den reduzierten Betrag, wenn er schnell ist. In einer strukturierten E-Rechnung braucht derselbe Satz echte Sorgfalt, denn EN 16931 hat kein eigenes Feld für einen Nachlass, der nur greift, wenn der Käufer früh zahlt.

Warum es kein „Skonto-Feld“ gibt

Das EN 16931-Datenmodell beschreibt, was jetzt geschuldet ist: eine eindeutige Summe, eine eindeutige USt-Aufschlüsselung, eindeutige Positionen. Ein Frühzahler-Skonto ist nichts davon — es hängt an einem Ereignis (dem Zahlungszeitpunkt), das im Moment der Ausstellung noch nicht eingetreten ist. Diesen bedingten Betrag in ein Feld für einen eindeutigen Wert zu zwängen, ist die Wurzel fast jedes Skonto-Fehlers.

Die Zahlungsbedingungen tragen das Skonto (BT-20)

Der etablierte Weg ist der Zahlungsbedingungstext, BT-20. XRechnung definiert dafür eine maschinenlesbare Konvention, sodass die Software des Käufers Prozentsatz, Frist und — optional — den Basisbetrag auslesen kann. Jede Regel steht in einer eigenen Zeile:

#SKONTO#TAGE=10#PROZENT=2.00#
#SKONTO#TAGE=30#PROZENT=1.00#

So lassen sich mehrere Stufen ausdrücken (2% binnen 10 Tagen, 1% binnen 30), und mit #SKONTO#TAGE=14#PROZENT=3.00#BASISBETRAG=1000.00# lässt sich der Basisbetrag festlegen, wenn das Skonto nur auf einen Teil der Rechnung gilt. Freitext funktioniert für Menschen weiterhin, aber nur die strukturierte Form ist über Empfänger hinweg zuverlässig maschinenlesbar.

Die Rechnungssumme bleibt vollständig

Der entscheidende Punkt: Das Skonto wird nicht von der Rechnungssumme abgezogen. Die Rechnung wird über den vollen Betrag übermittelt, und der Zahlbetrag (BT-115) entspricht genau diesem vollen Betrag. Der reduzierte Betrag wird erst relevant, wenn der Käufer tatsächlich innerhalb der Frist zahlt. Die E-Rechnung nennt die Verbindlichkeit; das Skonto ist eine Option, die der Käufer später ziehen kann.

Nicht als Nachlass modellieren (BG-20)

Der häufigste Umsetzungsfehler ist, Skonto als Nachlass auf Dokumentebene zu kodieren, BG-20. Im Datenmodell mindert ein Nachlass den Zahlbetrag bedingungslos und fließt in die Summen und die USt-Aufschlüsselung (BG-23) ein — genau das, was ein bedingtes Frühzahler-Skonto zum Ausstellungszeitpunkt nicht tun darf. Vermischt man beides, hat man gleich zwei Fehler: Die Rechenregeln (BR-CO-…) weisen das Dokument zurück, weil die Summen nicht mehr aufgehen — und selbst wenn sie es täten, übermittelte man eine USt-Bemessungsgrundlage, die falsch ist, bis das Skonto wirklich gezogen wird.

Der USt-Aspekt

Die Umsatzsteuer folgt derselben Logik. Bei Ausstellung wird die USt auf den vollen Betrag berechnet. Erst wenn das Skonto tatsächlich in Anspruch genommen wird, ändert sich die Bemessungsgrundlage — als nachträgliche Korrektur (in Deutschland § 17 UStG), nicht als in das Originaldokument eingebaute Minderung. Die skontierte USt vorab zu kodieren, ist sowohl falsch als auch ein zuverlässiger Validierungsfehler.

Kurz gefasst

• Skonto in die Zahlungsbedingungen (BT-20), idealerweise in der strukturierten #SKONTO#-Form.
• Rechnungssumme und USt auf dem vollen Betrag belassen.
• Niemals als BG-20-Nachlass modellieren.

eunormia rechnet jede Summe serverseitig nach und weist eine Rechnung mit nicht schlüssigen Summen zurück, statt sie stillschweigend zu korrigieren. So bleibt Skonto eine bewusste Modellierungsentscheidung in den Zahlungsbedingungen — und kein Versehen, das durch das Gate rutscht und beim Empfänger als nicht-aufgehendes Dokument landet.