Ein Metallbaubetrieb liefert Geländer an einen Generalunternehmer und räumt 3 % Skonto bei Zahlung binnen zehn Tagen ein. Auf der PDF-Rechnung stand dieser Satz zwanzig Jahre lang unten links, und irgendjemand in der Kreditorenbuchhaltung hat ihn gelesen, den Abzug ausgerechnet und die Zahlung vorgezogen. Seit der Betrieb XRechnungen stellt, passiert etwas anderes: Die Software des Kunden liest die Zahlungsbedingungen aus dem strukturierten Datensatz, findet dort keinen maschinenlesbaren Skonto-Eintrag — und terminiert die Zahlung nüchtern auf das Fälligkeitsdatum. Volle 30 Tage. Der Skonto-Anreiz, für den der Betrieb bereit war, drei Prozent des Rechnungsbetrags herzugeben, ist schlicht unsichtbar geworden.
Das ist kein konstruiertes Beispiel, sondern die logische Folge davon, wie automatisierte Rechnungseingänge arbeiten: Was nicht in strukturierter Form im XML steht, existiert für den Zahllauf nicht. Und ausgerechnet beim Skonto — in Deutschland gelebte Praxis, im Baugewerbe fast schon Vertragsstandard — hat der europäische Rechnungsstandard eine Lücke gelassen, die Deutschland mit einer bemerkenswert eigenwilligen Konstruktion gestopft hat. Um die geht es heute.
Warum es überhaupt eine Skonto-Syntax gibt
Die europäische Norm EN 16931, das semantische Datenmodell hinter XRechnung, ZUGFeRD und Peppol BIS, kennt kein eigenes Feld für Skonto. Es gibt Felder für das Fälligkeitsdatum (BT-9), für Nachlässe auf Dokumentenebene, für Zahlungsmittel — aber keines, in das man „2 % Abzug bei Zahlung binnen 14 Tagen“ strukturiert eintragen könnte. Für ein Land, in dem Skonto eher Regel als Ausnahme ist, ist das ein echtes Problem.
Der Standard XRechnung — die deutsche Ausprägung (CIUS) der Norm, gepflegt von der KoSIT in Bremen — hat deshalb eine Konvention geschaffen: Skontoangaben werden als maschinenlesbare Zeichenkette im Freitextfeld „Zahlungsbedingungen“ (BT-20) übermittelt. Man muss das einmal sacken lassen: Ein Freitextfeld, in dem ein streng formatierter String steht, den Software parsen soll. Das ist ein Hack. Ein offizieller, dokumentierter, normativ geprüfter Hack — aber ein Hack. Und wie jeder Hack ist er unerbittlich gegenüber kleinen Abweichungen, die einem menschlichen Leser nie auffallen würden.
Überwacht wird die Konvention von der Geschäftsregel BR-DE-18. Wer Skonto anders formuliert, bekommt beim Validieren genau diesen Code zu sehen.
Die Syntax, Zeichen für Zeichen
Das Muster sieht so aus:
#SKONTO#TAGE=14#PROZENT=2.00#
Vier Dinge muss diese Zeile leisten, und jedes einzelne ist eine eigene Fehlerquelle.
Großbuchstaben, keine Leerzeichen. Die Schlüsselwörter SKONTO, TAGE, PROZENT müssen exakt so geschrieben werden — #Skonto#Tage=14#… fällt durch, ebenso ein wohlmeinendes Leerzeichen nach dem Gleichheitszeichen.
TAGE ist eine ganze Zahl. Vierzehn Tage heißt TAGE=14, nicht TAGE=14.0 und erst recht nicht TAGE=zwei Wochen.
PROZENT verlangt den Punkt und exakt zwei Nachkommastellen. Zwei Prozent sind PROZENT=2.00 — ohne Vorzeichen, mit Dezimalpunkt. Das deutsche Komma (2,00) ist der vielleicht häufigste Einzelfehler in diesem Feld, dicht gefolgt von der verkürzten Schreibweise PROZENT=2.
Jede Angabe steht in einer eigenen Zeile, abgeschlossen mit # und einem XML-konformen Zeilenumbruch. Zwei Skonto-Staffeln gehören in zwei Zeilen:
#SKONTO#TAGE=7#PROZENT=3.00#
#SKONTO#TAGE=14#PROZENT=2.00#
Zusätzlicher Freitext („Zahlbar innerhalb von 30 Tagen netto“) ist im selben Feld erlaubt — aber in eigenen Zeilen, sauber getrennt von den Skonto-Einträgen. Wie heikel die Zeilenumbruch-Mechanik ist, zeigt ein Blick in die Versionshistorie des offiziellen Prüfwerkzeugs: Die KoSIT hat die Newline-Behandlung von BR-DE-18 gleich zweimal nachgebessert — 2020 kam die Prüfung des abschließenden Zeilenumbruchs hinzu, Ende 2021 wurde ein Fehler korrigiert, durch den die letzte Zeile ohne Umbruch fälschlich abgelehnt wurde. Wenn schon das Prüfwerkzeug selbst hier zweimal nachjustieren musste, darf man Implementierern verzeihen, dass sie an derselben Stelle scheitern.
Zwei Ergänzungen für Fortgeschrittene. Erstens: Bezieht sich der Abzug nicht auf den vollen fälligen Betrag — im Baugewerbe üblich, wenn bereits Abschläge geflossen sind oder Teilbeträge skontierfähig sind —, kommt der optionale Parameter #BASISBETRAG=…# ans Ende der Zeile, ebenfalls mit Punkt und zwei Nachkommastellen; auch negative Werte sind zulässig. Zweitens: Dieselbe Mechanik funktioniert mit dem Schlüsselwort VERZUG für Verzugszinsen — #VERZUG#TAGE=30#PROZENT=9.00# — und wird von derselben Regel geprüft.
Wo das alles technisch landet, hängt von der Syntax-Familie ab: In UBL steht die Zeichenkette in cac:PaymentTerms/cbc:Note, in der CII-Syntax (und damit auch im XML-Teil einer ZUGFeRD-Rechnung im Profil XRechnung) in ram:SpecifiedTradePaymentTerms/ram:Description.
Warnung oder Fehler? Kommt darauf an, wen Sie fragen
Jetzt wird es interessant, denn die Antwort auf die naheliegende Frage — „fällt meine Rechnung damit durch?“ — ist unbefriedigend uneinheitlich.
In der Prüfkonfiguration der KoSIT, die hinter dem offiziellen Validator und vielen Eingangsplattformen steht, ist BR-DE-18 als Warnung geführt: Die Rechnung gilt weiterhin als konform, der Prüfbericht weist den Verstoß aber aus. Kommerzielle Prüfwerkzeuge sehen das teils strenger und stufen denselben Verstoß als kritischen Fehler ein. Und einzelne Empfangssysteme entscheiden nach eigenen Regeln, was sie zurückweisen.
Unsere Meinung dazu ist eindeutig: Die Einstufung ist die falsche Frage. Selbst wenn jede Plattform die Rechnung durchwinkt, haben Sie verloren — nämlich genau das, wofür Sie das Skonto anbieten. Ein Skonto, das die Software des Kunden nicht lesen kann, verkürzt keine Zahlungsziele. Im besten Fall ruft jemand an und fragt nach. Im Normalfall passiert das, was im Eingangsbeispiel passiert: Die Zahlung kommt zum Nettotermin, und der Anreiz war umsonst. Umgekehrt gilt für die Empfängerseite: Zieht Ihre Buchhaltung Skonto auf Basis einer Freitextangabe, die das System nicht validiert hat, sind Rückfragen und Differenzen programmiert.
Dazu kommt der steuerliche Rahmen, der seit dem BMF-Schreiben vom 15. Oktober 2025 deutlich konkreter geworden ist: Die Finanzverwaltung unterscheidet bei E-Rechnungen ausdrücklich zwischen Formatfehlern, Geschäftsregelfehlern und inhaltlichen Fehlern, empfiehlt die technische Validierung ein- wie ausgehender Rechnungen nachdrücklich — und stellt klar, dass bei hybriden Formaten wie ZUGFeRD der XML-Datensatz maßgeblich ist, nicht das PDF. Der beliebte Ausweg, das Skonto eben nur hübsch ins PDF-Sichtexemplar zu schreiben, ist damit endgültig keiner mehr: Was zählt, ist, was im strukturierten Teil steht.
Die Fehler, die wir immer wieder sehen
Aus Validierungsläufen lässt sich eine kleine Typologie destillieren. Das Komma statt des Punkts haben wir erwähnt; es entsteht meist, wenn die Rechnungssoftware Prozentwerte lokalisiert formatiert und ungefiltert in den String gießt. Die fehlende zweite Nachkommastelle (PROZENT=2.5) ist Variante zwei desselben Problems. Dann der Klassiker: Skonto nur als Prosa — „Bei Zahlung innerhalb von 10 Tagen gewähren wir 3 % Skonto“ — grammatikalisch einwandfrei, maschinell wertlos. Mehrere Staffeln in einer Zeile aneinandergereiht statt zeilenweise getrennt. Kleingeschriebene Schlüsselwörter aus einem Template, das nie gegen den Validator lief. Und schließlich die Inkonsistenz zwischen Feldern: ein Fälligkeitsdatum in BT-9, das der Skonto-Frist widerspricht, weil beide aus unterschiedlichen Systemteilen befüllt werden.
Fast alle diese Fehler haben gemeinsam, dass sie im Ausgangssystem einmal entstehen und dann in jeder Rechnung stecken. Das ist die schlechte und die gute Nachricht zugleich: Ein einziger unentdeckter Formatierungsfehler multipliziert sich in Hunderte fehlerhafte Rechnungen — aber ein einziger Fix im Template repariert sie alle. Deshalb gehört die Skonto-Zeile zu den Dingen, die man beim Umstieg auf die E-Rechnung genau einmal gründlich testet, mit einer echten Rechnung aus dem eigenen System statt mit dem Musterbeispiel des Herstellers. Wie bei den Rechenregeln der Summenfelder (BR-CO-10) oder der Leitweg-ID bei öffentlichen Auftraggebern (BR-DE-15) gilt: Der Fehler ist trivial zu beheben, wenn man ihn sieht — man muss ihn nur sehen, bevor der Kunde ihn sieht.
Wen das ab wann betrifft
Zur Einordnung der Dringlichkeit: Empfangen können muss E-Rechnungen seit dem 1. Januar 2025 jedes inländische Unternehmen. Ausstellen müssen sie ab dem 1. Januar 2027 alle Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz, ab dem 1. Januar 2028 praktisch alle. Wer an die öffentliche Hand fakturiert, kennt die XRechnung ohnehin längst. Gerade die Branchen, in denen Skonto fest zum Geschäft gehört — Bau und Ausbau, Großhandel, Zulieferer —, rutschen mit der 800.000-Euro-Schwelle mehrheitlich schon in die 2027er-Welle. Die Skonto-Syntax ist damit kein Nischenthema für Verwaltungslieferanten mehr, sondern ab kommendem Jahr Alltag im B2B-Geschäft.
Ein Blick nach vorn gehört zur Ehrlichkeit dazu: Aktuell gilt der Standard XRechnung in Version 3.0.2, deren jüngstes Bundle die KoSIT zum 31. Januar 2026 veröffentlicht hat. Für Mitte bis Ende 2026 ist XRechnung 4.0 angekündigt, aufsetzend auf der überarbeiteten Norm EN 16931-1:2026 — mit neuem Datenmodell, Sammelrechnungen und einem modularen Erweiterungskonzept. Ob das Skonto dabei endlich ein echtes strukturiertes Feld bekommt, ist bislang offen. Bis dahin — und für alle Rechnungen, die bis zum Ende der Übergangsfristen im 3.0.2-Format laufen — bleibt die #SKONTO#-Zeichenkette der einzige Weg, Skonto maschinenlesbar zu übermitteln. Wer sie heute sauber implementiert, hat also nichts umsonst gebaut.
In dreißig Sekunden Gewissheit
Ob Ihre Zahlungsbedingungen der Syntax standhalten, müssen Sie nicht raten: Laden Sie eine XRechnung oder ZUGFeRD-Datei aus Ihrem System in unseren kostenlosen Validator — ohne Registrierung, die Datei wird nach der Prüfung nicht gespeichert. Sie sehen sofort, ob BR-DE-18 anschlägt und was genau zu korrigieren ist. Und wenn Sie die Prüfung dauerhaft in Ihren Rechnungsausgang einbauen wollen, damit der Komma-statt-Punkt-Fehler gar nicht erst zum Kunden gelangt: Die API-Dokumentation zeigt, wie das mit einem einzelnen API-Aufruf funktioniert.
Zuletzt aktualisiert: 10.08.2026. Quellen: XStandards Einkauf (KoSIT) — FAQ XRechnung; XStandards Einkauf — Versionen und Bundles der XRechnung; KoSIT — Changelog des XRechnung-Schematron (v2.5.0, 31.01.2026); Aloaha — Skonto und Verzugszinsen (BT-20); Invoice-Converter — BT-20 Payment Terms; Bonpago — XRechnung-Fehlercodes verstehen; Ecovis KSO — E-Rechnung 2026: Hinweise zum BMF-Schreiben vom 15.10.2025; Factora — XRechnung 4.0: Zeitplan und Änderungen; Cosinex-Blog — XRechnung 4.0 (25.03.2026).