Validator-Update: Neues Regelwerk – warum dieselbe Rechnung jetzt anders bewertet werden kann

Neues Regelwerk: Dieselbe Rechnung, anderes Prüfergebnis

Seit dem 14.11.2026 prüft erechnungs-validator.de E-Rechnungen mit einer neuen Prüf-Engine und den aktuellen offiziellen Regelwerken. Das bringt schnellere Ergebnisse und klarere Meldungen – aber auch eine Folge, die viele überraschen wird: Eine Rechnung, die gestern noch als gültig galt, kann heute als ungültig gemeldet werden.

Das liegt nicht an einer Laune unseres Validators. Die Koordinierungsstelle für IT-Standards (KoSIT) und das europäische Normungsgremium haben ihre Prüfregeln verschärft. Wir prüfen jetzt nach genau diesem Stand – mit dem Werkzeug der KoSIT, das auch viele Rechnungsempfänger und Eingangsplattformen der öffentlichen Verwaltung einsetzen. In diesem Artikel erklären wir, was sich geändert hat, welche Regeln betroffen sind und wie Sie Ihre Rechnungen anpassen.

Das Wichtigste vorweg

  • Wir prüfen jetzt mit KoSIT-Validator 1.6.3 und der XRechnung-Konfiguration vom 31.08.2026 (EN-16931-Regeln Version 1.3.16).
  • ZUGFeRD- und Factur-X-PDFs prüfen wir mit Mustang 2.26 (ZUGFeRD 2.5) – also nach demselben Regelstand wie XRechnung.
  • Über 30 Prüfregeln führen jetzt zu „ungültig“, die vorher nur gewarnt haben oder gar nicht geprüft wurden.
  • Der häufigste neue Fehler: CII-SR-465/466 – ein Kontakt mit Ansprechpartner und Abteilung.
  • Eine Regel entfällt: BR-CO-25. Einige Rechnungen, die bisher abgelehnt wurden, sind jetzt gültig.
  • UBL-Rechnungen (XRechnung im UBL-Format) prüfen wir jetzt im Original statt nach einer Umwandlung.

Was wir technisch geändert haben

Neue Versionen der offiziellen Prüfwerkzeuge

Bausteinbisherjetzt
KoSIT-Validator (XRechnung, EN 16931)1.6.21.6.3
XRechnung-Konfiguration (Regeln und Stufen)04.02.202631.08.2026
EN-16931-Geschäftsregeln (CEN)1.3.15 (XML) bzw. 1.3.12 (PDF)1.3.16
Mustang (ZUGFeRD/Factur-X-PDF)2.20, ZUGFeRD 2.32.26, ZUGFeRD 2.5

Der KoSIT-Validator 1.6.3 schließt außerdem eine Sicherheitslücke der Vorversion. Die neue Konfiguration der KoSIT ändert an mehreren Stellen, wie streng eine Regel ist: Manche Warnungen sind jetzt Fehler.

UBL wird im Original geprüft

Bisher wurde eine XRechnung im UBL-Format vor der Prüfung in das andere XRechnung-Format (CII) umgewandelt. Dabei konnten Fehler verschwinden oder neu entstehen, und bei veralteten Rechnungen (z. B. XRechnung 2.1) brach die Prüfung mit einer irreführenden Meldung ab. Jetzt prüft der KoSIT-Validator die Rechnung genau so, wie Sie sie hochladen. Hat eine Rechnung eine veraltete oder fehlende Spezifikationskennung (BT-24), sagen wir das klar: „Kein Prüfszenario für diese Rechnungsart“.

Schneller

Die Prüf-Engines laufen jetzt dauerhaft im Hintergrund, statt für jede Prüfung neu zu starten. Eine XRechnung ist in rund 0,3 Sekunden geprüft, ein ZUGFeRD-PDF in unter einer Sekunde.

Welche Rechnungen jetzt ungültig werden

Strengere Regeln – und eine Lockerung

Die folgenden Regeln betreffen fast alle das CII-Format (UN/CEFACT) – also XRechnungen im CII-Format und ZUGFeRD-/Factur-X-PDFs, in denen eine CII-Datei steckt.

1. Kontakt mit Ansprechpartner und Abteilung (CII-SR-465, CII-SR-466)

CII-SR-465: Ansprechpartner und Abteilung im Kontakt

