What is KoSIT Validation?
The Coordination Office for IT Standards (KoSIT) provides the official validator for XRechnung documents. This validator checks every submitted e-invoice in two steps: first against the UBL 2.1 XML schema (syntactic well-formedness), then against an extensive set of Schematron rules that implement the business rules of EN 16931 plus the German extension rules (BR-DE-*).
Schematron rules are classified by severity: fatal errors (FATAL/Critical) make the KoSIT validator recommend 'reject', and the invoice is rejected. Warnings (WARNING) cover 'should' rules; the validator still recommends accepting the invoice. The most common error sources are miscalculated totals, missing mandatory fields per the German extension specification, invalid code values, and badly formatted dates.
This reference covers all essential error codes — from structural XML errors through core EN 16931 rules (BR-1, BR-6, BR-CO-*) to German extension rules (BR-DE-1 through BR-DE-31) and VAT-specific rules (BR-S-*, BR-E-*, BR-Z-*, BR-AE-*).
Severity Levels
The invoice is rejected. The error must be fixed before resubmitting.
WarningA 'should' rule. The KoSIT validator still recommends accepting the invoice, but the deviation is worth fixing.
Error Database
Select an error code for detailed remediation instructions.
Payment Instructions Missing (BG-16)
BR-DE-1 is a rule of the German CIUS XRechnung: every invoice must contain the group PAYMENT INSTRUCTIONS (BG-16). In UBL this is cac:PaymentMeans, in CII ram:SpecifiedTradeSettlementPaymentMeans. EN 16931 treats BG-16 as optional, so a file that passes a plain EN 16931 check can still fail here. The rule is fatal. The KoSIT validator reports it as 'Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten.' and recommends rejecting the invoice.
Seller Contact Missing (BG-6)
XRechnung requires the group SELLER CONTACT (BG-6). In UBL this is cac:AccountingSupplierParty/cac:Party/cac:Contact, in CII ram:SellerTradeParty/ram:DefinedTradeContact. EN 16931 treats the group as optional. XRechnung makes it mandatory and, through BR-DE-5, BR-DE-6 and BR-DE-7, also requires its three fields: contact point (BT-41), telephone number (BT-42) and email address (BT-43). The rule is fatal. KoSIT message: 'Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden.'
Seller City Missing (BT-37)
The seller's postal address (BG-5) must contain the city (BT-37). EN 16931 only requires the country code in an address (BR-09); XRechnung adds the city with BR-DE-3 and the post code with BR-DE-4. The same applies to the buyer (BR-DE-8, BR-DE-9). The rule is fatal and also fires when cbc:CityName is present but empty.
Seller Post Code Missing (BT-38)
The seller's postal address (BG-5) must contain the post code (BT-38). This is an XRechnung addition to EN 16931. The rule is fatal. A frequent cause is a combined value such as '10115 Berlin' in the city field while cbc:PostalZone stays empty.
Seller Contact Point Missing (BT-41)
When the SELLER CONTACT group (BG-6) is present, it must contain the contact point BT-41: the name of a person or a department. In XRechnung 3.0.x this is a fatal rule, not a warning. If the whole group is missing, BR-DE-2 fires instead.
Buyer Reference Missing (BT-10)
BR-DE-15 requires the element Buyer reference (BT-10) in every XRechnung, and it must not be empty. In UBL this is cbc:BuyerReference directly under the root, in CII ram:ApplicableHeaderTradeAgreement/ram:BuyerReference. For public buyers the field carries the Leitweg-ID; for companies it carries whatever reference the buyer asks for. The rule only checks that a value is there. It does not check the Leitweg-ID format or its check digit. KoSIT message: 'Das Element "Buyer reference" (BT-10) muss übermittelt werden.' The rule is fatal.
Invoice Type Code Not Recommended (BT-3)
XRechnung recommends that the invoice type code in BT-3 is one of these UNTDID 1001 values: 326 (Partial Invoice), 380 (Commercial Invoice), 381 (Credit Note), 384 (Corrected Invoice), 389 (Self-billed Invoice), 875 (Partial Construction Invoice), 876 (Partial Final Construction Invoice) or 877 (Final Construction Invoice). BR-DE-17 is a warning ("should" rule), so the file stays valid, but some recipients may reject other codes.
Skonto (Early-Payment Discount) Badly Formatted in BT-20
EN 16931 has no structured field for an early-payment discount (Skonto). XRechnung therefore defines a machine-readable line format inside the payment terms (BT-20): #SKONTO#TAGE=n#PROZENT=n.nn# with an optional #BASISBETRAG=n.nn# segment. BR-DE-18 checks every line that starts with '#' in the first cac:PaymentTerms/cbc:Note (CII: the first ram:SpecifiedTradePaymentTerms/ram:Description). Each such line must match the format exactly, and a line break must follow the last Skonto line. Ordinary text lines are ignored. The rule is fatal.
Specification Identifier Is Not the XRechnung ID (BT-24)
BR-DE-21 says that the specification identifier BT-24 should be the XRechnung identifier: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0, or for the XRechnung Extension that value followed by #conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0 (since XRechnung Schematron 2.4.0 the CVD identifier for clean-vehicle invoices is accepted as well). In the Schematron it is only a warning. In practice it is blocking: the official KoSIT validator picks its validation scenario by exactly this value, so a file with an outdated identifier (such as urn:xoev-de:kosit:standard:xrechnung_2.3) matches no scenario and is rejected without any rule ID. A file with only the plain EN 16931 identifier urn:cen.eu:en16931:2017 is checked against EN 16931 alone, without any XRechnung rule.
Credit Transfer (30/58) Without BG-17, or With Card or Direct-Debit Data (BR-DE-23-a/-b)
When the payment means type code BT-81 is 30 (credit transfer) or 58 (SEPA credit transfer), the payment instructions must contain the CREDIT TRANSFER group BG-17, in UBL cac:PayeeFinancialAccount. The validator reports this as BR-DE-23-a. They must also not contain PAYMENT CARD INFORMATION (BG-18, cac:CardAccount) or DIRECT DEBIT (BG-19, cac:PaymentMandate), reported as BR-DE-23-b. Both parts are fatal. In CII, a mandate reference, creditor identifier or debited account anywhere in the settlement also counts as BG-19.
Corrected Invoice (384) Without Preceding Invoice Reference (BG-3)
If the invoice type code BT-3 is 384 (corrected invoice), the group PRECEDING INVOICE REFERENCE (BG-3) should be present at least once, so the buyer knows which invoice is being corrected. In UBL this is cac:BillingReference/cac:InvoiceDocumentReference with the invoice number in cbc:ID (BT-25), in CII ram:InvoiceReferencedDocument. BR-DE-26 is a warning.
Seller Contact Email Has an Invalid Format (BT-43)
BR-DE-28 checks the syntax of the seller contact email (BT-43). According to the KoSIT text it should contain exactly one @, not flanked by a space or a dot, with at least two characters on each side, and no dot at the start or end. The current KoSIT configuration (31 August 2026) checks it with the regular expression ^[^@\s]+@([^@.\s]+\.)+[^@.\s]+$: no whitespace anywhere, exactly one @, and a domain made of at least two non-empty parts separated by dots. Umlauts are accepted; older configurations (for example 31 October 2024) used a stricter ASCII-only pattern and flagged them. The rule is a warning. It also fires, together with BR-DE-7, when cac:Contact exists but cbc:ElectronicMail is empty.
Direct Debit Without Creditor Identifier (BT-90)
BR-DE-30 applies to invoices that are paid by direct debit. If the DIRECT DEBIT group (BG-19) is present, the bank assigned creditor identifier (BT-90), in Germany the SEPA Gläubiger-Identifikationsnummer, must be provided. In UBL, BG-19 is cac:PaymentMeans/cac:PaymentMandate, and BT-90 is a cac:PartyIdentification/cbc:ID with schemeID="SEPA" in the seller party (or in cac:PayeeParty if a different payee collects). In CII, BT-90 is ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID. The rule is fatal. KoSIT message: 'Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Bank assigned creditor identifier" BT-90 übermittelt werden.'
Delivery or Service Date Missing (BT-72, BG-14 or BG-26)
BR-DE-TMP-32 is a temporary KoSIT rule, added with the XRechnung 3.0.2 bugfix release of 10 July 2025 (XRechnung Schematron 2.4.0). An invoice should state when the goods were delivered or the service was performed, using one of three options: the actual delivery date BT-72, the invoicing period BG-14, or an invoice line period BG-26 in every line. KoSIT flags it as 'information', the lowest level, so the validator still recommends accepting the invoice. In this reference it is filed under Warning. KoSIT has announced that a future normative XRechnung release will make the delivery or service date a mandatory business rule.
Sum of Line Net Amounts Mismatch (BT-106)
The sum of invoice line net amounts (BT-106) must equal the sum of all line net amounts (BT-131). In UBL, BT-106 is cac:LegalMonetaryTotal/cbc:LineExtensionAmount and BT-131 is cbc:LineExtensionAmount in each cac:InvoiceLine; in CII they are ram:LineTotalAmount in the header and line monetary summations. There is no tolerance: a difference of one cent is enough. The rule is fatal.
Invoice Total Without VAT Incorrect (BT-109)
BR-CO-13 checks the net total: invoice total amount without VAT (BT-109) = sum of invoice line net amounts (BT-106) − sum of document-level allowances (BT-107) + sum of document-level charges (BT-108). In UBL that is cbc:TaxExclusiveAmount = cbc:LineExtensionAmount − cbc:AllowanceTotalAmount + cbc:ChargeTotalAmount, all inside cac:LegalMonetaryTotal; in CII ram:TaxBasisTotalAmount. The result is rounded to two decimals and must match exactly. The rule is fatal. The VAT total (BT-110) is a different rule, BR-CO-14.
Grand Total Calculation Error (BT-112)
The invoice total amount with VAT (BT-112, cbc:TaxInclusiveAmount) must equal the invoice total without VAT (BT-109, cbc:TaxExclusiveAmount) plus the invoice total VAT amount (BT-110, cbc:TaxAmount in document currency). The rule also requires exactly one cac:TaxTotal/cbc:TaxAmount in the document currency. It is fatal.
Payable Amount Calculation Error (BT-115)
The amount due for payment (BT-115, cbc:PayableAmount) must equal the invoice total with VAT (BT-112) minus the paid amount (BT-113) plus the rounding amount (BT-114). A mismatch often means a prepayment or a rounding value was included in one total but not in the payable amount. The rule is fatal.
Invoice Line Net Amount Has More Than Two Decimals (BT-131)
BR-DEC-23 is an EN 16931 rule: the invoice line net amount (BT-131) may have at most two decimals. In UBL this is cbc:LineExtensionAmount in each cac:InvoiceLine (or cac:CreditNoteLine), in CII ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount. It belongs to the BR-DEC family, which limits all amounts in an invoice to two decimals. The rule is fatal. KoSIT message: '[BR-DEC-23]-The allowed maximum number of decimals for the Invoice line net amount (BT-131) is 2.' In UBL the general rule UBL-DT-01 ('Amounts shall be decimal up to two fraction digits') usually fires alongside.
Specification Identifier Missing (BT-24)
BR-1 is the first EN 16931 core rule: an invoice must have a specification identifier (BT-24). The KoSIT report prints it as [BR-01]. In UBL the field is cbc:CustomizationID, in CII rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. It tells the receiver which rule set the invoice follows; for XRechnung 3.0.x the value is urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. The rule is fatal.
Invoice Number Missing (BT-1)
Every EN 16931 invoice must have an invoice number (BT-1). The KoSIT report prints the rule as [BR-02]. In UBL the field is cbc:ID directly under the root, in CII rsm:ExchangedDocument/ram:ID. In UBL the element itself is mandatory in the XML schema, so a missing cbc:ID fails the schema check first; BR-02 appears when the element is present but empty or contains only spaces. The rule is fatal.
Invoice Type Code Missing (BT-3)
An invoice must have an invoice type code (BT-3). The KoSIT report prints the rule as [BR-04]. In a UBL Invoice the field is cbc:InvoiceTypeCode, in a UBL CreditNote cbc:CreditNoteTypeCode, in CII rsm:ExchangedDocument/ram:TypeCode. The UBL schema treats the element as optional, so only this Schematron rule catches its absence; the XRechnung warning BR-DE-17 appears alongside. The rule is fatal.
Invoice Currency Code Missing (BT-5)
An invoice must state its currency (BT-5). The KoSIT report prints the rule as [BR-05]. In UBL the field is cbc:DocumentCurrencyCode, in CII ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode. The value is an ISO 4217 code, for German invoices almost always EUR. Several calculation rules compare amounts against this currency. The rule is fatal.
Seller Name Missing (BT-27)
An invoice must contain the seller name (BT-27). The KoSIT report prints the rule as [BR-06]. In UBL this is cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName, in CII ram:SellerTradeParty/ram:Name. BT-27 is the full name under which the seller is registered, for example in the commercial register; a trading name belongs in BT-28 (cac:PartyName/cbc:Name). The rule is fatal.
Invoice Has No Invoice Line (BG-25)
An invoice must have at least one invoice line (BG-25). In UBL that is cac:InvoiceLine (cac:CreditNoteLine in a credit note), in CII ram:IncludedSupplyChainTradeLineItem. In UBL the schema already requires at least one line, so a file without lines fails the schema check before this rule runs; in CII, where the schema allows zero lines, BR-16 reports it. The rule is fatal.
Invoice Line Identifier Missing (BT-126)
Each invoice line must have an invoice line identifier (BT-126): cbc:ID in cac:InvoiceLine, in CII ram:AssociatedDocumentLineDocument/ram:LineID. The KoSIT test only checks that it is not empty. Receiving systems use it to refer to individual lines in queries and in payment and accounting workflows. The rule is fatal.
Invoice Line Item Name Missing (BT-153)
Every invoice line must contain the item name (BT-153): cac:Item/cbc:Name in UBL, ram:SpecifiedTradeProduct/ram:Name in CII. It describes the goods or services invoiced; without it the receiving system cannot display the line or match it to an order. The rule is fatal and also fires for an empty or whitespace-only name.
Supporting Document Reference Missing (BT-122)
Each additional supporting document (BG-24) must contain a supporting document reference (BT-122), an identifier for the attached or linked document. In UBL that is cbc:ID in cac:AdditionalDocumentReference, in CII ram:AdditionalReferencedDocument/ram:IssuerAssignedID. The rule applies to every attachment and fires for an empty ID. The rule is fatal.
Standard Rate Used but No 'S' VAT Breakdown (BG-23)
If any invoice line, document-level allowance or document-level charge uses VAT category S (standard rated), the VAT breakdown (BG-23) must contain at least one breakdown with category code S. The KoSIT report prints the rule as [BR-S-01]. In UBL the breakdown is cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID. The rule is fatal.
Standard Rate Lines Without Seller VAT ID or Tax Number (BT-31/BT-32)
An invoice with at least one line in VAT category S must contain the seller VAT identifier (BT-31), the seller tax registration identifier (BT-32, in Germany the Steuernummer) and/or the seller tax representative VAT identifier (BT-63). The KoSIT report prints the rule as [BR-S-02]. In UBL, BT-31 and BT-32 are cac:PartyTaxScheme/cbc:CompanyID in the seller party with TaxScheme VAT or FC. The XRechnung rule BR-DE-16 checks the same for all taxable categories and usually fires alongside. The rule is fatal.
Standard Rate: Taxable Amount per Rate Does Not Match (BT-116)
For each VAT rate used with category S, the taxable amount (BT-116) in the VAT breakdown must equal the sum of the line net amounts (BT-131) plus document-level charges (BT-99) minus document-level allowances (BT-92) that carry category S and that same rate. The KoSIT report prints the rule as [BR-S-08]. For UBL the Schematron allows a difference of less than 1.00 in either direction; for CII it compares the values rounded to two decimals exactly. The rule is fatal.
Zero Rate Used but No Single 'Z' VAT Breakdown (BG-23)
If any line, document-level allowance or charge uses VAT category Z (zero rated), the VAT breakdown must contain exactly one breakdown with category Z. The KoSIT report prints the rule as [BR-Z-01]. Z is a genuine 0 % rate; in Germany it applies only in specific cases, for example certain solar installations under § 12 (3) UStG. Exempt supplies use E, reverse charge uses AE. The rule is fatal.
Exempt Category Used but No Single 'E' VAT Breakdown (BG-23)
If any invoice line, document-level allowance or charge uses VAT category E (exempt from VAT), the VAT breakdown (BG-23) must contain exactly one breakdown with category E. The KoSIT report prints the rule as [BR-E-01]. The rule counts the E breakdowns: none fails, and two fail as well. The exemption reason for that breakdown is a separate rule, BR-E-10. The rule is fatal.
Reverse Charge Used but No Single 'AE' VAT Breakdown (BG-23)
If any invoice line, document-level allowance or charge uses VAT category AE (reverse charge), the VAT breakdown (BG-23) must contain exactly one breakdown with category AE. The KoSIT report prints the rule as [BR-AE-01]. Related rules check the details: BR-AE-09 requires a tax amount of 0, BR-AE-10 the exemption reason 'Reverse charge', BR-AE-02 the VAT IDs of seller and buyer. The rule is fatal.
IGIC (Canary Islands Tax) Used but No 'L' VAT Breakdown (BG-23), formerly BR-IG-1
BR-AF-1 concerns IGIC, the general indirect tax of the Canary Islands (VAT category code L). If a line, document-level allowance or charge uses category L, the VAT breakdown must contain at least one breakdown with category L. The current KoSIT configuration (31 August 2026, CEN Schematron 1.3.16) prints the rule as [BR-AF-01]. Older configurations, for example the one of 31 October 2024 (CEN 1.3.12), report the same rule in UBL files as [BR-IG-01]; in CII it was already BR-AF-01. The text of the rule did not change. It is relevant for sellers or supplies subject to Canary Islands tax, not for normal German invoices. The rule is fatal.
'Not Subject to VAT' Used but No Single 'O' VAT Breakdown (BG-23)
If a line, document-level allowance or charge uses VAT category O (services outside the scope of tax, not subject to VAT), the VAT breakdown must contain exactly one breakdown with category O. The KoSIT report prints the rule as [BR-O-01]. Category O has strict companion rules: no other breakdown may exist (BR-O-11), neither seller nor buyer VAT ID may be stated (BR-O-02), and an exemption reason is required (BR-O-10). The rule is fatal.
XML Not Well-Formed (Parser Error, No Rule ID)
SCHEMA-001 is not an official rule ID; docutools.pro uses it as a label for files that cannot be parsed as XML at all. The KoSIT validator then stops at the first step: its report shows no scenario and no rule, only a parser message such as 'The entity name must immediately follow the '&' in the entity reference' with line and column, and the file is not accepted (current KoSIT versions word this as 'Das Dokument sollte nicht automatisiert angenommen werden', older ones as a recommendation to reject). Common causes are an unescaped & or < in a text value, a tag that is never closed, wrong nesting, text before the XML declaration, or an encoding declaration that does not match the file.
Wrong Root Element or Namespace (No Matching Scenario, No Rule ID)
SCHEMA-002 is not an official rule ID; docutools.pro uses it as a label for well-formed files that the KoSIT validator cannot assign to a validation scenario. The validator selects the scenario from the root element, its namespace and the specification identifier BT-24. If nothing matches, the report says that no scenario matched, shows no rule ID, and the file is not accepted (current KoSIT versions: 'Das Dokument sollte nicht automatisiert angenommen werden'). For XRechnung in UBL the root must be Invoice in the namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 (or CreditNote in ...:CreditNote-2); for CII it is rsm:CrossIndustryInvoice.
XSD Schema Violation: Element Missing, Misplaced or Not Allowed (No Rule ID)
SCHEMA-003 is not an official rule ID; docutools.pro uses it as a label for XML schema (XSD) errors. After selecting a scenario, the KoSIT validator checks the file against the UBL 2.1 or CII D16B schema. If that fails, the Schematron steps are not run at all, so the report shows only schema messages such as 'Invalid content was found starting with element cbc:IssueDate. One of cbc:ProfileID, cbc:ID ... is expected.' The result is reject.
Done debugging XML?
Our Smart Repair engine checks your invoice against the full KoSIT rule set, corrects supported fields such as amounts, VAT category and mandatory data, and records every change in a GoBD-compliant audit trail.
Launch Application