Skonto und E-Rechnung – wenn jahrhundertealte Handelspraxis auf ein starres Datenmodell trifft

Das Skonto ist älter als die moderne Rechnung – jedenfalls in seiner wirtschaftlichen Grundidee. Seine Geschichte beginnt dort, wo Händler anfingen, zwischen Geld heute und Geld zu einem späteren Zeitpunkt zu unterscheiden.

Schon das Wort weist nach Italien. Das deutsche Skonto wurde aus dem italienischen sconto übernommen. Scontare bedeutet unter anderem abrechnen oder abziehen und geht über contare – zählen, rechnen – letztlich auf das lateinische computare zurück.

Hinter dem Skonto steckt historisch ein sehr einfacher wirtschaftlicher Gedanke:

So betrachtet ist Skonto ursprünglich gar nicht zwingend ein Rabatt auf einen vermeintlich „eigentlichen“ Preis. Man kann die Betrachtung genauso gut umkehren: Der Skontopreis ist der Barpreis – und der höhere Rechnungsbetrag ist der Zielpreis einschließlich der Kosten des Lieferantenkredits.

Diese Zahlungsbedingung beschreibt in einem einzigen Satz gleich mehrere wirtschaftliche Größen: Preis, Kredit, Zahlungszeitpunkt und Liquiditätssteuerung.

Und genau hier beginnt das Problem der E-Rechnung.

Der alte Kaufmann denkt anders als das Datenmodell

Eine klassische Skontovereinbarung enthält wirtschaftlich betrachtet nicht nur einen Rechnungsbetrag und ein Fälligkeitsdatum. Sie beschreibt vielmehr zwei Alternativen:

Der zu zahlende Betrag hängt also vom Zeitpunkt der Zahlung ab.

Ein streng strukturiertes Rechnungsmodell denkt dagegen anders. Die europäische Norm EN 16931 geht grundsätzlich von einem fälligen Rechnungsbetrag und einem Fälligkeitsdatum aus. Es gibt ein Payment due date (BT-9) und einen Amount due for payment (BT-115).

Was fehlt, ist eine wiederholbare Struktur nach dem Muster:

Genau eine solche Struktur wäre aber erforderlich, wenn man das klassische Skonto vollständig und eindeutig maschinenlesbar abbilden wollte.

Das Problem liegt damit nicht zuerst bei XRechnung oder ZUGFeRD. Es liegt bereits im semantischen Modell der europäischen E-Rechnung.

Welcher Betrag ist eigentlich der „richtige“ Rechnungsbetrag?

Nehmen wir eine Rechnung über 1.000 Euro mit der Zahlungsbedingung: 2 % Skonto bis 10. September, ansonsten 1.000 Euro fällig am 30. September.

Welcher dieser beiden Beträge soll nun der maschinenlesbare Amount due for payment sein? Und welches Datum gehört in BT-9 Payment due date?

Wird der Skontotermin als Fälligkeit verwendet, müsste konsequenterweise eigentlich auch der reduzierte Betrag als zu zahlender Betrag ausgewiesen werden. Dann würde die Rechnung maschinenlesbar jedoch so erscheinen, als seien lediglich 980 Euro geschuldet.

Wird dagegen der volle Rechnungsbetrag von 1.000 Euro und dessen endgültiges Zahlungsziel eingetragen, ist die Rechnung mathematisch eindeutig – die wirtschaftlich wichtige Alternative „980 Euro bei früher Zahlung“ verschwindet jedoch aus den strukturierten Zahlungsdaten.

Genau daran erkennt man, dass Skonto keine einfache Fälligkeit ist. Es ist vielmehr eine zeitabhängige Zahlungsbedingung.

XRechnung löst das Problem über BT-20

In der deutschen XRechnung wird für Skontobedingungen deshalb BT-20 – Payment terms / Zahlungsbedingungen verwendet. Dort kann beispielsweise beschrieben werden, dass bei Zahlung innerhalb einer bestimmten Frist ein bestimmter Prozentsatz Skonto abgezogen werden darf.

Für Deutschland existieren dafür sogar festgelegte Konventionen, durch die Skontobedingungen innerhalb von BT-20 teilweise automatisiert ausgewertet werden können.

Das ist pragmatisch – aber konzeptionell nicht besonders elegant. Denn BT-20 ist zunächst ein Feld für Zahlungsbedingungen. Es ersetzt keine echte Datenstruktur aus Betrag, Prozentsatz, Bezugsdatum und Fälligkeit.

Man könnte sagen: Die Information wird strukturiert genug übertragen, damit Empfängersysteme sie interpretieren können – sie ist aber nicht Bestandteil des eigentlichen mathematischen Rechnungsmodells. Das ist ein wichtiger Unterschied.