Im CII-Format bilden zwei Felder den Kontakt des Verkäufers ab: der Personenname (ram:PersonName) und die Abteilung (ram:DepartmentName). Beide stehen für dasselbe Geschäftsfeld BT-41 „Seller contact point“. Sind beide befüllt, enthält die Rechnung BT-41 zweimal – und das ist nicht erlaubt. Für den Käufer gilt dasselbe (BT-56, Regel CII-SR-466).

Vorher: Die Regel gab es seit den CEN-Regeln 1.3.15 nur als Warnung; die Rechnung war gültig.
Jetzt: Die KoSIT stuft sie als Fehler ein; die Rechnung wird abgelehnt.

So beheben Sie es: Befüllen Sie nur eines der beiden Felder. Wenn Sie Name und Abteilung angeben möchten, schreiben Sie beides in den Personennamen, z. B. „Erika Muster, Buchhaltung“. In vielen Rechnungsprogrammen heißen die Felder „Ansprechpartner“ und „Abteilung“ – hier ist meist der Hersteller gefragt.

2. Zahlungsangaben (CII-SR-467 bis CII-SR-470)

  • CII-SR-467: Alle Zahlungsblöcke müssen dieselbe Zahlungsart (BT-81) haben. Eine Rechnung darf nicht gleichzeitig Überweisung und Lastschrift anbieten.
  • CII-SR-468: Der Text zur Zahlungsart (BT-82) muss überall gleich sein.
  • CII-SR-469: Der Verwendungszweck (BT-83) darf nur einmal vorkommen.
  • CII-SR-470: Bei Überweisung (Code 30 oder 58) muss die IBAN oder eine Kontokennung angegeben sein. Die Regel ersetzt die frühere BR-CO-27 und prüft jetzt mit den richtigen Codes.

Vorher: CII-SR-467 bis 469 gab es nicht. Jetzt: Fehler.

3. Summenfelder nur einmal (CII-SR-477 bis CII-SR-494)

Im Summenblock einer CII-Rechnung (SpecifiedTradeSettlementHeaderMonetarySummation) darf jede Summe nur einmal stehen – etwa die Summe der Positionen (BT-106), der Nettobetrag (BT-109), der Bruttobetrag (BT-112) oder der Zahlbetrag (BT-115). Das XML-Schema lässt Wiederholungen technisch zu; die neuen Regeln verbieten sie ausdrücklich. Typische Ursache: Ein Programm schreibt eine Summe je Steuersatz oder je Währung.

Vorher: nicht geprüft. Jetzt: Fehler.

4. Zu- und Abschläge (CII-SR-463, CII-SR-471 bis CII-SR-473)

Jeder Zu- oder Abschlag (z. B. Rabatt, Fracht) darf nur einen Betrag, einen Steuersatz und einen Steuerblock haben und muss angeben, ob es ein Zu- oder Abschlag ist. Gilt ein Rabatt für mehrere Steuersätze, teilen Sie ihn in mehrere Abschläge auf. CII-SR-463 ist inhaltlich die frühere Regel BR-66 unter neuem Namen.

5. Externe Belege und Vergabenummer (BR-TMP-2, UBL-SR-56)

  • BR-TMP-2: Verweist die Rechnung auf einen externen Beleg (BT-124), muss das eine vollständige Adresse sein, z. B. https://…. Ein Dateiname oder relativer Pfad reicht nicht. Vorher Warnung, jetzt Fehler – auch für UBL.
  • UBL-SR-56: Eine UBL-Rechnung darf höchstens eine Vergabe- oder Losnummer (BT-17) enthalten. Neu.

6. ZUGFeRD- und Factur-X-PDFs

Für PDF-Rechnungen ist der Sprung am größten: Sie wurden bisher mit älteren Regeln (EN 16931 Version 1.3.12) geprüft. Jetzt gelten für die in der PDF enthaltene CII-Datei alle oben genannten Regeln – und zusätzlich:

  • BR-DEC-23: Der Nettobetrag einer Position (BT-131) darf höchstens zwei Nachkommastellen haben. Die Regel gab es schon, in der alten Regelversion prüfte sie aber an der falschen Stelle der Datei und schlug nie an. Der KoSIT-Validator hat sie bei XRechnungen schon immer korrekt geprüft – jetzt gilt das auch für PDFs.
  • CII-DT-101 bis CII-DT-104: Kennungen dürfen keine Zusatzattribute wie schemeName oder schemeURI tragen; erlaubt ist nur schemeID.

