Skonto in E-Rechnungen: BT-20 richtig nutzen

Skonto gehört in einer E-Rechnung nicht nur in den sichtbaren Hinweistext. Damit Empfänger, Prüfportal und Buchhaltung dieselbe Zahlungsbedingung verstehen, müssen Frist, Prozentsatz und gegebenenfalls der Basisbetrag im passenden Datenfeld stehen. Besonders wichtig ist das bei XRechnung: Dort wird Skonto nach einer festgelegten Syntax im Feld BT-20 übermittelt. Österreichische Formate und ZUGFeRD lösen dieselbe Aufgabe technisch anders.

Für KMU folgt daraus eine einfache Regel: Vereinbaren Sie Skonto kaufmännisch eindeutig, speichern Sie die Kondition strukturiert und prüfen Sie vor dem Versand, wie das konkrete Zielformat sie abbildet. Ein korrekt aussehendes PDF beweist noch nicht, dass die XML-Daten vollständig oder maschinenlesbar sind.

Skonto ist Vereinbarung, Zahlungsbedingung und Rechenregel

Skonto ist ein Preisnachlass für eine besonders frühe Zahlung. Das österreichische Unternehmensserviceportal weist ausdrücklich darauf hin, dass Skonto vereinbart sein muss. Ist kein Skonto vereinbart und erscheint es auch nicht auf der Rechnung, darf der Kunde den Rechnungsbetrag nicht eigenmächtig kürzen.

Eine brauchbare Skontobedingung beantwortet mindestens vier Fragen:

Wie hoch ist der Prozentsatz?
Innerhalb welcher Frist darf er abgezogen werden?
Ab welchem Datum läuft diese Frist?
Auf welchen Betrag wird der Prozentsatz angewendet?

Im klassischen Beleg können diese Angaben als Satz erscheinen: „2 Prozent Skonto bei Zahlung innerhalb von 10 Tagen, netto fällig in 30 Tagen.“ Eine E-Rechnung muss denselben Inhalt zusätzlich so transportieren, dass die Empfängersoftware ihn ohne Textraten verarbeiten kann. Genau hier unterscheiden sich XRechnung, ZUGFeRD und österreichische Einreichungsformate.

Welche Felder in EN 16931 wichtig sind

EN-16931-basierte E-Rechnungen trennen das Fälligkeitsdatum und die Zahlungsbedingungen. Das Fälligkeitsdatum wird als BT-9 geführt, Zahlungsbedingungen als BT-20. Nach den für Peppol BIS Billing dokumentierten Geschäftsregeln muss bei einer Rechnung mit positivem Zahlbetrag entweder ein Fälligkeitsdatum oder eine Zahlungsbedingung vorhanden sein.

Diese Regel ersetzt jedoch keine klare Skontovereinbarung. Ein Fälligkeitsdatum sagt nur, wann der volle Betrag spätestens bezahlt werden soll. Es enthält weder Skontosatz noch Skontofrist. Umgekehrt sollte eine Skontoangabe das endgültige Zahlungsziel nicht verschleiern. Für eine zuverlässige Verarbeitung sind daher drei Ebenen zu unterscheiden:

Ebene	Beispiel	Prüffrage
Kaufmännische Vereinbarung	2 Prozent innerhalb von 10 Tagen	Ist die Kondition mit dem Kunden vereinbart?
Rechenregel	Prozentsatz, Frist, Fristbeginn und Basisbetrag	Kann der zulässige Zahlbetrag eindeutig berechnet werden?
Formatabbildung	BT-20, ZUGFeRD-Zahlungsbedingung oder österreichisches Formatfeld	Kann das Zielsystem die Angabe maschinell auslesen?

XRechnung: Skonto folgt einer strengen BT-20-Syntax

Die europäische Norm selbst sieht keine eigene strukturierte Skonto-Datengruppe vor. XRechnung schließt diese Lücke mit einer nationalen Konvention im Feld BT-20. Die offizielle XRechnung-FAQ nennt dafür eine genau definierte Schreibweise.

Ein einfaches Beispiel für 2 Prozent Skonto innerhalb von 10 Tagen lautet:

#SKONTO#TAGE=10#PROZENT=2.00#

Die Segmente beginnen und enden mit einem Doppelkreuz. Der Prozentsatz wird ohne Prozentzeichen, mit Punkt als Dezimaltrennzeichen und zwei Nachkommastellen angegeben. Zusätzliche Leerzeichen oder freie Zusätze innerhalb dieser strukturierten Zeile sind nicht vorgesehen. Werden mehrere Konditionen übermittelt, braucht jede vollständige Angabe einen XML-konformen Zeilenumbruch.