Dokumentenabzug oder Kreditpreis?

Damit stellt sich auch die immer wieder diskutierte Frage, wie Skonto rechnerisch zu verstehen ist.

Bildet der maschinenlesbare Rechnungsbetrag den Barpreis ab, dann müsste der spätere Zielpreis als eine Art Aufschlag für den Lieferantenkredit betrachtet werden.

Bildet die Rechnung dagegen – wie heute üblich – den vollen Zielpreis ab, wird das Skonto bei frühzeitiger Zahlung nachträglich als Entgeltminderung behandelt.

In der Praxis hat sich die zweite Darstellung durchgesetzt: Die Rechnung lautet beispielsweise über 1.000 Euro. Der vollständige Betrag wird mit dem regulären Zahlungsziel ausgewiesen. Zahlt der Kunde innerhalb der Skontofrist, darf er 20 Euro abziehen.

Für eine klassische Papierrechnung ist das problemlos verständlich. Für ein streng maschinenlesbares Datenmodell entsteht jedoch eine gewisse Inkonsistenz: Der ausgewiesene Amount due for payment beträgt 1.000 Euro, obwohl eine vertragsgemäße Zahlung von nur 980 Euro die Forderung ebenfalls vollständig erfüllt.

Der Betrag, der tatsächlich „due for payment“ ist, hängt also von einem Ereignis ab, das erst nach Ausstellung der Rechnung eintritt: dem Zeitpunkt der Zahlung.

ZUGFeRD Extended kann mehr – löst aber nicht das europäische Grundproblem

Erweiterte Rechnungsprofile können komplexere kaufmännische Sachverhalte modellieren. Insbesondere ZUGFeRD Extended geht über den Kernumfang der EN 16931 hinaus und bietet Möglichkeiten, Zahlungsbedingungen differenzierter darzustellen.

Das ist technisch interessant, beseitigt aber das grundsätzliche Problem nicht. Denn sobald eine Rechnung interoperabel im Sinne der europäischen Norm verarbeitet werden soll, muss man sich auf deren gemeinsames semantisches Modell verlassen können.

Eine Funktion, die ausschließlich in einem erweiterten Profil vorhanden ist, kann deshalb nicht als allgemeine Lösung für die europäische E-Rechnung gelten.

Gerade darin zeigt sich die Grenze zwischen einem Austauschstandard und einem vollständigen kaufmännischen Datenmodell. Die EN 16931 muss möglichst viele Rechnungen europaweit eindeutig verarbeitbar machen. Sie bildet deshalb einen gemeinsamen Nenner. Historisch gewachsene nationale Handelspraktiken wie das deutsche Skonto passen nicht immer vollständig in diesen Nenner.

Skonto ist kein Rabatt wie jeder andere

Das eigentliche Missverständnis entsteht häufig bereits dadurch, dass Skonto einfach als Rabatt betrachtet wird.

Ein Mengenrabatt lässt sich problemlos in einer Rechnung berechnen: Aus 1.000 Euro werden 950 Euro. Das Ergebnis steht bereits bei Ausstellung der Rechnung fest.

Beim Skonto dagegen ist bei Rechnungsstellung noch nicht bekannt, welcher Betrag letztlich gezahlt werden wird. Der Kunde entscheidet durch sein Zahlungsverhalten, welches der beiden wirtschaftlichen Angebote er annimmt.

Genau deshalb ist Skonto mathematisch etwas anderes als ein gewöhnlicher Rechnungsrabatt. Man könnte es als bedingten Preis beschreiben:

Und genau für eine solche Funktion ist die klassische EN-16931-Rechnung nicht ausgelegt.

Ein historisches Fossil trifft auf die Digitalisierung

Das Skonto wirkt in der modernen E-Rechnung deshalb tatsächlich ein wenig wie ein historisches Fossil.

Nicht weil es wirtschaftlich überholt wäre – ganz im Gegenteil. Es ist bis heute ein wirkungsvolles Instrument zur Liquiditätssteuerung.

Aber seine Logik stammt aus einer Handelswelt, in der ein Kaufmann problemlos verstand: „Heute kostet es weniger als in drei Wochen.“

Die moderne E-Rechnung versucht dagegen, jeden Bestandteil einer Rechnung eindeutig in Datenfelder und Geschäftsregeln zu zerlegen. Dabei zeigt sich, dass nicht jede jahrhundertealte kaufmännische Vereinbarung in ein einfaches Schema aus Rechnungsbetrag + Fälligkeitsdatum passt.