Geschäftsregeln der EN 16931: Woran Rechnungen wirklich scheitern

Die XML einer Rechnung kann formal tadellos sein und inhaltlich trotzdem falsch. Die Schemaprüfung kontrolliert, ob jedes Element dort steht, wo das Schema es erwartet, und den richtigen Datentyp hat; ob die Beträge aufgehen, ob eine Steuerbefreiung begründet ist oder ob der Rechnungssteller überhaupt identifizierbar ist, sagt sie nicht. Genau diese Lücke schließen die Geschäftsregeln.

Sie sind der Grund, aus dem die meisten abgelehnten Rechnungen abgelehnt werden. Eine Datei, die hier durchfällt, öffnet sich im PDF-Reader einwandfrei, lässt sich sauber als XML einlesen — und ist trotzdem keine gültige EN-16931-Rechnung.

Was eine Geschäftsregel ist

Jede Regel ist eine einzelne Aussage über den Inhalt einer Rechnung, formuliert in Schematron und gemeinsam mit der Norm veröffentlicht. Wo das Schema sagt „hier darf ein Element stehen“, sagt eine Geschäftsregel etwa: der Bruttogesamtbetrag muss dem Nettogesamtbetrag zuzüglich des Steuergesamtbetrags entsprechen. Rechnet man alle Steuerkategorien und Belegarten zusammen, kommen mehrere Hundert solcher Aussagen zusammen.

Die Regeln beziehen sich auf das semantische Modell, nicht auf das Dateiformat. Sie sprechen deshalb von Geschäftsbegriffen — BT-112 für den Bruttogesamtbetrag, BT-31 für die Umsatzsteuer-Identifikationsnummer des Verkäufers — und nicht von XML-Pfaden. Dieselbe Regel greift damit gleichermaßen für eine CII-Rechnung in einer ZUGFeRD-Datei wie für eine UBL-Rechnung über Peppol.

Die Regelfamilien

Das Präfix eines Regelcodes verrät, aus welchem Regelwerk er stammt — und das ist das Erste, was zu klären ist, denn nicht jedes Regelwerk gilt für jede Datei.

Nicht jede Regel gilt für Ihre Datei

An dieser Stelle werden Prüfberichte am häufigsten falsch gelesen, und es kostet echte Zeit.

Ein Beispiel, das auf jeder einzelnen Datei auftaucht: BR-DE-21 verlangt, dass die Spezifikationskennung (BT-24) eine XRechnung-Kennung ist. Ein ZUGFeRD- oder Factur-X-Dokument trägt dort definitionsgemäß eine ZUGFeRD-Kennung, die Regel kann also niemals erfüllt sein — und darf nie als Fehler gezählt werden. Unsere Prüfanzeige markiert sie als „für dieses Profil nicht anwendbar“ und rechnet sie aus der Fehlerzahl heraus, statt sie Anwender beunruhigen zu lassen.

Auch die Profile engen das Regelwerk ein. Eine Datei in MINIMUM oder BASIC WL trägt bewusst weniger Informationen, als die EN 16931 verlangt, und wird nicht am vollständigen Regelsatz gemessen. Was in welchem Profil steckt, behandelt Factur-X- und ZUGFeRD-Profile.

Die Fehler, die tatsächlich vorkommen

In der Praxis geht der Großteil der Ablehnungen auf wenige Regeln zurück. Das sind die, die am häufigsten auftauchen, wenn echte Rechnungen echter deutscher und französischer Absender durch einen Validator laufen.

Warum ein Cent eine Rechnung zu Fall bringt

Der mit Abstand häufigste Fehler ist ein Rechenfehler — und fast nie ein Fehler im Rechnen. Es ist uneinheitlich angewandte Rundung.

Werden Einzelpreise in voller Genauigkeit multipliziert, aufsummiert und erst dann gerundet, weicht die Summe gelegentlich um einen Cent von denselben, aber positionsweise gerundeten Zahlen ab. Buchhalterisch sind beide Wege vertretbar; nur einer stimmt mit dem überein, was die Regel nachrechnet. BR-CO-* ist gleichgültig, welche Konvention Sie gewählt haben — die Regel verlangt allein, dass die Zahlen innerhalb des Dokuments zueinander passen.