Bezieht sich Skonto nicht auf den gesamten fälligen Betrag BT-115, kommt ein viertes Segment hinzu:

#SKONTO#TAGE=10#PROZENT=2.00#BASISBETRAG=1000.00#

Unstrukturierte Zusatzinformationen dürfen ebenfalls in BT-20 stehen. Die strukturierte Skontozeile und ein verständlicher Erläuterungstext schließen einander laut XRechnung-FAQ nicht aus. Sie sollten aber sauber getrennt bleiben, damit ein Parser die definierte Zeile erkennt.

Praxisbeispiel Deutschland

Ein deutscher Maschinenservice stellt einem öffentlichen Auftraggeber 1.190 Euro brutto in Rechnung. Vereinbart sind 2 Prozent Skonto innerhalb von 10 Tagen und ein endgültiges Zahlungsziel von 30 Tagen. Bezieht sich der Nachlass auf den gesamten fälligen Betrag, ergibt sich ein Skonto von 23,80 Euro und ein früher Zahlbetrag von 1.166,20 Euro.

Die Rechnung sollte das endgültige Fälligkeitsdatum eindeutig ausweisen und die Skontoregel in der geforderten BT-20-Syntax transportieren. Ein sichtbarer Satz im PDF ist hilfreich für Menschen, ersetzt aber die prüfbare XML-Angabe nicht. Vor dem Versand gehört die Datei durch einen Validator, denn schon ein Komma statt eines Punkts oder ein zusätzliches Leerzeichen kann die strukturierte Auswertung verhindern.

ZUGFeRD: Profil und XML sind entscheidend

ZUGFeRD verbindet ein menschenlesbares PDF/A-3 mit eingebetteten XML-Daten. Für Skonto entsteht daraus eine typische Fehlerquelle: Die Zahlungsbedingung kann im PDF vollständig aussehen, während die XML-Seite nur ein Fälligkeitsdatum oder einen allgemeinen Beschreibungstext enthält.

Das aktuelle ZUGFeRD-Infopaket ist seit Juni 2026 in Version 2.5 verfügbar. FeRD beschreibt das Profil EN 16931 als geeignete Grundlage für normkonforme E-Rechnungen. Das Profil EXTENDED unterstützt darüber hinaus komplexere Geschäftsprozesse und strukturierte Zahlungsbedingungen. Welches Profil ein Empfänger akzeptiert, muss deshalb vorab geklärt werden.

Für KMU ist weniger der Name des XML-Elements entscheidend als das Prüfergebnis:

Enthalten PDF und XML dieselbe Skontobedingung?
Ist das verwendete Profil beim Empfänger zugelassen?
Bleibt der endgültig fällige Betrag nachvollziehbar?
Besteht die Datei die zum Profil passenden Geschäftsregeln?

Wer zwischen Formaten wechselt, sollte Zahlungsbedingungen nicht als beliebigen Freitext kopieren. Die XRechnung-Syntax ist eine deutsche Formatkonvention. Sie wird nicht automatisch zur strukturierten Skontoangabe in jedem ZUGFeRD-Profil.

Österreich: ebInterface und Peppol nicht mit XRechnung verwechseln

In Österreich sind strukturierte E-Rechnungen an Bundesdienststellen seit 2014 verpflichtend. Die Einbringung kann über das Unternehmensserviceportal oder über Peppol erfolgen. Das Portal e-Rechnung.gv.at führt optionale Zahlungsbedingungen und Zahlungsdaten als eigene Rechnungsinhalte.

Für die österreichische Formatwelt ist ebInterface besonders relevant. Die technischen Vorgaben sehen eigene Strukturen für Zahlungsbedingungen vor. Eine XRechnung-Zeile mit #SKONTO#... sollte daher nicht ungeprüft in ein österreichisches XML-Feld übernommen werden. Bei Peppol wiederum gelten das gewählte Rechnungsprofil und dessen Geschäftsregeln.

Praxisbeispiel Österreich

Ein Wiener Beratungsunternehmen rechnet eine Leistung gegenüber einer Bundesdienststelle ab. Vereinbart sind 3 Prozent Skonto innerhalb von 7 Tagen. Im Erfassungsformular oder im ebInterface-Export werden Zahlungsbedingung, Frist und Prozentsatz in den dafür vorgesehenen Feldern hinterlegt. Zusätzlich bleibt das reguläre Zahlungsziel eindeutig.

