Prüfen Sie bei einer XRechnung mit Skonto nicht nur die sichtbare Rechnung, sondern den tatsächlich versandten XML-Export. Für XRechnung 3.0 gehört die strukturierte Skontoangabe in BT-20 nach BR-DE-18. Vergleichen Sie anschließend die exportierten Konditionen mit der Vereinbarung und validieren Sie die vollständige Datei. Ein grünes Prüfergebnis bestätigt nicht, dass der Kunde den richtigen Nachlass vereinbart hat.
Er richtet sich an Selbstständige und kleine Unternehmen, deren Rechnungsprogramm eine Skontobedingung anzeigt, der XML-Export aber unklar ist oder eine Fehlermeldung auslöst. Die Berechnung und Buchung von Skonto einschließlich Teilzahlungen ist ein anderer Arbeitsschritt. Hier kontrollieren Sie die Übertragung vor dem Versand, nicht den späteren Zahlungseingang.
Stand Oktober 2026: XRechnung 3.0 nicht mit 4.0 vermischen
Recherche- und Quellenstand: 8. Oktober 2026. Die KoSIT-Übersicht zu Versionen und Bundles nennt XRechnung 3.0 als weiterhin aktive Version, mindestens bis zum 31. Juli 2027. Dort ist das technische Bundle 3.0.2 Summer 2026 Bugfix vom 31. August 2026 aufgeführt. Spezifikation und technische Prüfkonfiguration sind unterschiedliche Bestandteile: Notieren Sie deshalb nicht nur „XRechnung“, sondern auch den verwendeten Export und die Validator-Konfiguration.
Die am 15. September 2026 veröffentlichte Vorversion XRechnung 4.0 ist laut KoSIT noch nicht für den produktiven Einsatz vorgesehen. Sie sieht für Skonto die neue Gruppe BG-35 vor. Das ist kein Anlass, einen laufenden 3.0-Export eigenständig umzubauen. Klären Sie mit Anbieter und Rechnungsempfänger, welches produktive Profil Sie benötigen; eine angekündigte Funktion ist noch kein funktionierender Versandweg.
Erst die vereinbarte Kondition, dann die XML-Darstellung
Legen Sie für den Test eine kleine Vergleichsliste an: Skontosatz, Frist, Fristbeginn, Bezugsbetrag und reguläres Zahlungsziel. Verwenden Sie die tatsächlich mit diesem Kunden vereinbarte Kondition. Ein voreingestellter Text aus dem Kundenstamm kann von einem einzelnen Auftrag abweichen. Prüfen Sie deshalb den Rechnungsentwurf nach der Übernahme aus dem Angebot nochmals.
Halten Sie drei Ansichten nebeneinander: die vereinbarten Bedingungen, die Anzeige im Rechnungsprogramm und die Zahlungsbedingungen aus der exportierten Datei. Stimmen nur die ersten beiden überein, ist der Test noch offen. Stimmen Anzeige und Export überein, aber beide enthalten die falsche Kundenvorlage, liegt kein reiner XML-Fehler vor. Diese Trennung spart eine Supportanfrage an der falschen Stelle.
BT-20 ist der fachliche Bezeichner für Zahlungsbedingungen, nicht der Name eines identischen XML-Tags in jedem Format. Die offizielle KoSIT-FAQ erklärt die strukturierte Skontoangabe in diesem Feld und lässt zusätzlich unstrukturierten Text zu Zahlungsbedingungen zu. Lassen Sie sich im Zweifel von Ihrem Anbieter zeigen, wo BT-20 im konkreten Export dargestellt wird. Suchen Sie nicht ausschließlich nach einem wörtlichen Tag „BT-20“.
BR-DE-18: das Textmuster innerhalb von BT-20
Die Spezifikation 3.0.2, BR-DE-18 auf Druckseite 81, beschreibt dieses Muster: SKONTO, TAGE und PROZENT stehen in dieser Reihenfolge; Prozentwerte haben einen Punkt und zwei Nachkommastellen. Die Segmente sind durch Rauten getrennt, mit abschließender Raute. Nach der vollständigen Angabe folgt ein XML-konformer Zeilenumbruch. Schlüsselwörter sind großgeschrieben; zusätzliche Leerzeichen innerhalb der Skontoangabe passen nicht zum Muster.
Eigenes Textbeispiel: Für eine vereinbarte Frist von 14 Tagen und 2 Prozent auf den gesamten fälligen Betrag sieht der BT-20-Ausschnitt so aus. Die Zahlen sind frei gewählte Testdaten, keine Empfehlung für eine übliche Kondition.
#SKONTO#TAGE=14#PROZENT=2.00#
Die Beispielwerte enden jeweils mit einem Zeilenumbruch nach der letzten Raute. Ein automatischer Umbruch eines schmalen Anzeigefensters ersetzt dieses Zeichen nicht. Ein Screenshot kann den Unterschied nicht zuverlässig zeigen; prüfen Sie den gespeicherten Feldwert oder bitten Sie den Anbieter um dessen technische Darstellung.
Wenn nur ein Teil des fälligen Betrags BT-115 die Skontobasis bildet, ergänzt BR-DE-18 das vierte Segment BASISBETRAG. Eigenes Beispiel mit 600,00 Euro Bezugsbetrag:
#SKONTO#TAGE=14#PROZENT=2.00#BASISBETRAG=600.00#
600,00 Euro ist hier der Betrag, auf den der Nachlass angewendet werden soll, nicht der bereits verminderte Zahlbetrag. Klären Sie die vereinbarte Basis vor dem Export. Beide Beispiele zeigen ausschließlich einen Textwert, keine vollständige UBL- oder CII-Rechnung. Sie sind daher weder ein Beleg für die Validität einer gesamten Rechnung noch eine Anleitung, produktive XML-Dateien von Hand zu ändern.
Was Sie bei BR-DE-18 zuerst untersuchen sollten
Beginnen Sie mit dem tatsächlichen Bericht des Validators. Halten Sie Regelkennung, Meldung, Datei und Prüfkonfiguration fest. Die folgende Tabelle enthält eigene Diagnosefälle. Sie beschreibt Suchrichtungen, nicht einen garantierten Fehlertext jedes Programms.
| Beobachtung | Nächster Prüfschritt | Sinnvolle Korrekturstelle |
|---|---|---|
| BeobachtungIm Export steht PROZENT=2,00 | Nächster PrüfschrittUnterscheiden Sie deutsche Anzeigeformatierung und gespeicherten Textwert. | Sinnvolle KorrekturstelleExportformatierung des Anbieters, nicht den vereinbarten Satz ändern |
| BeobachtungDer Satz erscheint als 2 statt 2.00 | Nächster PrüfschrittPrüfen Sie, ob die Oberfläche nur eine gekürzte Anzeige zeigt oder der Export denselben Wert enthält. | Sinnvolle KorrekturstelleErzeugung des BT-20-Textes prüfen lassen |
| BeobachtungEine kopierte Vorlage enthält Leerzeichen oder eine fehlende Raute | Nächster PrüfschrittVergleichen Sie den vollständigen Text mit dem Muster und exportieren Sie aus einem frischen Entwurf. | Sinnvolle KorrekturstelleVorlage beziehungsweise Skontoeinstellung korrigieren |
| BeobachtungDie letzte Raute ist sichtbar, der Fehler bleibt | Nächster PrüfschrittPrüfen Sie den tatsächlichen Zeilenumbruch und die verwendete Prüfkonfiguration. | Sinnvolle KorrekturstelleFeldwert und Validator-Bericht gemeinsam an den Support geben |
| BeobachtungValidierung erfolgreich, Bezugsbetrag trotzdem falsch | Nächster PrüfschrittVergleichen Sie den Export mit der auftragsbezogenen Vereinbarung. | Sinnvolle KorrekturstelleKondition oder Datenübernahme korrigieren, nicht den Validator ausschalten |
Eine Meldung ohne BR-DE-18 kann einen ganz anderen Teil der Datei betreffen. Löschen Sie deshalb nicht versuchsweise alle Zahlungsbedingungen, bis die Anzeige grün wird. Wenn die Diagnose unklar bleibt, bitten Sie den Anbieter um eine konkrete Erklärung zur Regelkennung. „Unsere PDF sieht richtig aus“ beantwortet die Exportfrage nicht.
Ein sicherer Prüfablauf vor dem Versand
- Entwurf festlegen: Notieren Sie die erwarteten Konditionen und wählen Sie das mit dem Empfänger abgestimmte XRechnung-Profil. Arbeiten Sie zunächst mit Testdaten ohne echte Kundeninformationen.
- Genau den Versandexport erzeugen: Exportieren Sie über denselben Weg, den Sie später verwenden. Eine zusätzliche PDF-Vorschau ist nicht die XML-Datei, die das Kundenportal verarbeitet.
- Lesbar darstellen: Kontrollieren Sie Zahlungsbedingungen und Bezugsbetrag. Der Leitfaden zum Öffnen und Prüfen einer XRechnung trennt Darstellung, fachlichen Abgleich und Validierung.
- Vollständige Datei validieren: Verwenden Sie die zum Zielprofil passende, dokumentierte Konfiguration. Ein Prüfer nur für den einzelnen Textwert kann Fehler im übrigen Beleg nicht erkennen.
- Ursache im Ursprung korrigieren: Ändern Sie Kondition, Vorlage oder Exportfunktion im Rechnungsprogramm. Erzeugen Sie danach eine neue Datei und wiederholen Sie denselben Test.
- Freigabe nachvollziehbar festhalten: Bewahren Sie die geprüfte Exportversion und den zugehörigen Bericht zusammen mit Ihrer internen Freigabe auf. Der ergänzende Ablauf zum Archivieren von XML und lesbarer Rechnung hilft bei der späteren Zuordnung.
Die KoSIT-FAQ weist darauf hin, dass geänderte europäische Prüfkomponenten bei einer neuen Konfiguration zu anderen Ergebnissen führen können. Wiederholen Sie einen fehlgeschlagenen Test deshalb nicht mit einem absichtlich veralteten Prüfer, um eine Erfolgsmeldung zu erhalten. Dokumentieren Sie vielmehr, welche Konfiguration der Empfänger verlangt und welche Ihr Anbieter unterstützt.
Für eine Supportanfrage reichen zunächst anonymisierte Testdatei, Bericht, Programmversion, Exportprofil und die erwarteten Zahlungsbedingungen. Senden Sie vertrauliche echte Rechnungen nicht ohne Prüfung der Freigabe und des Übertragungswegs an ein beliebiges Online-Testangebot. Dieser organisatorische Hinweis ist keine Behauptung über die Sicherheit eines bestimmten Validators.
So testen Sie Rechnungssoftware für Ihren Skontofall
Eine Funktionsliste mit dem Wort „Skonto“ genügt für die Auswahl nicht. Bitten Sie den Anbieter um einen exportierten Musterbeleg für Ihren Ablauf und den dazugehörigen Prüfbericht. Der folgende Abnahmetest ist eine eigene Empfehlung; es werden keine ungetesteten Funktionen eines Produkts versprochen.
- Fall A – ganze Basis: Ein Entwurf mit der frei gewählten Testkondition 14 Tage und 2 Prozent. Stimmen Einstellung, Anzeige und Export überein?
- Fall B – eingeschränkte Basis: Ein Test mit nur 600,00 Euro skontofähigem Betrag. Kann das Programm diese Bedingung tatsächlich abbilden, oder braucht Ihr Vorgang einen anderen unterstützten Ablauf?
- Fall C – kein Skonto vereinbart: Kontrollieren Sie einen separaten Entwurf ohne Nachlass. Werden ungewollte Bedingungen aus dem Kundenstamm oder einer Vorlage übernommen?
- Fall D – Vorlage geändert: Ändern Sie die Kondition im Testentwurf und exportieren Sie neu. Prüfen Sie, ob noch alte Werte im XML stehen.
- Fall E – Empfängertest: Nutzen Sie einen ausdrücklich vorgesehenen Testweg des Empfängers, sofern vorhanden. Eine lokale Freigabe ersetzt nicht den tatsächlichen Annahmeprozess.
Protokollieren Sie je Fall die Eingabe, den Dateinamen, die gefundene Kondition und das Ergebnis. Fragen Sie bei Einschränkungen nach einer schriftlichen Beschreibung des unterstützten Falls. Ein manuell bearbeitetes Muster sagt wenig darüber aus, ob der reguläre Export im Alltag dieselben Daten erzeugt.
Was der technische Test nicht entscheidet
Ein vorhandener Skontotext bedeutet nicht, dass jede Rechnung einen Nachlass enthalten muss. Entscheidend bleibt Ihr Geschäftsvorgang. Auch der Eintrag TAGE=14 klärt für Ihren Abgleich allein nicht alle vertraglichen Fragen: Welches Ereignis startet die Frist, gilt die Bedingung für alle Positionen und welche Zahlung muss rechtzeitig vorliegen? Lösen Sie solche Unklarheiten nicht durch das Austauschen einer Zahl im Export.
Übertragen Sie das hier behandelte XRechnung-3.0-Muster außerdem nicht pauschal auf jedes ZUGFeRD-Profil oder eine künftige Version. Ein anderer Exportweg benötigt seine eigene Prüfung. Zeigt ein empfangener Beleg widersprüchliche Konditionen, wählen Sie nicht eigenmächtig den günstigeren Betrag. Für den weiteren Ablauf hilft der Leitfaden zum Prüfen und Klären einer fehlerhaften E-Rechnung.
Eine bereits verschickte Rechnung ist kein beliebiger Testentwurf. Stimmen Sie eine erforderliche Korrektur und erneute Übermittlung mit dem zuständigen Bearbeiter ab, damit nicht zwei verschiedene Dateien unter derselben Zuordnung ungeklärt nebeneinander stehen. Dieser Leitfaden bewertet keine individuelle Vertrags- oder Steuerfrage.
Nächster Schritt: eine Kondition vollständig durchtesten
Wählen Sie einen anonymisierten Musterauftrag mit einer eindeutig festgelegten Skontobedingung. Lassen Sie Ihr Rechnungsprogramm die XRechnung erzeugen und vergleichen Sie die drei Ansichten. Klären Sie jede Abweichung im Ursprung, bevor Sie den Versand freigeben. Danach ergänzen Sie genau die Sonderfälle, die Ihr Betrieb tatsächlich benötigt, etwa eine eingeschränkte Bezugsbasis. So entsteht ein wiederholbarer Exporttest statt einer Sammlung unkontrollierter Textvorlagen.
Häufige Fragen
Reicht ein richtiger Skontohinweis in der PDF-Vorschau?
Nein. Prüfen Sie die tatsächlich versandte XML-Datei und vergleichen Sie deren Zahlungsbedingungen mit der Vereinbarung. Eine Vorschau kann richtig aussehen, während der separate Export andere Werte enthält.
Darf BT-20 auch normalen Text zu Zahlungsbedingungen enthalten?
Ja. Die KoSIT-FAQ erlaubt strukturierten Skontotext und zusätzlichen unstrukturierten Text in BT-20. Innerhalb der strukturierten Skontoangabe ist das Muster von BR-DE-18 einzuhalten.
Muss ich eine fehlerhafte XML-Datei von Hand reparieren?
Korrigieren Sie vorzugsweise die Einstellung, Vorlage oder Exportfunktion im Rechnungsprogramm und erzeugen Sie die Datei neu. Eine Handkorrektur löst die Ursache im wiederkehrenden Export nicht.
Soll ich im Oktober 2026 schon auf XRechnung 4.0 umstellen?
Nicht allein aufgrund der veröffentlichten Vorversion. KoSIT bezeichnet diese ausdrücklich als noch nicht für den produktiven Einsatz vorgesehen. Klären Sie das unterstützte produktive Profil mit Anbieter und Empfänger.
Quellen und Aktualität
Primärquellen geprüft am 8. Oktober 2026. Dieser Beitrag behandelt den XML-Export für XRechnung 3.0; Beispiele und Abnahmetest sind eigene Muster, keine validierten vollständigen Rechnungsdateien und keine Produkttests. Keine individuelle Rechts- oder Steuerberatung. Das generativ erstellte Titelbild zeigt eine fiktive Oberfläche, keine echte Software.