Drei Gewohnheiten verhindern fast alles davon:

• Einmal runden, an einer festgelegten Stelle, und jede Summe aus den gerundeten Werten bilden, nicht aus den rohen.
• Rundung auf Einzelpreis- und auf Positionsebene nicht mischen. Entscheiden Sie sich für einen Weg und wenden Sie ihn überall an.
• Die Summe niemals von Hand nachbessern, damit sie aufgeht. Das verschiebt die Abweichung nur — meist in die Steueraufschlüsselung.

Fehler und Hinweise sind nicht dasselbe

Ein Prüfbericht vermischt zwei Schweregrade, und sie zu verwechseln kostet in beide Richtungen Aufwand. Ein fataler Befund bedeutet: Das Dokument ist ungültig und wird abgelehnt. Ein Hinweis markiert etwas Ungewöhnliches, aber Zulässiges — ein empfohlenes, leer gelassenes Feld, einen erlaubten, aber selten genutzten Wert, oder eine Regel aus einer nationalen CIUS, die für Ihr Dokument gar nicht gilt.

Hinweise sind es wert, einmal gelesen zu werden, denn ein Empfänger kann mehr verlangen als die Norm. Sie auf null zu bringen lohnt sich nicht.

Die Ursache beheben, nicht die Datei

Schlägt eine Regel fehl, zeigt die Meldung auf ein Element in der XML. Die Versuchung ist groß, genau dieses Element zu ändern und erneut zu prüfen. Tun Sie es nicht: In einer hybriden Rechnung sollen die PDF-Seite und die eingebettete XML dasselbe aussagen, und eine von Hand nachbearbeitete XML passt nicht mehr zur Seite daneben. Dieser Widerspruch ist schlimmer als der ursprüngliche Fehler und später deutlich schwerer zu bemerken.

Korrigieren Sie die Daten in dem System, das die Rechnung erzeugt hat — die USt-IdNr. im Firmenprofil, die Rundungsstufe im Rechnungsprogramm, die fehlende Position — und erzeugen Sie das Dokument neu. Das vollständige Vorgehen steht in Rechnung prüfen: so geht es.

Gegen welches Regelwerk wurde Ihre Datei geprüft?

In einem einzigen Prüflauf treffen drei Versionsnummern aufeinander, und sie bezeichnen nicht dasselbe:

• Die Formatversion. Factur-X 1.09.2 / ZUGFeRD 2.5.2, veröffentlicht am 4. August 2026, anzuwenden ab dem 1. September 2026 — ein Corrigendum zur Fassung 2.5 vom Juni 2026, das Stimmigkeit, Rundung, Steueraufschlüsselung und Prüfregeln nachgezogen hat, vor allem im Profil EXTENDED.
• Die Version des Regelwerks. Die Schematron-Artefakte werden getrennt versioniert — EN 16931 Schematron v1.3.16 ist der Satz, der zur korrigierten Fassung 2.5.2 gehört.
• Die Version des Validators. Von beidem unabhängig. Mustang, der quelloffene Validator, auf dem der Großteil dieser Branche aufsetzt, steht bei 2.26.0.

Eine Klarstellung, die selten gemacht wird: Die semantische Norm selbst wurde überarbeitet. CEN hat EN 16931-1:2026 im Februar 2026 angenommen und im Mai 2026 veröffentlicht; die Fassung von 2017 wurde zurückgezogen. Die Werkzeuge sind noch nicht nachgezogen — die aktuellen Schematron-Sätze bilden weiterhin die Semantik von 2017 ab, und die Unterstützung der neuen Fassung wird mit dem für Herbst 2026 erwarteten Release gerechnet. Wer heute behauptet, gegen die Fassung 2026 zu prüfen, sollte gefragt werden, was genau damit gemeint ist.

Codeverzeichnis: die Regeln einzeln