Das Unternehmen prüft anschließend die Rückmeldung des Einbringungsportals. Denn die Annahme einer Datei und die kaufmännische Richtigkeit sind zwei verschiedene Dinge: Ein Portal kann eine formal gültige Rechnung weiterleiten, obwohl intern eine falsche Skontofrist aus den Stammdaten übernommen wurde.

Vom Vertrag bis zum Zahlungseingang: ein durchgängiger Datenfluss

Skontofehler entstehen selten erst im XML. Häufig beginnt das Problem schon im Angebot: Dort werden 2 Prozent innerhalb von 10 Tagen zugesagt, im Kundenstamm stehen jedoch noch 3 Prozent innerhalb von 14 Tagen. Übernimmt die Rechnungssoftware den älteren Wert, kann auch ein technisch perfekter Export kaufmännisch falsch sein.

KMU sollten deshalb eine eindeutige Reihenfolge festlegen. Zuerst kommt die gültige Vereinbarung aus Angebot, Auftrag oder Rahmenvertrag. Daraus werden Prozentsatz, Frist und gegebenenfalls Basisbetrag in die Rechnung übernommen. Erst danach ordnet der Export diese Informationen den Feldern des Zielformats zu. Ein Validator prüft die technischen Regeln; eine fachliche Freigabe prüft, ob die exportierten Werte wirklich zur Vereinbarung passen.

Nach dem Versand endet der Prozess noch nicht. Beim Zahlungseingang muss die Buchhaltung erkennen, ob der Kunde rechtzeitig und in korrekter Höhe gekürzt hat. Dafür braucht sie dieselben Ausgangsdaten wie die Rechnungserstellung: Rechnungsdatum, Beginn der Skontofrist, Skontosatz, Basisbetrag und endgültige Fälligkeit. Fehlt einer dieser Werte, lässt sich eine Differenz nicht zuverlässig als zulässiger Skontoabzug, Teilzahlung oder unbegründete Kürzung einordnen.

Ein schlanker Kontrollpunkt kann so aussehen:

Vertrieb bestätigt die vereinbarte Kondition im Auftrag.
Rechnungswesen prüft die vorbelegten Kundendaten vor der Freigabe.
Der Export bildet die Kondition formatspezifisch ab.
Ein Validator prüft XML und Profil.
Der Zahlungsabgleich verwendet dieselbe Frist- und Betragslogik.

Damit wird Skonto nicht zu einem isolierten Textbaustein, sondern zu einer kontrollierten Regel im gesamten Beleg- und Zahlungsprozess.

Der Basisbetrag ist die häufigste Rechenfalle

Ein Skontosatz allein reicht nicht. Unternehmen müssen festlegen, worauf er angewendet wird. Bei einem einfachen Gesamtbetrag ist das meist unstrittig. Komplexer wird es bei nicht skontierbaren Nebenkosten, Teilbeträgen, Anzahlungen oder vertraglich ausgenommenen Positionen.

Ein Beispiel: Die Rechnung weist 1.240 Euro fällig aus, aber nur 1.000 Euro sind skontierbar. Bei 2 Prozent beträgt der Nachlass 20 Euro und nicht 24,80 Euro. In XRechnung muss der abweichende Basisbetrag in der strukturierten Angabe mitgeführt werden. Auch in anderen Formaten muss die Berechnungsgrundlage eindeutig bleiben.

Diese Entscheidung sollte nicht erst beim XML-Export fallen. Sie gehört in Angebot, Auftrag oder Rahmenvertrag und in die Stammdaten des Kunden. Auf der öffentlichen Claribill-Seite zur Kundenverwaltung mit individuellen Zahlungsbedingungen ist beschrieben, wie Zahlungsziel, Skontoprozent und Skontofrist pro Kunde vorbelegt werden. Vor dem E-Rechnungsversand bleibt dennoch eine formatbezogene Prüfung notwendig.

Fünf typische Fehler und ihre Folgen

1. Skonto steht nur im PDF

Menschen sehen die Kondition, die Buchhaltungssoftware aber nicht. Automatischer Zahllauf und Rechnungsprüfung können dann vom sichtbaren Beleg abweichen.

2. BT-20 enthält eine frei erfundene Syntax

Die Rechnung kann technisch lesbar sein, ohne dass die Skontoangabe als strukturierte XRechnung-Konvention erkannt wird. Halten Sie sich exakt an Schreibweise, Reihenfolge und Dezimalformat.

