An e-invoice to a German business comes back from validation with a fatal error. Does it still count as an e-invoice for VAT? Germany’s Federal Ministry of Finance (BMF) answers in two letters to the tax authorities of the federal states, dated 15 October 2025 and 15 October 2026. It depends on the kind of error. Whether a business-rule error also means the invoice is not a proper invoice (ordnungsmäßige Rechnung), one that meets the legal requirements for an invoice, depends on whether it concerns a particular that VAT law requires. A report with no errors settles less than it seems.
The letters number their paragraphs as Rn. (Randnummer). This post cites them that way, beside the EN 16931 and XRechnung rules they touch.
Two views of one error
The 2026 letter separates two views (Rn. 23). In the technical view, a file that breaks a business rule of the EN 16931 core data model is no longer an e-invoice, because it does not conform to the standard. That holds even when the rule concerns something outside the particulars VAT law requires.
The BMF says this technical view does not decide VAT questions, input VAT deduction for example. For VAT, a file with a business-rule error but no format error is in principle still an e-invoice within the meaning of section 14 of the German VAT Act (UStG). To be a proper invoice, it must still carry all the particulars that §§ 14 and 14a UStG require, correct and complete.
Three kinds of finding
The 2025 letter defines the kinds of error (Rn. 6a, 6b and 35a). The 2026 letter confirms that the definitions in Rn. 6a and 6b are the VAT view (Rn. 22).
A format error. For an EN 16931 file, a format error means the file does not conform to the permitted syntaxes or their technical specifications. Such a file is not an e-invoice, whatever the kind of format error. Provided it is an invoice at all, it is an “other invoice” (sonstige Rechnung) in another electronic format (Rn. 6a), the category § 14 UStG also gives to invoices sent on paper.
A business-rule error is a separate kind. It exists when the file breaks the business rules that apply to its e-invoice format. Business rules, in the letter’s words, are technical rules that check the logical dependencies between the pieces of information in an e-invoice. An error can come from information that is incomplete or that contradicts other information. The letter’s examples are a missing Buyer reference in an XRechnung, and a tax amount that does not match the stated tax rate (Rn. 6b). What the error means for VAT depends on the field it concerns.
A business-rule error on a mandatory VAT particular. When the error concerns one of the particulars that §§ 14(4) and 14a UStG require, the invoice has a content error (Inhaltsfehler) and is not a proper invoice (Rn. 35a; 2026, Rn. 22).
A business-rule error on other content. It is irrelevant for VAT (Rn. 35a). The BMF’s example is the field BT-10 “Buyer reference”, which XRechnung requires (Rn. 6b and 35a).
| What the validation finds | What it means for German VAT | Where the letters say it |
|---|---|---|
| A format error | Not an e-invoice. Provided it is an invoice at all, an “other invoice” (sonstige Rechnung) in another electronic format | 2025, Rn. 6a |
| A business-rule error, and no format error, on a mandatory VAT particular | An e-invoice in principle, but not a proper invoice: it has a content error | 2025, Rn. 35a; 2026, Rn. 22 and 23 |
| A business-rule error, and no format error, on other content | An e-invoice in principle. The error is irrelevant for VAT | 2025, Rn. 35a; 2026, Rn. 23 |
| No error | Content errors are still possible, a wrong tax rate for example | 2025, Rn. 35a |
The BMF’s example, in the rule file
In XRechnung, the rule behind BT-10 is BR-DE-15. In KoSIT’s XRechnung
Schematron 2.6.0, the rule set for XRechnung 3.0.2, its message reads
Das Element "Buyer reference" (BT-10) muss übermittelt werden: the Buyer
reference must be sent. The rule is flagged fatal, in both the UBL and the CII
syntax. So an XRechnung without a Buyer reference fails validation, and by the
BMF’s own example that error is irrelevant for VAT.
Both letters answer VAT questions. Neither says whether a recipient has to accept a file that fails a business rule.
Which errors touch a VAT particular
The letters do not list which business rules concern a mandatory VAT particular. For which particular goes in which EN 16931 business term (BT) or business group (BG), the 2026 letter points to a mapping table that KoSIT and the Forum für elektronische Rechnung Deutschland (FeRD) drew up as an aid. The tax administration recommends basing e-invoices on its current version (Rn. 8 and 9). The letters stop at the field. They do not say which rule in a validation report concerns which particular.
What a report without errors leaves open
The first limit is content. A content error can exist without any business-rule error, so that the validation reports nothing. The BMF’s example is a wrong tax rate (2025, Rn. 35a). The validation does not replace the recipient’s duty to check the invoice for completeness and correctness; it helps with it. A business that acts with the care of a prudent merchant may rely on the technical result of a validation by a suitable validation application, for the format and the business rules. As evidence, the letter suggests keeping the validation report.
The second limit is the description of the supply. The 2026 letter spells out what it must do for a proper e-invoice (Rn. 10 to 12). For the invoice’s control function, above all the type, scope and content of the supply, and where relevant its place, must be in the structured part so unambiguously that these details alone allow the other tax bases to be determined, abstractly and beyond doubt. The BMF’s examples are whether it is a supply of goods or of services, the place of supply, and whether the tax rate applied is right. Where relevant, these details must also allow a concrete check on site, beyond doubt, that the supply was made. And they must show, just as beyond doubt, whether the recipient obtained the supply for their business, and so is in principle entitled to deduct input VAT.
Not every detail has to be in the description, and what is needed depends on the case (Rn. 11). Further information that the control function does not need, such as a breakdown of time records, does not have to be in the structured part and can go in an embedded attachment (Rn. 12).
What do the rules check of the description? EN 16931 requires every invoice line to carry an item name (BT-153). The rule is BR-25, flagged fatal. Its test in the EN 16931 validation artefacts 1.3.16:
CII normalize-space(ram:SpecifiedTradeProduct/ram:Name) != ''
UBL normalize-space(cac:Item/cbc:Name) != ''Any text that is not only whitespace passes, a single character included. Each line must also carry a quantity and its unit of measure (BR-22 and BR-23, both fatal). These rules check that the values are there, not whether they fit the supply. The only EN 16931 rule on the item description (BT-154), UBL-SR-50, allows it at most once. XRechnung’s Schematron 2.6.0 adds no rule on the item name or the item description. So no rule of EN 16931 or XRechnung tests whether a description is clear enough, and a report without errors does not say whether it meets Rn. 12.
Where the description may sit in an attachment
Two reliefs in the 2026 letter let the detailed description move from the structured part into an attachment. In both, an embedded attachment that people can read holds the detail, and the structured part must refer to it unambiguously.
Construction services (Rn. 13 and 14). These are often invoiced by the bill of quantities (Leistungsverzeichnis), which as a rule is a sufficient description. Because of technical limits the core data model still has, the bill of quantities cannot be listed in the structured part of an e-invoice that follows the core data model. So for now the tax administration does not object when the structured part holds, as the description, only the individual trades with their sums. The attachment must then hold a detailed breakdown by the bill of quantities. The letter sets no end date for this relief.
Gross-price invoices (Rn. 18 and 19). The EN 16931 core data model calculates from the net amount, which for a supply priced gross can cause rounding differences. No gross-price format is available yet for XRechnung and ZUGFeRD. So for EN 16931 e-invoices based on gross prices and issued by 31 December 2027, the tax administration does not object when the structured part carries, instead of a full description with line items, only the net totals per tax rate and exemption, each rate with its tax amount, or a note on the exemption. The attachment must then hold a proper description with the line items, from which the totals in the structured part follow.
No business rule checks either condition. No rule requires an attachment. The rules on attachments check their structure, such as BR-52, which requires each additional supporting document (BG-24) to carry its own identifier (BT-122), or BR-CL-24, which checks an attachment’s MIME code against a fixed list. None reads what an attachment holds, and none checks that the description in the structured part points to it.
One point the gross-price relief leaves open: EN 16931 still requires at least one invoice line (BR-16, fatal), and every line an item name (BR-25). The letter does not say how the totals per tax rate are to be laid out as lines.
Until the end of 2026
The 2026 letter applies to supplies made after 31 December 2024, with the transition rules that run to 31 December 2027. Its application rule adds a relief for e-invoices issued by 31 December 2026.