Ab hier steht jede Regel für sich: was sie prüft, woran sie in der Praxis scheitert und was zu ändern ist. Jeder Eintrag hat einen eigenen Anker, #BR-CO-15 etwa führt direkt zur passenden Stelle — Sie können den Code aus Ihrem Prüfbericht an die Adresse dieser Seite hängen.

Die Beträge in den Beispielen stammen alle aus derselben Rechnung, damit sich die Rechenwege ineinanderstecken lassen:

Summen und Rundung

Diese Familie erzeugt die meisten Ablehnungen, und fast immer geht es um Centbeträge. Die Regeln bilden eine Kette: BT-106 → BT-109 → BT-110 → BT-112 → BT-115. Reißt ein Glied, melden die folgenden Regeln der Reihe nach ebenfalls Fehler — reparieren Sie immer das erste, nicht alle.

BR-CO-10 — Summe der Positionen

Summe der Nettobeträge der Rechnungspositionen (BT-106) = Σ Nettobetrag der Position (BT-131).

Im Beispiel muss BT-106 genau 747,00 + 120,50 = 867,50 lauten. Scheitert meist, weil der Positionsbetrag aus Menge × Einzelpreis auf mehr als zwei Nachkommastellen fällt und das Programm ihn erst in der Summe rundet: 3 × 82,99 ergibt 248,97, nicht 249,00. Runden Sie jede Position einzeln und summieren Sie danach — nie umgekehrt.

BR-CO-13 — Nettogesamtbetrag

Gesamtbetrag ohne Umsatzsteuer (BT-109) = Σ Nettobeträge der Positionen (BT-131) − Nachlässe auf Belegebene (BT-107) + Zuschläge auf Belegebene (BT-108).

867,50 − 17,50 + 0,00 = 850,00. Der häufigste Grund für einen Fehler: Ein Rabatt wurde bereits in den Positionspreisen berücksichtigt und zusätzlich als Nachlass auf Belegebene ausgewiesen — er zieht dann doppelt. Ein Nachlass gehört entweder in die Position oder auf die Belegebene, nicht in beide.

BR-CO-14 — Steuergesamtbetrag

Gesamtbetrag der Umsatzsteuer (BT-110) = Σ Steuerbetrag je Kategorie (BT-117).

Bei einem einzigen Satz ist das trivial. Fehler entstehen, sobald zwei Sätze zusammenkommen: 19 % und 7 % ergeben zwei Zeilen in der Steueraufschlüsselung, und BT-110 muss die Summe beider sein — nicht etwa der Betrag der größeren Zeile und nicht die Steuer auf die Gesamtsumme.

BR-CO-15 — Bruttogesamtbetrag

Gesamtbetrag mit Umsatzsteuer (BT-112) = Gesamtbetrag ohne Umsatzsteuer (BT-109) + Gesamtbetrag der Umsatzsteuer (BT-110).

850,00 + 161,50 = 1011,50. Das ist der Code, der in der Praxis am häufigsten auftaucht, und dahinter steckt fast nie ein Rechenfehler, sondern eine Rundung: Die Anwendung rechnet intern mit 849,995 € und schreibt 850,00 € in die XML, die Steuer aber aus dem ungerundeten Wert. Ein Cent Unterschied, und die Rechnung ist ungültig. Was in die XML geschrieben wird, muss auch die Grundlage der Rechnung sein.

BR-CO-16 — Fälliger Betrag

Fälliger Betrag (BT-115) = Gesamtbetrag mit Umsatzsteuer (BT-112) − bereits gezahlter Betrag (BT-113) + Rundungsbetrag (BT-114).

1011,50 − 200,00 = 811,50. Typischer Fehler bei Abschlagsrechnungen: Die Anzahlung steht im Freitext der Zahlungsbedingungen statt in BT-113, und der fällige Betrag passt dann rechnerisch zu nichts. Was der Empfänger überweisen soll, gehört in ein Feld, nicht in einen Satz.

BR-CO-17 — Steuerbetrag je Kategorie

