Warum wird die Rechnung abgelehnt, obwohl das XML gültig ist?

Weil gültiges XML nur die erste von drei Prüfstufen ist. Syntax und Schema prüfen die Form, Geschäftsregeln prüfen den Inhalt. Eine Rechnung ohne Ansprechpartner beim Verkäufer ist formal fehlerfrei und trotzdem nicht konform.

Wo finde ich, was eine Regel-ID bedeutet?

In der Meldung selbst. Jede Schematron-Regel bringt einen Klartext mit, der das betroffene Feld in BT- oder BG-Notation nennt — etwa 'The group SELLER CONTACT (BG-6) shall be provided'. Diese Angabe ist präziser als jede Übersetzung davon.

Ist eine Warnung auch ein Fehler?

Nein. Eine als warning markierte Regel führt nicht zur Ablehnung. Nur fatal markierte Regeln tun das. Welche Regel welchen Schweregrad hat, legt das Regelwerk fest — und derselbe Sachverhalt kann in einem anderen Regelwerk härter gewichtet sein.

Meine Summen stimmen, trotzdem meldet BR-CO-10 einen Fehler.

Fast immer ein Rundungsproblem. Die Regel rechnet die Summe der Positionsbeträge gegen den ausgewiesenen Nettobetrag. Wer je Position auf zwei Nachkommastellen rundet und erst danach summiert, bekommt ein anderes Ergebnis als wer erst summiert und dann rundet.

Kann ich vor dem Versand prüfen?

Ja, und das ist der eigentliche Rat. Eine Prüfung vor dem Versand kostet Sekunden, eine Ablehnung kostet einen Zahlungslauf. Sie können eine Datei direkt auf dieser Seite prüfen, ohne Konto.

XRechnung abgelehnt: Die häufigsten Fehler und wie Sie sie finden

Die Fehlermeldung richtig lesen

Eine brauchbare Meldung nennt drei Dinge, und alle drei sind nützlich:

text

1[BR-DE-2] fatal
2The group "SELLER CONTACT" (BG-6) shall be provided.

Die Regel-ID (BR-DE-2) sagt, aus welchem Regelwerk der Verstoß stammt. Präfixe: BR- europäische Norm · BR-CO- Rechenregeln der Norm · BR-DE- und DE-R- deutsche Zusatzregeln · PEPPOL- Peppol-Regeln.
Der Schweregrad (fatal) sagt, ob die Rechnung deshalb zurückgewiesen wird.
Das Feld in BT/BG-Notation (BG-6) sagt, wo Sie suchen müssen.

🔴 Der häufigste Zeitfresser ist der dritte Punkt: Die Meldung spricht in BT-Nummern, Ihr System spricht in eigenen Feldnamen. Wer BT-10 in seinem ERP sucht, findet nichts; wer nach „Leitweg" sucht, findet es sofort.

Die Regeln, an denen es tatsächlich scheitert

BR-DE-2 — Ansprechpartner beim Verkäufer fehlt

Mit Abstand der häufigste Grund. Die deutsche CIUS verlangt eine Kontaktgruppe beim Verkäufer: Name und mindestens Telefon oder E-Mail. Viele Systeme führen diese Angaben in der Signatur des Rechnungsdokuments, nicht als Stammdatenfeld — und dann fehlen sie im XML.

json

1{
2  "seller": {
3    "name": "Muster GmbH",
4    "email": "info@muster.de",
5    "phone": "+49 30 12345678"
6  }
7}

DE-R-001 — Zahlungsangaben fehlen

Die Gruppe BG-16 ist Pflicht. Es genügt nicht, das Zahlungsziel im Fließtext zu nennen; es braucht ein strukturiertes Zahlungsmittel — in aller Regel IBAN und Überweisungscode.

BR-CO-10 — Positionssummen ergeben nicht den Nettobetrag

Rechnerisch fast immer eine Rundungsfrage. Die Regel summiert die Nettobeträge der Positionen und vergleicht sie mit dem ausgewiesenen Gesamtnetto.

🔵 Die Reihenfolge entscheidet: Runden Sie je Position auf zwei Nachkommastellen und summieren Sie danach. Wer die ungerundeten Werte summiert und erst das Ergebnis rundet, landet bei vielen Positionen regelmäßig einen Cent daneben — und ein Cent ist ein fatal.

BR-11 — Länderkennzeichen in der Käuferanschrift fehlt

Eine Regel der europäischen Norm. Sie greift überraschend oft bei Inlandskunden, weil das Länderkennzeichen im Stammsatz leer bleibt, solange niemand exportiert.

Skonto im falschen Format

Skonto ist in der XRechnung kein Freitext, sondern eine festgelegte Zeichenkette im Feld für Zahlungsbedingungen. Ein Satz wie „2 % Skonto bei Zahlung innerhalb von 10 Tagen" ist für einen Menschen eindeutig und für die Prüfung wertlos — die Angabe muss codiert vorliegen, sonst wird sie entweder abgelehnt oder ignoriert.

Leitweg-ID fehlt oder steht im falschen Feld

Bei Rechnungen an Behörden ist BT-10 Pflicht. Der typische Fehler ist nicht die fehlende ID, sondern die ID an der falschen Stelle: im Verwendungszweck, in der Bestellnummer oder in einem Freitextfeld.

Vorgehen, wenn eine Rechnung zurückkommt

1. Erst den Schweregrad prüfen. Steht in der Antwort nur warning, ist die Rechnung nicht deswegen abgelehnt worden. Dann liegt die Ursache woanders — oft beim Empfänger, nicht am Dokument.

2. Die Regel-ID nachschlagen, nicht die Meldung interpretieren. Der Klartext einer Regel ist bewusst knapp gehalten. Die Regel selbst nennt den genauen Ausdruck, der geprüft wurde, und damit die Stelle im Dokument.

3. Am Original prüfen, nicht am erzeugten PDF. Bei ZUGFeRD entscheidet die eingebettete XML-Datei, nicht das sichtbare Dokument. Beide können auseinanderlaufen, und die Prüfung sieht nur eine davon.

4. Nach der Korrektur erneut prüfen. Regelverstöße treten selten allein auf. Ein fehlender Kontaktblock zieht häufig eine zweite Meldung nach sich, die erst sichtbar wird, wenn die erste behoben ist.

Der wirksamste Schritt kommt vorher

Alle genannten Fehler haben eines gemeinsam: Sie sind vor dem Versand erkennbar. Keiner davon erfordert Wissen über den Empfänger, keiner hängt von dessen System ab — es sind Regeln, die auf dem Dokument selbst arbeiten.

Eine Prüfung im Erzeugungsprozess kostet einen Aufruf. Eine Ablehnung kostet einen Zahlungslauf und die Zeit, in der niemand weiß, warum das Geld ausbleibt.