E-Invoice Format Error, Business Rule Error or Content Error?
E-invoice format error, business rule error or content error: three examples each with the KoSIT rule, the input VAT impact in Germany and a decision table.
docutools.pro Editorial TeamEditorial TeamKey takeaways
- The BMF letter of 15 October 2025 separates format errors (para. 6a), business rule errors (para. 6b) and content errors (para. 35a).
- A file with a format error is not an e-invoice under German VAT law but an other invoice (sonstige Rechnung).
- Business rule errors outside the mandatory invoice details, such as a missing BT-10, have no VAT consequence.
- Content errors break the mandatory details of § 14(4) and § 14a UStG and can exist even when validation passes.
- You may rely on the technical validation result; the BMF suggests keeping the validation report.
On this page
An e-invoice format error means the invoice file does not follow a permitted syntax, for example it fails the UBL or CII XML schema. Under the German BMF letter of 15 October 2025 (para. 6a), such a file is not an e-invoice but an other invoice. The BMF treats business rule errors (para. 6b) and content errors (para. 35a) differently.
This matters to anyone receiving German e-invoices: accounts payable teams, shared service centres and foreign suppliers whose files get rejected. The distinction tells you whether to reject a file, ask for a corrected invoice, or post it despite a validation message. Below are three examples per class with the matching KoSIT rule, and a decision table.
What are the three error classes?
The classes come from the BMF letter of 15 October 2025 (opens in a new tab), which adds paragraphs 6a, 6b and 35a to the earlier letter of 15 October 2024. The same rules appear in the German VAT Application Decree (Umsatzsteuer-Anwendungserlass, UStAE), section 14.1(11) and section 14.5(1).
| Error class | BMF definition | Where it shows | VAT consequence |
|---|---|---|---|
| Format error (Formatfehler, para. 6a) | The file does not meet the permitted syntaxes or their technical requirements | XML parser, XSD schema | Not an e-invoice, but an other invoice |
| Business rule error (Geschäftsregelfehler, para. 6b) | The file breaks the format's business rules: data incomplete or contradictory | Schematron (BR-…) | None, unless a mandatory detail is affected |
| Content error (Inhaltsfehler, para. 35a) | A breach of the mandatory details in § 14(4) and § 14a UStG | Business rules, or nothing at all | Invoice not proper, input VAT at risk |
The classes overlap. A content error can surface as a business rule error, for example when the invoice number is missing. It can also hide in a file that passes every check. A validator only knows schema and rules. Whether a rule breach matters for VAT is your call.
Format errors: when is a file not an e-invoice?
A format error affects the file as a whole. Para. 6a says the type of format error is irrelevant: any deviation from the syntax is enough. For formats agreed between the parties (Section 14(1) sentence 6 no. 2 of the German VAT Act, § 14 UStG), a format error also exists when the data cannot be extracted correctly and completely into an EN 16931 format.
Three typical examples:
- Schema violation. An element is in the wrong order, misspelt, or missing although the UBL or CII schema requires it. The KoSIT validator stops after the XSD step and runs no business rules.
- Malformed XML. A tag is not closed, or a character such as
&is not escaped. The file cannot even be parsed as XML. - No permitted syntax. The invoicing software exports its own XML that is neither UBL 2.1 nor UN/CEFACT CII. The validation configuration has no scenario for it.
Related, but not a format error in the strict sense: a supposed ZUGFeRD PDF without embedded XML is simply a PDF without an integrated data set, and therefore also an other invoice under section 14.1(2) UStAE. See how to validate a ZUGFeRD PDF.
What follows from a format error?
It depends on whether the supply already requires an e-invoice:
| Period | Other invoices allowed? | Effect of a format error |
|---|---|---|
| Until 31 December 2026 | Yes; electronic ones with the recipient's consent (para. 63) | Valid other invoice if the recipient consents |
| 2027 | Only for issuers with 2026 total turnover up to €800,000 (para. 64), or via EDI (para. 65) | Not a proper invoice from larger issuers |
| From 1 January 2028 | No, except small invoices, travel tickets and small businesses (Kleinunternehmer) | Not a proper invoice |
Where an e-invoice was required and an other invoice was issued instead, section 15.2a(1) sentence 4 UStAE says it does "in principle" not entitle the recipient to deduct input VAT (Vorsteuerabzug). New sentence 13 of section 15.2a(1a) softens this: for an other invoice that is correct and complete in content, the conditions for deduction without a proper invoice "will regularly be met". The cleaner route is a correction. The supplier issues an e-invoice that refers specifically and unambiguously to the original invoice (section 15.2a(7) UStAE). Who must issue e-invoices when is explained in Germany e-invoicing 2027.
Business rule errors: when does a rule breach not matter for VAT?
Para. 6b defines business rules as "technical rules for checking the logical dependencies" within an e-invoice. For XRechnung these are the EN 16931 Schematron rules (BR-…, BR-CO-…, BR-CL-…) and the German national rules (BR-DE-…). Para. 35a states that business rule errors about "other content" than the mandatory details have no VAT relevance.
Three examples, with the official rule text from the KoSIT configuration of 31 August 2026:
| Rule | Official text (German original, translated) | Why it has no VAT relevance |
|---|---|---|
| BR-DE-15 | The element "Buyer reference" (BT-10) must be provided | The Leitweg-ID or order reference is not a mandatory detail under § 14(4) UStG; the BMF uses this exact example |
| BR-DE-1 | An invoice must contain "PAYMENT INSTRUCTIONS" (BG-16) | Payment details are not mandatory invoice details |
| BR-DE-2 | The group "SELLER CONTACT" (BG-6) must be provided | Contact name, phone and e-mail are not mandatory details |
No VAT relevance does not mean no consequence. The KoSIT validator still recommends rejection, and many recipients reject such files automatically. For German federal authorities, a missing Leitweg-ID is a practical blocker, because the invoice cannot be routed. Details are on the BR-DE-15 page and in the overview of XRechnung validation errors; rely on the official rule text rather than the short title there.
Content errors: when is the invoice not proper?
A content error is a breach of the mandatory VAT details in § 14(4) and § 14a UStG. The invoice is then not a proper invoice. Para. 35a says validation may reveal such errors, but it does not have to.
Three content errors the validator reports
| Rule | Official text (abridged) | Mandatory detail affected |
|---|---|---|
| BR-02 | "An Invoice shall have an Invoice number (BT-1)." | Invoice number, § 14(4) no. 4 UStG |
| BR-06 | "An Invoice shall contain the Seller name (BT-27)." | Supplier name, § 14(4) no. 1 UStG |
| BR-DE-16 | With VAT codes such as S, Z, E or AE, the seller VAT ID (BT-31), tax number (BT-32) or tax representative group (BG-11) must be provided | Tax number or VAT ID, § 14(4) no. 2 UStG |
Calculation errors are a borderline case. In para. 6b the BMF uses "tax amount does not match the stated VAT rate" as an example of a business rule error; in a KoSIT check this is usually BR-CO-17 (VAT amount per category) or BR-CO-14 (total VAT amount). VAT rate and VAT amount are, however, mandatory details under § 14(4) no. 8 UStG. In accounts payable, treat such a finding like a content error and ask for a correction.
Three content errors the validator cannot find
- Wrong VAT rate. 7 % instead of 19 % on consulting services: the invoice is internally consistent and passes every rule. The BMF names this exact example.
- Vague description. "Services as agreed" fills the mandatory field BT-153 but does not meet § 14(4) no. 5 UStG.
- Missing supply date. The XRechnung rule BR-DE-TMP-32 suggests BT-72, BG-14 or BG-26, but it is information only and never blocks. § 14(4) no. 6 UStG still requires the date.
That is why, under para. 35a, validation "does not replace" the recipient's duty to check the invoice for completeness and correctness. The full list of mandatory details is in German invoice requirements.
Which KoSIT rule belongs to which error class?
The BMF does not map rule prefixes to classes. The table below is our classification, based on the KoSIT configuration of 31 August 2026 and the definitions in paras. 6a, 6b and 35a.
| Finding in the KoSIT check | Typical error class | Note |
|---|---|---|
| Malformed XML, XSD error | Format error | No rules run afterwards |
| No matching validation scenario | Format error if the file is neither UBL nor CII | A valid EN 16931 file with another identifier (e.g. Peppol BIS) is not automatically faulty; the XRechnung configuration just does not check it |
| UBL-SR, CII-SR (errors) | Unclear | Syntax-related rules; the BMF is silent, and most UBL-CR rules are warnings anyway |
| BR-01 to BR-65 | Content error if the field is a mandatory detail, otherwise business rule error | Check the BT/BG reference in the rule text |
| BR-CO (calculations) | Treat like a content error where VAT amounts are involved | Totals affect the net amount and VAT |
| BR-S, BR-E, BR-AE, BR-IC, BR-G, BR-O, BR-Z | Often content errors | VAT category, exemption reason and VAT ID are mandatory details |
| BR-CL (code lists) | Mostly business rule errors | Exception: VAT category codes |
| BR-DE | Mostly business rule errors | Exceptions: BR-DE-14 (VAT rate), BR-DE-16 (tax ID) |
Decision table for accounts payable
| Finding | Error class | Post it? | Next step |
|---|---|---|---|
| Schema or scenario failure | Format error | Until end of 2026 as an other invoice if you consent; afterwards not without more | Request a new, valid e-invoice |
| Errors only on BT-10, BG-16, BG-6 or similar fields | Business rule error | Yes, no VAT relevance | Ask the supplier to fix future invoices |
| Errors on invoice number, name, address, tax ID, VAT amount | Content error | Safe only after correction | Request a corrected invoice (§ 31(5) UStDV) |
| File valid, but VAT rate or description wrong | Content error | Safe only after correction | Request a corrected invoice |
| File valid, warnings or information only | Not an error in the BMF sense | Yes, after a content check | Read the warnings, check the supply date |
How to fix the individual messages is covered in fix XRechnung validation errors. The steps the official tool runs, and how it reaches its verdict, are explained in our guide to the KoSIT validator.
How to classify validation results with docutools.pro
- Open the XRechnung validator and upload the XML file. The file is sent to our server for the check. For a ZUGFeRD PDF, first extract the XML from the PDF in your browser.
- Read the "KoSIT validation" section. A schema error means a format error. If "No official validation scenario matches this file" appears, check the specification identifier (BT-24): if the file is neither XRechnung nor plain EN 16931, agree the format with your supplier.
- If the verdict is "Not KoSIT-conformant", classify every finding at level "Error" with the table above: is a mandatory detail affected or not?
- Then check the VAT details with the German invoice requirements checker. Its "Auto-check XML" option pre-fills the checklist; supply date, exemption note and discounts must be ticked by hand.
- For a report to keep on file, run the KoSIT validator itself, because our result is shown on the page only. The free plan includes 2 uploads per day; the Pro plan removes the limit.
The check in the viewer follows the KoSIT configuration of 31 August 2026 and gives the same results as KoSIT validator 1.6.3 in our comparison. More guides are in the validation and errors category.
Sources
- BMF letter of 15 October 2025 on e-invoicing (opens in a new tab) (German), paras. 6a, 6b, 35a and the changes to section 15.2a UStAE
- § 14 UStG on Gesetze im Internet (opens in a new tab) (German)
- KoSIT validation configuration for XRechnung (opens in a new tab), release 2026-08-31
Last reviewed: October 2026
This article is general information, not tax or legal advice.
Tools for this article
- XRechnung ViewerParse, validate & repair German e-invoices with GoBD-compliant audit trail.Open tool →
- KoSIT Error HubSearchable reference for all XRechnung validation error codes with fix guides.Open tool →
- Invoice Mandatory Fields CheckerVerify all mandatory §14 UStG invoice fields via checklist or XRechnung/ZUGFeRD XML.Open tool →
Frequently asked questions
What is a format error in a German e-invoice?
A format error means the invoice file does not follow a permitted syntax or its technical requirements, for example it fails the UBL or CII XML schema. Under para. 6a of the BMF letter of 15 October 2025, the type of format error does not matter. The file is then not an e-invoice but an other invoice in a different electronic format (sonstige Rechnung).
Does a validation error cost me the input VAT deduction?
Only if it affects a mandatory invoice detail or the file is not an e-invoice at all. Business rule errors about other content, such as the missing buyer reference BT-10, have no VAT relevance according to para. 35a of the BMF letter. A missing invoice number or supplier tax number, however, is a content error and makes the invoice improper.
Can an e-invoice pass validation and still be wrong?
Yes. A validator checks syntax and business rules such as mandatory fields, code lists and calculations. It cannot know whether the VAT rate is correct for the supply or whether the description is specific enough. The BMF itself names a wrong VAT rate as a content error that validation does not detect. Checking the content remains the recipient's duty.
Should we keep the e-invoice validation report?
It is not a legal requirement, but the BMF recommends it. Under para. 35a of the BMF letter of 15 October 2025, a business acting with due commercial care may rely on the technical result of a suitable validation tool, and keeping the validation report is a sensible way to prove it. Store it together with the invoice.