Steuerbetrag je Kategorie (BT-117) = Bemessungsgrundlage (BT-116) × Satz (BT-119) / 100, auf zwei Nachkommastellen gerundet.

850,00 × 19 / 100 = 161,50. Die Rundung ist Teil der Regel — es gilt kaufmännisches Runden auf zwei Stellen, nicht Abschneiden. Wer 161,495 auf 161,49 kürzt, fällt durch.

BR-DEC-* — höchstens zwei Nachkommastellen

Beispiele: BR-DEC-12 für den Nettogesamtbetrag (BT-109), BR-DEC-14 für den Bruttogesamtbetrag (BT-112), BR-DEC-19 für die Bemessungsgrundlage (BT-116).

Über zwanzig Regeln dieser Familie sagen dasselbe über je ein anderes Geldfeld: mehr als zwei Nachkommastellen sind unzulässig. Ein 850.0000 aus einem Datenbankexport reicht bereits. Zu unterscheiden von den Mengen- und Preisfeldern, in denen mehr Stellen erlaubt sind — deshalb trifft es meist nur die Summenfelder.

Umsatzsteuer nach Kategorie

Jede Position trägt einen Steuerkategorie-Code, und für jeden dieser Codes existiert eine eigene Regelfamilie. Welche Familie Sie in Ihrem Bericht sehen, sagt Ihnen also bereits, mit welcher Kategorie ausgezeichnet wurde: S Regelsatz, Z Nullsatz, E steuerbefreit, AE Reverse-Charge, K innergemeinschaftliche Lieferung, G Ausfuhr, O nicht steuerbar.

BR-S-01 — Kategorie im Kopf fehlt

Enthält die Rechnung eine Position, einen Nachlass oder einen Zuschlag mit der Kategorie „Standard rated“, muss die Steueraufschlüsselung mindestens eine Zeile mit derselben Kategorie enthalten.

Die Position sagt „19 %“, aber die Steueraufschlüsselung im Rechnungskopf kennt diese Kategorie nicht. Entsteht regelmäßig beim nachträglichen Hinzufügen einer Position, wenn die Aufschlüsselung nicht neu berechnet wurde. Dieselbe Regel gibt es in jeder Familie: BR-Z-01, BR-E-01, BR-AE-01 und so fort.

BR-S-02 — Steuernummer fehlt bei Regelsatz

Enthält die Rechnung eine Position mit der Kategorie „Standard rated“, muss die Umsatzsteuer-Identifikationsnummer des Verkäufers (BT-31), seine Steuernummer (BT-32) und/oder die USt-IdNr. eines Steuervertreters (BT-63) vorhanden sein.

Wer Umsatzsteuer ausweist, muss sagen, unter welcher Nummer. Häufig bei Kleinunternehmern, die aus Versehen den Regelsatz statt der Kategorie E verwenden — die Rechnung ist dann nicht nur formal, sondern auch steuerlich falsch.

BR-S-08 — Bemessungsgrundlage je Satz

Für jeden Satz gilt: Bemessungsgrundlage (BT-116) = Σ Nettobeträge der Positionen mit diesem Satz + Zuschläge − Nachlässe mit diesem Satz.

Der klassische Fall mit zwei Sätzen: Ein Nachlass auf Belegebene wird vollständig der 19-%-Zeile zugeordnet, obwohl er sich anteilig auf 19 % und 7 % verteilen müsste. Ein Nachlass auf Belegebene trägt selbst eine Kategorie — sie muss gesetzt sein, und bei gemischten Sätzen braucht es eine Aufteilung.

BR-S-09 — Steuer je Satz

Der Steuerbetrag der Zeile (BT-117) muss der Bemessungsgrundlage (BT-116) multipliziert mit dem Satz (BT-119) entsprechen.

Fast dasselbe wie BR-CO-17, aber auf die einzelne Zeile bezogen. Sehen Sie beide, liegt der Fehler in derselben Zeile.

BR-Z-01 und BR-Z-08 — Nullsatz

