Embedded attachments, stricter requirements for structured invoice data, new correction rules and transition periods through 2030 — here is what the BMF letter of 15 October 2026 means for your e-invoicing process.
For the third year running the Federal Ministry of Finance published an e-invoicing letter on 15 October. The 2024 letter introduced the regime, the 2025 letter adapted the VAT Application Decree, and the new one, reference III C 5 - S 7287-a/00019/021/017, is shorter than both and easy to skim past.
It should not be skimmed past. The most consequential change is not in the letter's main body at all. It is a single word, replaced in four places of the UStAE at the very end of the document, and it decides whether the way you send supplementary information still works.
Sections 14.1 (17) and (19), and 14.5 (9) and (17) of the VAT Application Decree previously referred to information contained in the invoice. They now refer to information embedded in it.
That closes a gap people had been driving through. An attachment sitting next to the invoice, a download link, a reference to a document on a portal: none of that is embedded. If supplementary information has to travel with the invoice, it travels inside the file.
Hybrid formats. A ZUGFeRD or Factur-X file carries the PDF and any further attachment inside the same container, so the requirement is met by construction.
An XML sent by email with a separate PDF alongside it, or with a link to a customer portal. The supplementary document is attached to the message, not embedded in the invoice.
The letter opens with a sentence worth noting on its own: these rules will be reviewed again in view of the requirements of the reporting system that will then exist. The ministry is saying this is an interim position, with 2030 in view.
New sentence 3 in section 14.5 (15) is the other substantive change, and it is unusually specific for a VAT decree. The structured part must contain Leistungsart, Leistungsumfang, Leistungsgehalt and, where relevant, Leistungsort, clearly enough that someone reading only the structured data can:
distinguish a supply of goods from a service,
determine the place of supply,
check the tax rate applied,
and establish in principle the right to deduct input VAT.
This is the Kontrollfunktion the ministry keeps returning to, and a reference to a contract does not satisfy it. The counterweight sits in marginal note 12 and the reworded sentence 4: anything beyond that need not be in the structured part. Hour-by-hour timesheets, for example, can go in an embedded attachment, and the letter names a PDF explicitly.
So the dividing line is now drawn: enough in the XML to tax the transaction, the rest embedded.
Which mandatory detail belongs in which BT field or BG group is no longer left open. Marginal notes 8 and 9 point at the mapping tables from KoSIT and FeRD and recommend using the current version of them as the basis for your invoices. Both are linked at the end of this article.
Marginal notes 22 and 23 are the most interesting paragraphs in the document, and they describe a split that causes real confusion in projects.
A file that violates a business rule of the core data model no longer conforms to EN 16931, and on that reading is not an e-invoice.
That same file, if it has no format error, remains an e-invoice within the meaning of section 14 UStG.
The ministry states plainly that the technical view is not decisive for VAT questions, including input VAT deduction. A business-rule error produces a content error only where it touches a mandatory VAT field.
This cuts both ways, and the second direction is the one that gets overlooked. A red validation report does not automatically mean a broken invoice in tax terms. And an invoice that passes validation is still not a proper invoice unless the mandatory details under sections 14 and 14a UStG are present, correct and complete.
The letter grants several non-objection periods. They are generous, and most run far longer than people expect. Two of them reach into 2030.
Until 30 June 2030 the sum of part-payments already received may be shown in the structured part in BT-113 (Paid amount), with the required detail in the free-text field BT-22 (Invoice note). Alternatively the deduction may sit in an embedded unstructured attachment that satisfies section 14.8 (8) no. 2 UStAE, provided the structured part refers to it expressly. The 2024 letter had allowed this only to 31 December 2027, so this is an extension of two and a half years.
The EN 16931 core model calculates from the net amount, which creates rounding problems where the price is fixed gross, a book under fixed-price rules being the example given. The letter says plainly that no gross-invoice format is currently available for XRechnung or ZUGFeRD. Until the end of 2027 the structured part may therefore carry only the totals per tax rate and exemption, with a human-readable embedded attachment holding the line items.
The core data model cannot carry a Leistungsverzeichnis. Until it can, the structured part may show the individual trades with their totals, provided an embedded human-readable attachment holds the detailed breakdown and the structured part points to it clearly. The schedule may additionally travel as a structured file, GAEB being named, and the parties remain free to agree another suitable method under civil law, such as an extension carrying the schedule in the structured part.
Marginal notes 20 and 21 will reassure anyone who has been waiting for a technical ruling on correction types, because there is not one. Where an e-invoice is required the correction must also be an e-invoice using an invoice type for corrections. But the ministry states that it is not yet technically settled which type represents which correction practice, and that any correction method workable in practice may currently be used, with a suitable invoice type, as long as the original and the correction together make the final invoice details clear and unambiguous.
New sentence 7 in section 14.11 (2) adds a route that was previously contested: with an e-invoice the recipient may correct by issuing a credit note, provided this was agreed in advance and the credit note refers specifically and unambiguously to the original invoice.
Marginal note 28 settles a question that has circulated since 2024. Issuing an other invoice where an e-invoice was required is not an administrative offence under section 26a (2) no. 1 UStG.
The amended section 15.11 (3) is worth reading twice. Invoices that do not contain the details required by section 14 (4) sentence 1 nos. 1 to 8 and 10 UStG do not entitle the recipient to deduct input VAT unless they are subsequently completed, as a rule by the issuer. And the fallback of proving quantity or the date of supply from other business records, a delivery note for instance, is now expressly tied to other invoices only.
Retroactive in effect, subject to the statutory transition periods. The letter notes those run to 31 December 2027.
An e-invoice issued up to this date that complies with the 2024 and 2025 letters but not with the additional requirements of this one will not be objected to, including for input VAT purposes. In other words, you have until the end of the year to absorb this letter.
Both dates fall together, which is worth noting if you issue gross-priced invoices and were planning to use the full transition period first.
Final invoices settling advance payments, and public-law assessment notices issued as other invoices. By then the reporting system the letter alludes to is expected to be in place.
Four passages of the UStAE now turn on that word. A link or a second file in the same email does not qualify.
Type, scope, content and where relevant place of supply, in the XML, not in a referenced document.
They now have different consequences, and only one of them threatens the deduction.
BT-113 plus BT-22, or the embedded attachment with an express reference. Implement one of them deliberately rather than ending up with both.
The ministry recommends them by name, in the current version. That makes them the practical benchmark for a tax audit.
The two changes that matter here are both structural rather than legal. Supplementary documents have to sit inside the invoice file, and the structured part has to carry enough to tax the transaction on its own. Both are decided by how your invoices are generated, not by how carefully you read the letter.
We convert your ERP output into XRechnung, ZUGFeRD or Peppol BIS, embed attachments as part of the document rather than sending them alongside it, and validate before dispatch so you see a business-rule warning before your customer does. If you want to know where a real file stands against this letter today, our E-Invoice Validator is free and runs in the browser.
Test the platform free for 14 days. No commitment, no installation in your ERP.
Start free trialThis article is general information, not tax advice.