Die Meldungen tragen jetzt die bekannten Regelnummern (BR-…, CII-SR-…) statt der früheren ZUGFeRD-internen Nummern (FX-SCH-…).

Was jetzt nicht mehr abgelehnt wird

  • BR-CO-25 entfällt. Bisher galt: Ist ein Betrag zu zahlen, muss ein Fälligkeitsdatum (BT-9) oder eine Zahlungsbedingung (BT-20) angegeben sein. Diese Regel ist in den EN-16931-Regeln 1.3.16 nicht mehr enthalten.
  • CII-SR-475 und CII-SR-476 (eine Beschreibung bzw. eine Datei je Anhang) sind nur noch ein Hinweis. Die Regeln hatten einen Fehler und schlugen schon an, wenn eine Rechnung mehrere Anhänge hatte. Die XRechnung-Regeln BR-TMP-4 und BR-TMP-5 prüfen dasselbe jetzt richtig – als Warnung.

Neue Hinweise (Rechnung bleibt gültig)

  • CII-SR-464: Die Bank des Zahlungspflichtigen sollte nicht angegeben werden.
  • CII-SR-474: Je Position nur eine Objektkennung (BT-128).
  • BR-TMP-6 / BR-TMP-7: Datumsangaben im vorgeschriebenen Format (UBL: JJJJ-MM-TT, CII: format 102, JJJJMMTT).

winball.de+: unsere Zusatzprüfungen

Neben den offiziellen Regeln prüft winball.de+ weitere Punkte, die in der Praxis oft zu Rückfragen führen – etwa Prüfziffern von IBAN und GTIN, das Format von USt-IdNr. und BIC, Summenlogik oder Datumsangaben. Diese Befunde zeigen wir getrennt unter „winball.de+“ an, jeweils mit Erklärung und Lösungsvorschlag.

Als ungültig werten wir eine Rechnung wegen winball.de+ nur in wenigen, eindeutigen Fällen: wenn die IBAN eine falsche Prüfziffer hat (die Zahlung würde scheitern), wenn eine GLN eine falsche Prüfziffer hat oder wenn ein Datum nicht lesbar ist. Alles andere melden wir als Warnung – Ihre Rechnung bleibt dann gültig. Zur Kontrolle haben wir alle 86 offiziellen Beispielrechnungen der KoSIT geprüft: Keine wird durch winball.de+ ungültig.

Was Sie jetzt tun sollten

  1. Rechnungen erneut prüfen: Laden Sie eine aktuelle Rechnung aus Ihrem Programm im Validator hoch. Unser Assistent ValiBot erklärt jede neue Meldung mit Lösungsvorschlag.
  2. Häufigste Ursache zuerst: Prüfen Sie die Kontaktangaben von Verkäufer und Käufer (Name oder Abteilung).
  3. Hersteller ansprechen: Kommt die Rechnung aus einer Software, muss meist der Hersteller die Ausgabe anpassen. Die Regelnummer aus unserem Prüfbericht hilft ihm, die Stelle schnell zu finden.
  4. ZUGFeRD-PDFs nicht vergessen: Sie werden jetzt genauso streng geprüft wie XRechnungen.

Häufige Fragen

Meine Rechnung war gestern gültig. Ist sie jetzt falsch?
Nach dem aktuellen Regelstand: ja. Empfänger, die mit der aktuellen KoSIT-Konfiguration prüfen, lehnen solche Rechnungen ab. Wir zeigen Ihnen, welche Regel betroffen ist.

Warum prüft der Validator jetzt strenger als manche Empfänger?
Nicht jeder Empfänger aktualisiert sofort. Wir prüfen nach dem neuesten offiziellen Stand, damit Ihre Rechnungen auch morgen noch angenommen werden.

Hat sich an der Rechtslage etwas geändert?
Nein. Geändert haben sich die technischen Prüfregeln der Standards XRechnung und EN 16931. Dieser Artikel ist keine Steuer- oder Rechtsberatung.

Quellen

Verwandte Artikel

Subscribe
Subscribe
Warenkorb