Genau eine Zeile mit „Zero rated“, und deren Bemessungsgrundlage muss der Summe der Positionen mit Nullsatz entsprechen.

Nullsatz heißt: steuerbar, Satz 0 %. Nicht zu verwechseln mit steuerbefreit (E) und nicht mit „nicht steuerbar“ (O). Die Verwechslung ist der häufigste Grund, aus dem diese Familie überhaupt auftaucht.

BR-E-10 — Befreiung ohne Begründung

Eine Zeile mit „Exempt from VAT“ muss einen Befreiungsgrund tragen — als Code (BT-121) oder als Text (BT-120).

Sie dürfen steuerfrei abrechnen, aber Sie müssen dazuschreiben, warum. Ein leeres Feld genügt nicht, und ein Bindestrich ebenso wenig. Für Kleinunternehmer nach § 19 UStG gehört hier der entsprechende Hinweis hinein.

BR-AE-10 — Reverse-Charge ohne Hinweis

Eine Zeile mit „Reverse charge“ muss einen Befreiungsgrund tragen, der Reverse-Charge bedeutet — als Code (BT-121) oder als Text (BT-120).

Der Hinweis auf die Umkehr der Steuerschuldnerschaft ist keine Höflichkeit, sondern Pflichtangabe. Er darf in der Landessprache stehen, muss aber vorhanden sein. Fehlt zusätzlich die USt-IdNr. des Käufers, sehen Sie außerdem BR-AE-02 oder BR-AE-03.

BR-AE-08 und BR-E-08 — Bemessungsgrundlage bei 0 %

Auch ohne Steuer muss die Bemessungsgrundlage der Zeile der Summe der zugehörigen Positionen entsprechen.

Der Steuerbetrag ist hier 0,00 — die Bemessungsgrundlage ist es nicht. Wer beide Felder auf null setzt, fällt durch: Die Summe der Positionen steht unverändert in BT-116.

BR-IC-11 — innergemeinschaftliche Lieferung ohne Datum

Bei der Kategorie „Intra-community supply“ darf weder das tatsächliche Lieferdatum (BT-72) noch der Abrechnungszeitraum (BG-14) fehlen.

Bei der steuerfreien Lieferung ins EU-Ausland will der Empfänger wissen, wann geliefert wurde — das Rechnungsdatum reicht nicht. Eines der beiden Felder genügt.

BR-O-11 — „nicht steuerbar“ verträgt sich mit nichts

Enthält eine Rechnung eine Steuerzeile mit „Not subject to VAT“, darf sie keine weitere Steuerzeile enthalten.

Diese Kategorie schließt alle anderen aus: Eine Rechnung ist entweder vollständig nicht steuerbar oder gar nicht. Tritt auf, wenn eine durchlaufende Position — ausgelegte Gebühr, Auslage — mit O ausgezeichnet wird, während der Rest normal versteuert wird. Solche Posten gehören nicht in dieselbe Rechnung.

Pflichtangaben

Diese Regeln fangen Dateien ab, in denen schlicht etwas fehlt. Sie sind selten, wenn die Rechnung aus einem Programm kommt, und häufig, wenn die XML von Hand oder aus einer Vorlage entstanden ist.

BR-01 — Kennung des Regelwerks

Eine Rechnung muss eine Specification identifier (BT-24) tragen.

Das ist die Zeichenkette, die sagt, nach welchem Profil die Datei gebaut wurde — etwa urn:cen.eu:en16931:2017. Ohne sie weiß der Prüfer nicht, wogegen er prüfen soll, und der Empfänger nicht, was er bekommen hat. Fehlt praktisch nur in handgeschriebener XML.

BR-02 bis BR-05 — Nummer, Datum, Typ, Währung

Rechnungsnummer (BT-1), Rechnungsdatum (BT-2), Rechnungsart (BT-3) und Währung (BT-5) müssen vorhanden sein.

Vier getrennte Regeln für vier Felder, die alle im Kopf stehen. Die Rechnungsart ist ein Code aus UNTDID 1001 — 380 für die gewöhnliche Rechnung, 381 für die Gutschrift; ein freier Text an dieser Stelle löst zusätzlich eine BR-CL-*-Meldung aus.

