Woran Sie erkennen, dass es dieser Fall ist
- [BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden.
- [BR-CO-15] Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
- [BR-CO-10] Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
- [BR-DE-01] An invoice shall contain information on "PAYMENT INSTRUCTIONS" (BG-16).
- Validation failed: critical error
- XML document structures must start and end within the same entity.
- Die Spezifikationskennung wird nicht unterstützt.
Zugehörige Fehlercodes
- BR-DE-01
- BR-DE-15
- BR-CO-10
- BR-CO-15
- BR-S-08
- BR-01
- BR-02
Die schnelle Hilfe, in dieser Reihenfolge
Format oder Regel – was meldet der Validator?
Eine Meldung ohne Regelkennung („kein wohlgeformtes XML“, „Schema ungültig“, „unbekanntes Wurzelelement“) ist ein Formatfehler: Die Datei entspricht nicht der Syntax. Nach Rn. 6a des BMF-Schreibens ist sie dann keine E-Rechnung, sondern eine sonstige Rechnung. Eine Meldung mit Kennung (BR-…, BR-DE-…, BR-CO-…) ist ein Geschäftsregelfehler nach Rn. 6b.
Damit wissen Sie: Sie wissen, in welcher Klasse der Fehler liegt.
Bei Geschäftsregelfehlern: betrifft es eine Pflichtangabe des Umsatzsteuergesetzes?
Die Pflichtangaben sind Parteien, Steuernummer, Datum, Rechnungsnummer, Leistung, Leistungszeitpunkt, Entgelt je Satz, Steuerbetrag oder Befreiungsgrund. Fehlt davon etwas oder widersprechen sich Steuersatz und Steuerbetrag, ist es nach Rn. 35a ein Inhaltsfehler – die Rechnung ist nicht ordnungsgemäß. Fehlt die Käuferreferenz oder eine Bestellnummer, ist das zwischen Unternehmen umsatzsteuerlich unbeachtlich – das BMF nennt BT-10 ausdrücklich als Beispiel.
Damit wissen Sie: Sie wissen, ob die Rechnung zurück muss oder gebucht werden kann.
Die Spezifikationskennung prüfen
Der Validator prüft gegen eine Version der Regeln, die Datei nennt ihre Version in der Spezifikationskennung (BT-24). Passen beide nicht zusammen – alte Rechnung, neuer Validator oder umgekehrt –, erscheinen Fehler, die gar keine sind. Die Vertiefung zu XRechnung und ZUGFeRD nennt die aktuellen Versionen.
Damit wissen Sie: Sie wissen, ob die Fehler an der Datei oder an der Versionswahl liegen.
Summen nachrechnen
Die häufigsten echten Fehler sind Summenregeln: Positionen gegen Positionssumme (BR-CO-10), Netto plus Steuer gegen Brutto (BR-CO-15), Steuerbetrag gegen Satz mal Grundlage (BR-S-08 und verwandte). Ein Cent Rundungsdifferenz je Position ist zulässig, mehr nicht. Die E-Rechnungs-Vorprüfung rechnet das im Browser nach; der Befehl unten tut es in PowerShell.
Damit wissen Sie: Sie wissen, ob die Zahlen in sich stimmen.
Zurückweisen mit Angabe der Regel
Eine Rückweisung nennt die Regelkennung und das betroffene Feld – nicht „ungültig“. Der Aussteller kann dann gezielt korrigieren; seine Software zeigt dieselben Kennungen. Das Prüfprotokoll mit Datum und Validatorversion kommt zur Rechnung ins Archiv – als Beleg für die Verfahrensdokumentation.
Damit wissen Sie: Eine Rückweisung, die beim zweiten Mal nicht wiederkommt.
Dasselbe in PowerShell
Für alle, die mehr als einen Rechner betreuen
Die Befehle lesen die XML-Datei, prüfen, ob sie überhaupt wohlgeformt ist, zeigen die Profilkennung und rechnen die Summen nach – die drei Dinge, an denen Validierungen am häufigsten scheitern. Sie ersetzen keinen Validator; sie sagen, in welche Richtung man schauen muss.
PowerShell mit erweiterten Rechten starten – so geht es
- Windows 11
- Rechtsklick auf das Startsymbol – oder die Tastenkombination Windows + X – und dann Terminal (Administrator) wählen.
- Windows 10
- Dieselbe Tastenkombination, der Eintrag heißt dort Windows PowerShell (Administrator). Steht dort stattdessen die Eingabeaufforderung, lässt sich das in den Taskleisteneinstellungen umstellen – oder Sie nehmen den Weg darunter.
- Auf jedem Windows
- Startmenü öffnen, powershell tippen und den Treffer mit Strg + Umschalt + Eingabe öffnen. Das ist der Weg, der überall funktioniert.
- Woran Sie erkennen, dass es geklappt hat
- In der Titelleiste des Fensters steht Administrator, und die Eingabeaufforderung beginnt in C:\Windows\System32 statt in Ihrem Benutzerordner. Vorher bestätigen Sie die Abfrage der Benutzerkontensteuerung mit Ja.
- Wenn nach Zugangsdaten gefragt wird
- Dann sind Sie auf diesem Rechner kein Administrator. Im Firmennetz ist das der Regelfall und Absicht: Wer täglich mit erhöhten Rechten arbeitet, gibt einer Schadsoftware dieselben Rechte. Der richtige Weg ist die Zuarbeit durch die Administration – nicht das dauerhafte Hochstufen des eigenen Kontos.
Ein Hinweis, der wichtiger ist als er klingt: Führen Sie keinen Befehl aus, dessen Wirkung Sie nicht benennen können – auch keinen von uns. Die Blöcke unten sagen jeweils dazu, was sie tun; die, die etwas verändern, sind gekennzeichnet.
Ist die Datei wohlgeformtes XML – und welches Format?
Eine Datei, die sich nicht als XML laden lässt, ist nach dem BMF-Schreiben ein Formatfehler und damit keine E-Rechnung. Lädt sie, zeigt das Wurzelelement, ob es UBL (Invoice) oder CII (CrossIndustryInvoice) ist.
PS C:\> [xml]$x = Get-Content -Raw -Encoding UTF8 'C:\Rechnungen\eingang\rechnung.xml'PS C:\> $x.DocumentElement.LocalNameInvoice# Invoice oder CreditNote = UBL; CrossIndustryInvoice = CII; alles andere ist keine E-RechnungPS C:\> (Get-Content -Raw -Encoding Byte 'C:\Rechnungen\eingang\rechnung.xml' -TotalCount 3) -join ','239,187,191# Diese drei Bytes sind eine Byte-Order-Mark (BOM); manche Validatoren lehnen sie ab – Datei ohne BOM speichern lassenProfilkennung und Käuferreferenz
Die Profilkennung sagt, nach welcher Version der Regeln geprüft wird; eine veraltete Kennung erzeugt Fehler gegen aktuelle Regeln. Die Käuferreferenz ist der häufigste Einzelfehler – zwischen Unternehmen unbeachtlich, bei Behörden Pflicht.
PS C:\> $ns = @{ cbc = 'urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2' }PS C:\> Select-Xml -Xml $x -XPath '//cbc:CustomizationID' -Namespace $ns | ForEach-Object { $_.Node.InnerText }urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0# Für CII stattdessen: //*[local-name()='GuidelineSpecifiedDocumentContextParameter']/*[local-name()='ID']PS C:\> Select-Xml -Xml $x -XPath "//*[local-name()='BuyerReference']" | ForEach-Object { $_.Node.InnerText }# Leer bei einer Rechnung an eine Behörde: hier gehört die Leitweg-ID hineinSummen nachrechnen
Die Geschäftsregeln der EN 16931 verlangen, dass Positionssumme, Netto, Steuer und Brutto zusammenpassen. Ein Cent Abweichung durch Rundung je Position ist erlaubt; mehr ist ein kritischer Fehler.
PS C:\> $pos = (Select-Xml -Xml $x -XPath "//*[local-name()='InvoiceLine']/*[local-name()='LineExtensionAmount']" | ForEach-Object { [decimal]$_.Node.InnerText } | Measure-Object -Sum).SumPS C:\> $netto = [decimal](Select-Xml -Xml $x -XPath "//*[local-name()='LegalMonetaryTotal']/*[local-name()='TaxExclusiveAmount']").Node.InnerTextPS C:\> $steuer = [decimal](Select-Xml -Xml $x -XPath "//*[local-name()='TaxTotal']/*[local-name()='TaxAmount']").Node.InnerTextPS C:\> $brutto = [decimal](Select-Xml -Xml $x -XPath "//*[local-name()='LegalMonetaryTotal']/*[local-name()='TaxInclusiveAmount']").Node.InnerTextPS C:\> "Positionen $pos | Netto $netto | Steuer $steuer | Brutto $brutto | Netto+Steuer $($netto + $steuer)"Positionen 1250.00 | Netto 1250.00 | Steuer 237.50 | Brutto 1487.50 | Netto+Steuer 1487.50# Weicht Netto+Steuer vom Brutto ab oder die Positionssumme vom Netto: Geschäftsregelfehler, Berichtigung anfordernWarum meldet der Validator Fehler, die mein Buchhaltungsprogramm nicht sieht – oder umgekehrt?
Weil beide verschiedene Dinge prüfen. Ein Validator prüft gegen die Schematron-Regeln der Norm und der XRechnung – mehrere hundert Prüfungen, versioniert. Ein Buchhaltungsprogramm prüft, ob es die Datei importieren und buchen kann; dafür braucht es die Felder, die es verwendet, und ignoriert den Rest. Eine Datei kann also importierbar und zugleich regelwidrig sein, oder regelkonform und für ein bestimmtes Programm nicht lesbar.
Die Rangfolge ist klar: Die Regeln der Norm entscheiden, ob es eine E-Rechnung ist; das Programm entscheidet, ob Sie sie bequem verarbeiten können. Lehnt das Programm eine regelkonforme Datei ab, ist das ein Fall für dessen Hersteller, nicht für den Aussteller.
Und die zweite Unterscheidung, die das BMF trifft: Die Validierung ersetzt nicht die Prüfung durch den Empfänger. Ein falscher Steuersatz, der rechnerisch in sich stimmig ist, löst keine Regel aus – und macht die Rechnung trotzdem nicht ordnungsgemäß. Die sachliche und rechnerische Prüfung bleibt bei der Buchhaltung.
BR-DE-15, BR-DE-01 – die deutschen Zusatzregeln
Die Regeln mit „DE“ in der Kennung stammen aus der XRechnung, nicht aus der Norm. BR-DE-15 verlangt die Käuferreferenz, BR-DE-01 Zahlungsangaben, weitere Regeln die E-Mail-Adresse des Verkäufers, die Steuernummer, eine Kontaktperson. Sie gelten für Rechnungen an Behörden, die über die Portale eingereicht werden – dort führt jeder Verstoß zur Ablehnung.
Zwischen Unternehmen ist die Lage anders: Das Umsatzsteuergesetz verlangt weder Käuferreferenz noch Zahlungsangaben. Das BMF-Schreiben sagt in Rn. 35a, dass Geschäftsregelfehler zu anderen Inhalten als den umsatzsteuerlichen Pflichtangaben unbeachtlich sind, und nennt die Käuferreferenz als Beispiel. Eine Rechnung von Unternehmen zu Unternehmen mit BR-DE-15 ist also eine E-Rechnung und ordnungsgemäß – nur nicht behördentauglich.
Praktisch heißt das: Wer an Behörden liefert, füllt die DE-Felder immer; wer nur an Unternehmen liefert, kann sie füllen, muss aber nicht – und sollte Rückweisungen wegen BR-DE-Regeln von Unternehmenskunden freundlich einordnen.
Die Datei ist wohlgeformt, aber der Validator sagt „Schema ungültig“ – was ist passiert?
Dann stimmt die Struktur nicht mit dem XML-Schema der Syntax überein: ein Element an falscher Stelle, ein unbekanntes Element, ein Datum im falschen Format, eine Byte-Order-Mark am Dateianfang, die manche Prüfprogramme nicht ertragen. Das ist ein Formatfehler nach Rn. 6a – die Datei ist keine E-Rechnung, so plausibel ihr Inhalt wirkt.
Die Ursache liegt fast immer in der erzeugenden Software – eine veraltete Version, ein Export, der für eine andere Syntax gedacht war, oder eine nachträgliche Bearbeitung mit einem Texteditor. Die Datei nicht reparieren, sondern neu erzeugen lassen; eine von Hand geänderte Rechnungsdatei ist ein Beleg, den kein Prüfer anerkennt.
Im Betrieb
Die Validierung gehört an den Eingang – automatisch, mit Protokoll.
Im Betrieb wird nicht jede Rechnung von Hand validiert. Der Eingang prüft jede Datei automatisch, legt das Protokoll mit Datum und Validatorversion zur Rechnung und leitet nach Fehlerklasse weiter: Formatfehler zurück an den Lieferanten, unkritische Regelfehler mit Hinweis in die Freigabe, Fehler bei Pflichtangaben an die Buchhaltung mit der Bitte um Berichtigung. Genau diese Weiterleitung beschreibt die Vertiefung zur Prüfung und den Fehlerklassen.
Das Protokoll ist zugleich der Beleg, den die Verfahrensdokumentation braucht: dass die technische Prüfung stattgefunden hat, womit und mit welchem Ergebnis. Wir richten die Validierung so ein, dass das Protokoll mit der Datei archiviert wird – acht Jahre, unversehrt, wie die Rechnung selbst.
Wann Sie aufhören sollten zu probieren
Meldung einordnen, Summen nachrechnen, Versionen vergleichen – das kann die Buchhaltung mit dieser Seite und der Vorprüfung in einer Viertelstunde. Die Grenze liegt dort, wo dieselben Fehler bei jeder Rechnung eines Lieferanten oder bei jeder eigenen Ausgangsrechnung auftauchen: Dann ist es die Software, nicht die Datei – und die Frage, wer sie einstellt, ist ein Anruf wert.
Häufige Anschlussfragen
Darf ich eine Rechnung mit Warnungen buchen?
Warnungen sind Hinweise, keine Fehler; die Datei bleibt eine gültige E-Rechnung. Entscheidend ist, ob die Pflichtangaben des Umsatzsteuergesetzes vollständig und richtig sind – das prüft die Buchhaltung. Die Warnungen gehören ins Protokoll, mehr nicht.
Gibt es einen amtlichen Validator?
Die KoSIT stellt für die XRechnung ein Prüfwerkzeug mit den amtlichen Regeln bereit, und die Rechnungseingangsplattform des Bundes prüft jede eingereichte Rechnung automatisch. Für den Alltag zwischen Unternehmen reicht ein Validator, der die Regeln der EN 16931 und der XRechnung in der passenden Version kennt – die Vorprüfung in diesem Bereich ist ein erster Blick, keine amtliche Prüfung.
Der Fehler nennt ein Feld, das ich in meiner Software nicht finde – was tun?
Die Regelkennung und die Feldkennung (BT-Nummer) sind das Vokabular der Norm; Softwarehersteller benennen Felder anders. Die Dokumentation des Herstellers hat in der Regel eine Zuordnungstabelle; sonst der Support mit der Kennung. Fragen Sie nicht nach „der Fehlermeldung“, sondern nach „BT-10 in Version 3.0“ – das beantwortet der Hersteller sofort.
Muss ich jede eingehende Rechnung validieren?
Das Gesetz verlangt es nicht ausdrücklich; es verlangt, dass Sie die Rechnung auf Vollständigkeit und Richtigkeit prüfen. Die Validierung ist der schnellste Weg, den strukturierten Teil zu prüfen, und ihr Protokoll ist der Beleg dafür. Im eingerichteten Eingang läuft sie automatisch – dann ist die Frage erledigt.
Dazu passt