Was ist KoSIT-Validierung?
Die Koordinierungsstelle für IT-Standards (KoSIT) stellt den offiziellen Validator für XRechnung-Dokumente bereit. Dieser Validator prüft jede eingereichte elektronische Rechnung in zwei Schritten: Zuerst gegen das UBL-2.1-XML-Schema (syntaktische Wohlgeformtheit), dann gegen einen umfangreichen Satz Schematron-Regeln, der die Geschäftsregeln der EN 16931 sowie die deutschen Erweiterungen (BR-DE-*) umsetzt.
Schematron-Regeln sind in Schweregrade eingeteilt: Fatale Fehler (FATAL/Critical) führen im KoSIT-Validator zur Empfehlung „reject“, die Rechnung wird abgelehnt. Warnungen (WARNING) betreffen Soll-Regeln; der Validator empfiehlt die Rechnung trotzdem zur Annahme. Die häufigsten Fehlerquellen sind fehlerhafte Berechnungen, fehlende Pflichtfelder gemäß der deutschen Erweiterungsspezifikation, ungültige Code-Werte und falsch formatierte Datumsangaben.
Diese Referenz deckt alle wesentlichen Fehlercodes ab — von strukturellen XML-Fehlern über Kernregeln der EN 16931 (BR-1, BR-6, BR-CO-*) bis hin zu den deutschen Erweiterungsregeln (BR-DE-1 bis BR-DE-31) und umsatzsteuerspezifischen Regeln (BR-S-*, BR-E-*, BR-Z-*, BR-AE-*).
Schweregradstufen
Die Rechnung wird abgelehnt. Der Fehler muss behoben werden, bevor die Einreichung erneut versucht wird.
WarningEine Soll-Regel. Der KoSIT-Validator empfiehlt die Rechnung trotzdem zur Annahme; beheben sollten Sie die Abweichung dennoch.
Fehlerdatenbank
Wählen Sie einen Fehlercode für detaillierte Behebungsanweisungen.
Zahlungsanweisungen fehlen (BG-16)
BR-DE-1 ist eine Regel der deutschen CIUS XRechnung: Jede Rechnung muss die Gruppe PAYMENT INSTRUCTIONS (BG-16) enthalten. In UBL ist das cac:PaymentMeans, in CII ram:SpecifiedTradeSettlementPaymentMeans. Die EN 16931 behandelt BG-16 als optional. Eine Datei, die eine reine EN-16931-Prüfung besteht, kann hier also trotzdem scheitern. Die Regel ist fatal. Der KoSIT-Validator meldet sie mit dem Text „Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten.“ und empfiehlt die Ablehnung.
Verkäuferkontakt fehlt (BG-6)
XRechnung verlangt die Gruppe SELLER CONTACT (BG-6). In UBL ist das cac:AccountingSupplierParty/cac:Party/cac:Contact, in CII ram:SellerTradeParty/ram:DefinedTradeContact. Die EN 16931 behandelt die Gruppe als optional. XRechnung macht sie zur Pflicht und verlangt über BR-DE-5, BR-DE-6 und BR-DE-7 auch ihre drei Felder: Ansprechpartner (BT-41), Telefonnummer (BT-42) und E-Mail-Adresse (BT-43). Die Regel ist fatal. KoSIT-Meldung: „Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden.“
Ort des Verkäufers fehlt (BT-37)
Die Postanschrift des Verkäufers (BG-5) muss den Ort (BT-37) enthalten. Die EN 16931 verlangt in einer Anschrift nur den Ländercode (BR-09); XRechnung ergänzt mit BR-DE-3 den Ort und mit BR-DE-4 die Postleitzahl. Für den Käufer gilt dasselbe (BR-DE-8, BR-DE-9). Die Regel ist fatal und schlägt auch an, wenn cbc:CityName vorhanden, aber leer ist.
Postleitzahl des Verkäufers fehlt (BT-38)
Die Postanschrift des Verkäufers (BG-5) muss die Postleitzahl (BT-38) enthalten. Das ist eine Ergänzung der XRechnung zur EN 16931. Die Regel ist fatal. Häufige Ursache ist ein zusammengesetzter Wert wie „10115 Berlin“ im Ortsfeld, während cbc:PostalZone leer bleibt.
Ansprechpartner des Verkäufers fehlt (BT-41)
Ist die Gruppe SELLER CONTACT (BG-6) vorhanden, muss sie den Ansprechpartner BT-41 enthalten: den Namen einer Person oder einer Abteilung. In XRechnung 3.0.x ist das eine fatale Regel, keine Warnung. Fehlt die ganze Gruppe, meldet der Validator stattdessen BR-DE-2.
Käuferreferenz fehlt (BT-10)
BR-DE-15 verlangt in jeder XRechnung das Element Buyer reference (BT-10), und es darf nicht leer sein. In UBL ist das cbc:BuyerReference direkt unter dem Wurzelelement, in CII ram:ApplicableHeaderTradeAgreement/ram:BuyerReference. Bei öffentlichen Auftraggebern steht dort die Leitweg-ID, bei Unternehmen die Referenz, die der Käufer vorgibt. Die Regel prüft nur, ob ein Wert vorhanden ist. Format und Prüfziffer der Leitweg-ID prüft sie nicht. KoSIT-Meldung: „Das Element "Buyer reference" (BT-10) muss übermittelt werden.“ Die Regel ist fatal.
Rechnungstyp-Code nicht empfohlen (BT-3)
XRechnung empfiehlt, im Rechnungstyp-Code (BT-3) nur diese Werte aus der Codeliste UNTDID 1001 zu verwenden: 326 (Teilrechnung), 380 (Handelsrechnung), 381 (Gutschrift), 384 (Korrigierte Rechnung), 389 (Gutschrift im Gutschriftsverfahren), 875 (Abschlagsrechnung Bau), 876 (Schlussrechnung Teilabschnitt Bau) oder 877 (Schlussrechnung Bau). BR-DE-17 ist eine Warnung (Soll-Regel): Die Datei bleibt gültig, einzelne Empfänger können andere Codes aber ablehnen.
Skonto in den Zahlungsbedingungen (BT-20) falsch formatiert
Die EN 16931 hat kein strukturiertes Feld für Skonto. XRechnung legt deshalb ein maschinenlesbares Zeilenformat innerhalb der Zahlungsbedingungen (BT-20) fest: #SKONTO#TAGE=n#PROZENT=n.nn# mit optionalem Segment #BASISBETRAG=n.nn#. BR-DE-18 prüft jede Zeile, die mit „#“ beginnt, in der ersten cac:PaymentTerms/cbc:Note (CII: die erste ram:SpecifiedTradePaymentTerms/ram:Description). Jede dieser Zeilen muss dem Format genau entsprechen, und nach der letzten Skonto-Zeile muss ein Zeilenumbruch folgen. Normale Textzeilen werden ignoriert. Die Regel ist fatal.
Spezifikationskennung entspricht nicht XRechnung (BT-24)
BR-DE-21 besagt, dass die Spezifikationskennung BT-24 der XRechnung-Kennung entsprechen soll: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0, bei der XRechnung-Extension dieser Wert gefolgt von #conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0 (seit XRechnung-Schematron 2.4.0 ist auch die CVD-Kennung für Rechnungen über saubere Fahrzeuge zulässig). Im Schematron ist das nur eine Warnung. Praktisch wirkt sie blockierend: Der offizielle KoSIT-Validator wählt sein Prüfszenario genau anhand dieses Werts. Eine Datei mit veralteter Kennung (etwa urn:xoev-de:kosit:standard:xrechnung_2.3) passt zu keinem Szenario und wird ohne Regel-ID abgelehnt. Eine Datei mit der reinen EN-16931-Kennung urn:cen.eu:en16931:2017 wird nur gegen die EN 16931 geprüft, ohne XRechnung-Regeln.
Überweisung (30/58) ohne BG-17 oder mit Karten- bzw. Lastschriftdaten (BR-DE-23-a/-b)
Ist der Zahlungsartcode BT-81 gleich 30 (Überweisung) oder 58 (SEPA-Überweisung), müssen die Zahlungsanweisungen die Gruppe CREDIT TRANSFER (BG-17) enthalten, in UBL cac:PayeeFinancialAccount. Der Validator meldet das als BR-DE-23-a. Außerdem dürfen PAYMENT CARD INFORMATION (BG-18, cac:CardAccount) und DIRECT DEBIT (BG-19, cac:PaymentMandate) nicht vorhanden sein, gemeldet als BR-DE-23-b. Beide Teile sind fatal. In CII zählt auch eine Mandatsreferenz, Gläubiger-ID oder ein belastetes Konto an anderer Stelle der Abrechnung als BG-19.
Rechnungskorrektur (384) ohne Bezug auf die ursprüngliche Rechnung (BG-3)
Ist der Rechnungstyp-Code BT-3 gleich 384 (korrigierte Rechnung), soll die Gruppe PRECEDING INVOICE REFERENCE (BG-3) mindestens einmal vorhanden sein, damit der Käufer weiß, welche Rechnung korrigiert wird. In UBL ist das cac:BillingReference/cac:InvoiceDocumentReference mit der Rechnungsnummer in cbc:ID (BT-25), in CII ram:InvoiceReferencedDocument. BR-DE-26 ist eine Warnung.
E-Mail-Adresse des Verkäuferkontakts formal ungültig (BT-43)
BR-DE-28 prüft die Schreibweise der E-Mail-Adresse des Verkäuferkontakts (BT-43). Laut KoSIT-Text soll sie genau ein @ enthalten, das nicht von einem Leerzeichen oder Punkt flankiert ist, mit mindestens zwei Zeichen auf jeder Seite, und nicht mit einem Punkt beginnen oder enden. Die aktuelle KoSIT-Konfiguration (31. August 2026) prüft das mit dem regulären Ausdruck ^[^@\s]+@([^@.\s]+\.)+[^@.\s]+$: nirgends ein Leerzeichen, genau ein @ und eine Domain aus mindestens zwei nicht leeren, durch Punkte getrennten Teilen. Umlaute sind erlaubt; ältere Konfigurationen (etwa vom 31. Oktober 2024) nutzten ein strengeres Muster nur mit ASCII-Zeichen und beanstandeten sie. Die Regel ist eine Warnung. Sie schlägt zusammen mit BR-DE-7 auch an, wenn cac:Contact existiert, cbc:ElectronicMail aber leer ist.
Lastschrift ohne Gläubiger-Identifikationsnummer (BT-90)
BR-DE-30 betrifft Rechnungen, die per Lastschrift beglichen werden. Ist die Gruppe DIRECT DEBIT (BG-19) vorhanden, muss die Gläubiger-Identifikationsnummer (BT-90, „Bank assigned creditor identifier“) angegeben werden. In UBL ist BG-19 cac:PaymentMeans/cac:PaymentMandate, und BT-90 ist eine cac:PartyIdentification/cbc:ID mit schemeID="SEPA" in der Partei des Verkäufers (oder in cac:PayeeParty, wenn ein abweichender Zahlungsempfänger einzieht). In CII ist BT-90 ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID. Die Regel ist fatal. KoSIT-Meldung: „Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Bank assigned creditor identifier" BT-90 übermittelt werden.“
Liefer- oder Leistungsdatum fehlt (BT-72, BG-14 oder BG-26)
BR-DE-TMP-32 ist eine vorläufige KoSIT-Regel, eingeführt mit dem Bugfix-Release von XRechnung 3.0.2 vom 10. Juli 2025 (XRechnung-Schematron 2.4.0). Eine Rechnung soll angeben, wann geliefert oder geleistet wurde, und zwar auf einem von drei Wegen: mit dem tatsächlichen Lieferdatum BT-72, dem Abrechnungszeitraum BG-14 oder einem Positionszeitraum BG-26 in jeder Rechnungsposition. Die KoSIT stuft die Regel als „information“ ein, die niedrigste Stufe; der Validator empfiehlt also weiterhin die Annahme. In dieser Referenz steht sie unter Warnung. Die KoSIT hat angekündigt, das Liefer- oder Leistungsdatum mit einem künftigen normativen Release als verpflichtende Geschäftsregel aufzunehmen.
Summe der Positions-Nettobeträge stimmt nicht überein (BT-106)
Die Summe der Positions-Nettobeträge (BT-106) muss der Summe aller Positions-Nettobeträge (BT-131) entsprechen. In UBL ist BT-106 cac:LegalMonetaryTotal/cbc:LineExtensionAmount und BT-131 das cbc:LineExtensionAmount jeder cac:InvoiceLine; in CII jeweils ram:LineTotalAmount in der Kopf- und Positionssummierung. Es gibt keine Toleranz, ein Cent Abweichung genügt. Die Regel ist fatal.
Rechnungsbetrag ohne Umsatzsteuer falsch berechnet (BT-109)
BR-CO-13 prüft den Nettobetrag: Rechnungsbetrag ohne Umsatzsteuer (BT-109) = Summe der Positions-Nettobeträge (BT-106) − Summe der Abschläge auf Dokumentebene (BT-107) + Summe der Zuschläge auf Dokumentebene (BT-108). In UBL heißt das cbc:TaxExclusiveAmount = cbc:LineExtensionAmount − cbc:AllowanceTotalAmount + cbc:ChargeTotalAmount, jeweils in cac:LegalMonetaryTotal; in CII ram:TaxBasisTotalAmount. Das Ergebnis wird auf zwei Nachkommastellen gerundet und muss genau stimmen. Die Regel ist fatal. Die Umsatzsteuer-Summe (BT-110) prüft eine andere Regel, BR-CO-14.
Fehler bei der Rechnungsgesamtbetrag-Berechnung (BT-112)
Der Rechnungsgesamtbetrag mit Umsatzsteuer (BT-112, cbc:TaxInclusiveAmount) muss dem Rechnungsbetrag ohne Umsatzsteuer (BT-109, cbc:TaxExclusiveAmount) plus der Umsatzsteuer-Summe (BT-110, cbc:TaxAmount in Dokumentwährung) entsprechen. Die Regel verlangt außerdem genau ein cac:TaxTotal/cbc:TaxAmount in Dokumentwährung. Sie ist fatal.
Fehler bei der Berechnung des fälligen Betrags (BT-115)
Der fällige Betrag (BT-115, cbc:PayableAmount) muss dem Rechnungsgesamtbetrag mit Umsatzsteuer (BT-112) minus dem bereits gezahlten Betrag (BT-113) plus dem Rundungsbetrag (BT-114) entsprechen. Eine Abweichung deutet oft darauf hin, dass eine Vorauszahlung oder ein Rundungswert in einer Summe steht, im Zahlbetrag aber fehlt. Die Regel ist fatal.
Positions-Nettobetrag mit mehr als zwei Nachkommastellen (BT-131)
BR-DEC-23 ist eine Regel der EN 16931: Der Positions-Nettobetrag (BT-131) darf höchstens zwei Nachkommastellen haben. In UBL ist das cbc:LineExtensionAmount jeder cac:InvoiceLine (bzw. cac:CreditNoteLine), in CII ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount. Sie gehört zur Familie BR-DEC, die alle Beträge einer Rechnung auf zwei Nachkommastellen begrenzt. Die Regel ist fatal. KoSIT-Meldung: „[BR-DEC-23]-The allowed maximum number of decimals for the Invoice line net amount (BT-131) is 2.“ In UBL schlägt meist zusätzlich die allgemeine Regel UBL-DT-01 an („Amounts shall be decimal up to two fraction digits“).
Spezifikationskennung fehlt (BT-24)
BR-1 ist die erste Kernregel der EN 16931: Eine Rechnung muss eine Spezifikationskennung (BT-24) haben. Im KoSIT-Prüfbericht erscheint sie als [BR-01]. In UBL heißt das Feld cbc:CustomizationID, in CII rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. Es sagt dem Empfänger, nach welchem Regelwerk die Rechnung erstellt ist; für XRechnung 3.0.x lautet der Wert urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Die Regel ist fatal.
Rechnungsnummer fehlt (BT-1)
Jede Rechnung nach EN 16931 muss eine Rechnungsnummer (BT-1) haben. Im KoSIT-Prüfbericht erscheint die Regel als [BR-02]. In UBL ist das Feld cbc:ID direkt unter dem Wurzelelement, in CII rsm:ExchangedDocument/ram:ID. In UBL schreibt schon das XML-Schema das Element vor; ein fehlendes cbc:ID scheitert also zuerst an der Schemaprüfung. BR-02 erscheint, wenn das Element vorhanden, aber leer ist oder nur Leerzeichen enthält. Die Regel ist fatal.
Rechnungstyp-Code fehlt (BT-3)
Eine Rechnung muss einen Rechnungstyp-Code (BT-3) haben. Im KoSIT-Prüfbericht erscheint die Regel als [BR-04]. In einer UBL-Invoice heißt das Feld cbc:InvoiceTypeCode, in einer UBL-CreditNote cbc:CreditNoteTypeCode, in CII rsm:ExchangedDocument/ram:TypeCode. Das UBL-Schema behandelt das Element als optional, deshalb fängt nur diese Schematron-Regel sein Fehlen ab; die XRechnung-Warnung BR-DE-17 erscheint zusätzlich. Die Regel ist fatal.
Rechnungswährung fehlt (BT-5)
Eine Rechnung muss ihre Währung angeben (BT-5). Im KoSIT-Prüfbericht erscheint die Regel als [BR-05]. In UBL heißt das Feld cbc:DocumentCurrencyCode, in CII ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode. Der Wert ist ein ISO-4217-Code, bei deutschen Rechnungen fast immer EUR. Mehrere Rechenregeln vergleichen Beträge mit dieser Währung. Die Regel ist fatal.
Name des Verkäufers fehlt (BT-27)
Eine Rechnung muss den Namen des Verkäufers (BT-27) enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-06]. In UBL ist das cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName, in CII ram:SellerTradeParty/ram:Name. BT-27 ist der vollständige Name, unter dem der Verkäufer eingetragen ist, etwa im Handelsregister; ein Handelsname gehört in BT-28 (cac:PartyName/cbc:Name). Die Regel ist fatal.
Rechnung ohne Rechnungsposition (BG-25)
Eine Rechnung muss mindestens eine Rechnungsposition (BG-25) haben. In UBL ist das cac:InvoiceLine (cac:CreditNoteLine in einer Gutschrift), in CII ram:IncludedSupplyChainTradeLineItem. In UBL verlangt schon das Schema mindestens eine Position; eine Datei ohne Positionen scheitert dort an der Schemaprüfung, bevor diese Regel läuft. In CII, wo das Schema null Positionen zulässt, meldet BR-16 den Fehler. Die Regel ist fatal.
Positionskennung fehlt (BT-126)
Jede Rechnungsposition muss eine Positionskennung (BT-126) haben: cbc:ID in cac:InvoiceLine, in CII ram:AssociatedDocumentLineDocument/ram:LineID. Der KoSIT-Test prüft nur, dass sie nicht leer ist. Empfangende Systeme nutzen sie, um sich bei Rückfragen sowie in Zahlungs- und Buchungsabläufen auf einzelne Positionen zu beziehen. Die Regel ist fatal.
Artikelname in Position fehlt (BT-153)
Jede Rechnungsposition muss den Artikelnamen (BT-153) enthalten: cac:Item/cbc:Name in UBL, ram:SpecifiedTradeProduct/ram:Name in CII. Er beschreibt die berechnete Ware oder Leistung; ohne ihn kann das empfangende System die Position weder anzeigen noch einer Bestellung zuordnen. Die Regel ist fatal und schlägt auch bei einem leeren oder nur aus Leerzeichen bestehenden Namen an.
Kennung des rechnungsbegründenden Dokuments fehlt (BT-122)
Jedes rechnungsbegründende Dokument (BG-24) muss eine Kennung (BT-122) haben, die das angehängte oder verlinkte Dokument bezeichnet. In UBL ist das cbc:ID in cac:AdditionalDocumentReference, in CII ram:AdditionalReferencedDocument/ram:IssuerAssignedID. Die Regel gilt für jeden Anhang und schlägt bei einer leeren Kennung an. Die Regel ist fatal.
Normalsatz verwendet, aber keine Steueraufschlüsselung „S“ (BG-23)
Verwendet eine Rechnungsposition, ein Abschlag oder ein Zuschlag auf Dokumentebene die Steuerkategorie S (Normalsatz), muss die Steueraufschlüsselung (BG-23) mindestens eine Aufschlüsselung mit Kategorie S enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-S-01]. In UBL steht die Aufschlüsselung in cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID. Die Regel ist fatal.
Normalsatz-Positionen ohne USt-IdNr. oder Steuernummer des Verkäufers (BT-31/BT-32)
Eine Rechnung mit mindestens einer Position der Steuerkategorie S muss die USt-IdNr. des Verkäufers (BT-31), seine Steuernummer (BT-32) und/oder die USt-IdNr. seines Steuervertreters (BT-63) enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-S-02]. In UBL sind BT-31 und BT-32 ein cac:PartyTaxScheme/cbc:CompanyID in der Partei des Verkäufers mit TaxScheme VAT bzw. FC. Die XRechnung-Regel BR-DE-16 prüft dasselbe für alle steuerpflichtigen Kategorien und schlägt meist zusätzlich an. Die Regel ist fatal.
Normalsatz: Bemessungsgrundlage je Steuersatz stimmt nicht (BT-116)
Für jeden Steuersatz, der mit Kategorie S verwendet wird, muss die Bemessungsgrundlage (BT-116) in der Steueraufschlüsselung der Summe der Positions-Nettobeträge (BT-131) plus Zuschläge (BT-99) minus Abschläge (BT-92) auf Dokumentebene entsprechen, die Kategorie S und genau diesen Satz tragen. Im KoSIT-Prüfbericht erscheint die Regel als [BR-S-08]. Für UBL lässt das Schematron eine Abweichung von weniger als 1,00 in beide Richtungen zu; für CII vergleicht es die auf zwei Nachkommastellen gerundeten Werte exakt. Die Regel ist fatal.
Nullsatz verwendet, aber keine einzelne Steueraufschlüsselung „Z“ (BG-23)
Verwendet eine Position, ein Abschlag oder ein Zuschlag die Steuerkategorie Z (Nullsatz), muss die Steueraufschlüsselung genau eine Aufschlüsselung mit Kategorie Z enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-Z-01]. Z ist ein echter Steuersatz von 0 %; in Deutschland gilt er nur in bestimmten Fällen, etwa für bestimmte Photovoltaikanlagen nach § 12 Abs. 3 UStG. Steuerfreie Umsätze verwenden E, Reverse Charge verwendet AE. Die Regel ist fatal.
Steuerbefreiung verwendet, aber keine einzelne Steueraufschlüsselung „E“ (BG-23)
Verwendet eine Rechnungsposition, ein Abschlag oder ein Zuschlag auf Dokumentebene die Steuerkategorie E (steuerbefreit), muss die Steueraufschlüsselung (BG-23) genau eine Aufschlüsselung mit Kategorie E enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-E-01]. Die Regel zählt die E-Aufschlüsselungen: keine ist ein Fehler, zwei ebenfalls. Der Befreiungsgrund dieser Aufschlüsselung ist eine eigene Regel, BR-E-10. Die Regel ist fatal.
Reverse Charge verwendet, aber keine einzelne Steueraufschlüsselung „AE“ (BG-23)
Verwendet eine Rechnungsposition, ein Abschlag oder ein Zuschlag auf Dokumentebene die Steuerkategorie AE (Umkehrung der Steuerschuldnerschaft, Reverse Charge), muss die Steueraufschlüsselung (BG-23) genau eine Aufschlüsselung mit Kategorie AE enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-AE-01]. Verwandte Regeln prüfen die Einzelheiten: BR-AE-09 verlangt einen Steuerbetrag von 0, BR-AE-10 den Befreiungsgrund „Reverse charge“, BR-AE-02 die USt-IdNrn. von Verkäufer und Käufer. Die Regel ist fatal.
IGIC (Kanarische Inseln) verwendet, aber keine Steueraufschlüsselung „L“ (BG-23), früher BR-IG-1
BR-AF-1 betrifft die IGIC, die allgemeine indirekte Steuer der Kanarischen Inseln (Steuerkategorie-Code L). Verwendet eine Position, ein Abschlag oder ein Zuschlag die Kategorie L, muss die Steueraufschlüsselung mindestens eine Aufschlüsselung mit Kategorie L enthalten. Die aktuelle KoSIT-Konfiguration (31. August 2026, CEN-Schematron 1.3.16) meldet die Regel als [BR-AF-01]. Ältere Konfigurationen, etwa die vom 31. Oktober 2024 (CEN 1.3.12), melden dieselbe Regel bei UBL-Dateien als [BR-IG-01]; in CII hieß sie schon BR-AF-01. Der Regeltext ist unverändert. Sie ist für Verkäufer oder Umsätze relevant, die der kanarischen Steuer unterliegen, nicht für normale deutsche Rechnungen. Die Regel ist fatal.
„Nicht steuerbar“ verwendet, aber keine einzelne Steueraufschlüsselung „O“ (BG-23)
Verwendet eine Position, ein Abschlag oder ein Zuschlag die Steuerkategorie O (nicht steuerbar, außerhalb des Anwendungsbereichs der Umsatzsteuer), muss die Steueraufschlüsselung genau eine Aufschlüsselung mit Kategorie O enthalten. Im KoSIT-Prüfbericht erscheint die Regel als [BR-O-01]. Zur Kategorie O gehören strenge Begleitregeln: Es darf keine andere Aufschlüsselung geben (BR-O-11), weder USt-IdNr. des Verkäufers noch des Käufers darf angegeben sein (BR-O-02), und ein Befreiungsgrund ist Pflicht (BR-O-10). Die Regel ist fatal.
XML nicht wohlgeformt (Parserfehler, keine Regel-ID)
SCHEMA-001 ist keine offizielle Regel-ID; docutools.pro verwendet sie als Bezeichnung für Dateien, die sich gar nicht als XML lesen lassen. Der KoSIT-Validator bricht dann beim ersten Schritt ab: Sein Bericht zeigt kein Szenario und keine Regel, nur eine Parsermeldung wie „The entity name must immediately follow the '&' in the entity reference“ mit Zeile und Spalte, und die Datei wird nicht angenommen (aktuelle KoSIT-Versionen formulieren das als „Das Dokument sollte nicht automatisiert angenommen werden“, ältere als Empfehlung zur Ablehnung). Häufige Ursachen sind ein nicht maskiertes & oder < in einem Textwert, ein nie geschlossenes Tag, falsche Verschachtelung, Text vor der XML-Deklaration oder eine Kodierungsangabe, die nicht zur Datei passt.
Falsches Wurzelelement oder Namespace (kein passendes Szenario, keine Regel-ID)
SCHEMA-002 ist keine offizielle Regel-ID; docutools.pro verwendet sie als Bezeichnung für wohlgeformte Dateien, die der KoSIT-Validator keinem Prüfszenario zuordnen kann. Der Validator wählt das Szenario anhand von Wurzelelement, Namespace und Spezifikationskennung BT-24. Passt nichts, meldet der Bericht, dass kein Szenario gefunden wurde, zeigt keine Regel-ID, und die Datei wird nicht angenommen (aktuelle KoSIT-Versionen: „Das Dokument sollte nicht automatisiert angenommen werden“). Für XRechnung in UBL muss das Wurzelelement Invoice im Namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 sein (oder CreditNote in ...:CreditNote-2); für CII ist es rsm:CrossIndustryInvoice.
XSD-Schemaverstoß: Element fehlt, steht falsch oder ist nicht erlaubt (keine Regel-ID)
SCHEMA-003 ist keine offizielle Regel-ID; docutools.pro verwendet sie als Bezeichnung für Fehler gegen das XML-Schema (XSD). Nach der Szenario-Auswahl prüft der KoSIT-Validator die Datei gegen das Schema für UBL 2.1 bzw. CII D16B. Scheitert das, laufen die Schematron-Schritte gar nicht; der Bericht zeigt nur Schemameldungen wie „Invalid content was found starting with element cbc:IssueDate. One of cbc:ProfileID, cbc:ID ... is expected.“ Das Ergebnis lautet Ablehnung.
Genug vom XML-Debugging?
Unsere Smart-Repair-Engine prüft Ihre Rechnung gegen das vollständige KoSIT-Regelwerk, korrigiert unterstützte Felder wie Beträge, Steuerkategorie und Pflichtangaben und protokolliert jede Änderung in einem GoBD-konformen Prüfpfad.
Anwendung starten