BR-06 bis BR-09 — Verkäufer und Käufer

Name des Verkäufers (BT-27), Name des Käufers (BT-44), Postanschrift des Verkäufers (BG-5) und darin das Länderkennzeichen (BT-40).

BR-09 ist der häufigste der vier: Straße und Ort sind gefüllt, das Länderkennzeichen fehlt. Es muss ein zweibuchstabiger Code nach ISO 3166-1 sein — DE, nicht Deutschland.

BR-16 — keine einzige Position

Eine Rechnung muss mindestens eine Rechnungsposition (BG-25) enthalten.

Tritt auf, wenn die Rechnung nur aus Summen besteht — etwa bei einer aus einem PDF erzeugten Datei, in der die Positionstabelle nicht erkannt wurde. Eine Sammelposition über den Gesamtbetrag ist besser als keine.

BR-CO-09 — Länderpräfix der USt-IdNr.

Die USt-IdNr. des Verkäufers (BT-31), die des Steuervertreters (BT-63) und die des Käufers (BT-48) müssen mit einem Länderkennzeichen nach ISO 3166-1 alpha-2 beginnen. Griechenland darf zusätzlich EL verwenden.

Aus 123456789 wird DE123456789. Der weitaus häufigste Fall: Die Nummer steht ohne Präfix in den Stammdaten, weil sie dort seit Jahren so gepflegt wird. Leerzeichen und Punkte gehören ebenfalls nicht hinein.

BR-CO-26 — Verkäufer nicht identifizierbar

Damit der Käufer den Lieferanten automatisch zuordnen kann, muss die Kennung des Verkäufers (BT-29), seine Registernummer (BT-30) und/oder seine USt-IdNr. (BT-31) vorhanden sein.

Mindestens eines der drei Felder, nicht alle. Häufigster Auslöser bei konvertierten Fremdrechnungen: Im PDF steht die Steuernummer im Format 12/345/67890, und weil das keine USt-IdNr. ist, landet sie in keinem der drei Felder. Dann lieber die Registernummer füllen als das Feld leer lassen.

Deutsche Zusatzregeln (BR-DE-*)

Die BR-DE-*-Regeln stammen nicht aus der EN 16931 selbst, sondern aus der deutschen Ausprägung XRechnung. Sie fordern Angaben, die die Norm freistellt. Wichtig für die Einordnung: Eine ZUGFeRD-Rechnung, die kein XRechnung sein will, muss sie nicht erfüllen — der Prüfer meldet sie trotzdem, weil er alle ihm bekannten Regelwerke anlegt.

BR-DE-1 — keine Zahlungsangaben

Eine Rechnung muss Angaben zu „PAYMENT INSTRUCTIONS“ (BG-16) enthalten.

Ohne Zahlungsweg keine XRechnung. Bei Überweisung gehören IBAN und Zahlungsmittel-Code dazu; bei Lastschrift oder Barzahlung ist der jeweilige Code zu setzen.

BR-DE-2, BR-DE-5 bis BR-DE-7 — Ansprechpartner

Die Gruppe „SELLER CONTACT“ (BG-6) muss übermittelt werden, und darin Ansprechpartner (BT-41), Telefonnummer (BT-42) und E-Mail-Adresse (BT-43).

Vier Regeln, ein Block. Eine allgemeine Adresse wie rechnung@… genügt, ein Name der Abteilung ebenso — es muss nur ausgefüllt sein. Fehlt der Block ganz, sehen Sie alle vier Meldungen gleichzeitig.

BR-DE-14 — Steuersatz fehlt

Das Element „VAT category rate“ (BT-119) muss übermittelt werden.

Die EN 16931 erlaubt, den Satz bei bestimmten Kategorien wegzulassen; XRechnung nicht. Bei steuerfreien Positionen ist ausdrücklich 0 einzutragen, nicht nichts.