3. Fälligkeit und Skontofrist werden verwechselt

Die Skontofrist beschreibt den Zeitraum für den Nachlass. Das endgültige Fälligkeitsdatum bestimmt, wann der ungekürzte Betrag zu zahlen ist. Beide Angaben sollten zueinander passen.

4. Veraltete Kundenkonditionen werden automatisch übernommen

Eine Vorbelegung spart Zeit, ist aber keine Freigabe. Prüfen Sie Vertragsänderungen, abweichende Aufträge und kundenspezifische Ausnahmen vor jeder Rechnung.

5. Ein Formatwechsel wird wie eine Dateikonvertierung behandelt

XRechnung, ZUGFeRD, Peppol BIS und ebInterface bilden Zahlungsbedingungen unterschiedlich ab. Eine syntaktische Konvertierung ohne fachliche Zuordnung kann Inhalte verlieren.

Checkliste vor dem Versand

Vereinbarung prüfen: Prozentsatz, Frist, Fristbeginn und Basisbetrag sind vertraglich eindeutig.
Kundendaten prüfen: Die aktuelle Kondition ist beim richtigen Rechnungsempfänger hinterlegt.
Zielformat bestimmen: XRechnung, ZUGFeRD-Profil, Peppol BIS oder österreichisches Format sind mit dem Empfänger abgestimmt.
Fälligkeit ergänzen: Das reguläre Zahlungsziel bleibt neben der Skontofrist verständlich.
Basisbetrag kontrollieren: Nicht skontierbare Positionen werden berücksichtigt.
PDF und XML vergleichen: Beide Darstellungen enthalten denselben kaufmännischen Inhalt.
Validieren: Die Datei wird gegen die aktuellen Regeln des konkreten Profils geprüft. Der Beitrag E-Rechnung validieren: Fehler vor dem Versand erkennen zeigt die wichtigsten Prüfschritte.
Rückmeldung archivieren: Annahme, Ablehnung und Korrektur des Übertragungswegs werden nachvollziehbar dokumentiert.

Zur Einordnung der Formate hilft außerdem der Vergleich XRechnung oder ZUGFeRD: Welches Format wann passt. Wie Skonto anschließend Umsatzsteuer und Zahlungsabgleich beeinflusst, erklärt der Beitrag Skonto richtig nutzen.

Kurze Antworten auf häufige Fragen

Ist Skonto eine Pflichtangabe auf jeder E-Rechnung?

Nein. Skonto ist eine vereinbarte Zahlungsbedingung, keine allgemeine Pflichtangabe jeder Rechnung. Wird Skonto angeboten, muss die Kondition jedoch eindeutig und im verwendeten Format korrekt abgebildet sein.

Reicht das Fälligkeitsdatum aus?

Nicht für einen Skontoabzug. Das Fälligkeitsdatum beschreibt den letzten Zahlungstermin für den regulären Betrag. Für Skonto werden zusätzlich mindestens Prozentsatz und Frist benötigt.

Kann dieselbe BT-20-Zeile in ZUGFeRD und ebInterface verwendet werden?

Nicht pauschal. Die definierte Skontozeile ist eine XRechnung-Konvention. Andere Formate und Profile haben eigene Datenmodelle und Validierungsregeln.

Muss ein österreichisches Unternehmen XRechnung beherrschen?

Bei Rechnungen an deutsche öffentliche Auftraggeber kann XRechnung vertraglich oder über den Einreichungsweg relevant sein. Für österreichische Bundesdienststellen gelten die dort zugelassenen Formate und Portale. Entscheidend ist immer die Vorgabe des konkreten Empfängers.

Fazit: Skonto muss für Mensch und Maschine identisch sein

Die kaufmännische Logik bleibt unabhängig vom Dateiformat gleich: Skontosatz, Frist, Fristbeginn und Basisbetrag müssen eindeutig sein. Technisch unterscheiden sich die Wege jedoch deutlich. XRechnung erwartet eine definierte BT-20-Syntax, ZUGFeRD hängt vom Profil und der XML-Abbildung ab, und Österreich nutzt eigene Strukturen beziehungsweise Peppol-Regeln.

Der wichtigste Praxisnutzen lautet daher: Zahlungsbedingungen einmal sauber vereinbaren und strukturiert pflegen, aber jeden Export im Zielformat validieren. So stimmen sichtbarer Beleg, XML-Daten, Empfängerprüfung und späterer Zahlungsabgleich überein.

Skonto in der E-Rechnung: Wo Frist und Prozentsatz hingehören