BR-DE-15 — Leitweg-ID fehlt

Das Element „Buyer reference“ (BT-10) muss übermittelt werden.

Im Geschäft mit der öffentlichen Hand ist das die Leitweg-ID: die Kennung, an der das Rechnungseingangsportal erkennt, an welche Stelle die Rechnung gehört. Sie steht in der Bestellung oder im Vertrag; erfinden lässt sie sich nicht, und ohne sie wird die Rechnung nicht zugestellt. Im rein privatwirtschaftlichen Verkehr genügt eine beliebige Referenz des Käufers.

BR-DE-16 — Steuerkennung bei bestimmten Codes

Werden die Steuercodes S, Z, E, AE, K, G, L oder M verwendet, muss mindestens eines der Elemente USt-IdNr. (BT-31), Steuernummer (BT-32) oder Steuervertreter (BG-11) übermittelt werden.

Die deutsche Verschärfung von BR-S-02: Sie gilt nicht nur beim Regelsatz, sondern bei praktisch jeder Kategorie.

BR-DE-17 — unzulässige Rechnungsart

Für „Invoice type code“ (BT-3) sind ausschließlich 326 (Teilrechnung), 380 (Rechnung), 384 (Rechnungskorrektur), 389 (Gutschriftsverfahren) und 381 (Gutschrift) zulässig.

Die UNTDID-Codeliste kennt Dutzende Werte; XRechnung lässt fünf davon zu. Wer eine Proformarechnung mit 325 auszeichnet, fällt hier durch.

BR-DE-18 — Skonto im falschen Format

Skonto muss im Element „Payment terms“ (BT-20) einem festen Muster folgen: #SKONTO#TAGE=n#PROZENT=n.nn#.

Die einzige Regel, die einem Freitextfeld eine Syntax vorschreibt. „2 % Skonto bei Zahlung innerhalb von 14 Tagen“ ist gut lesbar und trotzdem ungültig — der Empfänger soll das maschinell auswerten können.

BR-DE-19 — IBAN unplausibel

Ist als Zahlungsmittel SEPA-Überweisung (Code 58) angegeben, soll „Payment account identifier“ (BT-84) eine korrekte IBAN enthalten.

Geprüft werden Länge, Länderkennzeichen und Prüfziffer. Fällt in der Praxis meist über Leerzeichen: DE89 3704 0044 0532 0130 00 ist für Menschen richtig und für die Prüfung falsch — in die XML gehört die IBAN ohne Trennzeichen. BR-DE-20 sagt dasselbe über die Lastschrift (Code 59).

BR-DE-21 — die Meldung, die fast jeder sieht

Das Element „Specification identifier“ (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.

Diese Meldung erscheint auf jeder gültigen ZUGFeRD- und Factur-X-Rechnung, und sie ist dort kein Fehler. Sie sagt lediglich: „Das ist keine XRechnung.“ Das stimmt — und ist genau so gewollt, wenn Sie ZUGFeRD ausstellen. Rechnen Sie diese eine Meldung heraus, bevor Sie Ihren Bericht beurteilen; wir tun das in unserem Prüfbericht bereits für Sie.

BR-DE-26 — Korrektur ohne Bezug

Wird als Rechnungsart 384 (Rechnungskorrektur) übergeben, muss mindestens eine „PRECEDING INVOICE REFERENCE“ (BG-3) vorhanden sein.

Eine Korrektur ohne Angabe, was sie korrigiert, ist nicht zuzuordnen. Nummer und Datum der ursprünglichen Rechnung gehören in BG-3, nicht in den Freitext.

Den eigenen Bericht lesen

Am schnellsten versteht man eine Regel, wenn man sie an einer bekannten Datei auslösen sieht. Laden Sie eine Rechnung in unseren Validator — kostenlos und ohne Mengenbegrenzung, mit denselben hier beschriebenen Schematron-Sätzen, und jeder Befund kommt mit Regelcode, Schweregrad und Fundstelle zurück. Was auf jeder der drei Schichten passiert, beschreibt So funktioniert die Prüfung.