80 Days to XML: The E-Rechnung Deadline Is an Integration Problem, Not a PDF Problem

In the first half of 2026, roughly 51 million e-invoices ran through Datev's systems. In all of 2025 the figure was about 64 million. That is 80% of last year's volume in half the time, and Datev's own chief executive still described it in July as a small share of Germany's total invoice traffic, adding that for a large part of the smaller Mittelstand the topic is simply not in focus (CIO, July 2026 (opens in new tab); it-daily, July 2026 (opens in new tab)).

After today, 2026 has 80 days left. Fifty-eight of them are weekdays, before you subtract public holidays and the year-end close. On 1 January 2027 the transition period for issuing ends for every company above the revenue threshold.

Our take: the firms in trouble in January will be the ones that scoped the work as "our invoicing tool needs to export a different file format". The file format is the easy tenth of the job. Everything that makes an e-invoice valid, deliverable, processable and auditable sits upstream or downstream of the XML.

One note before we go on: this is engineering guidance, not tax or legal advice. Take the legal questions to your Steuerberater.

What actually changes on 1 January

Under § 14 UStG (opens in new tab), an invoice between two businesses established in Germany has to be an elektronische Rechnung: a structured format that conforms to the European standard EN 16931, or a format the parties agree on that can be extracted losslessly into it. A PDF is not that; it is a sonstige Rechnung, an "other invoice".

The obligation has formally applied since 1 January 2025. What has kept PDFs legal is the transition rule in § 27 Abs. 38 UStG (opens in new tab), which has three parts:

• Until 31 December 2026, anyone may still send paper, or another electronic format if the recipient agrees.
• Until 31 December 2027, the same relief continues only if the issuer's total turnover (Gesamtumsatz as defined in § 19 Abs. 2 UStG) in the preceding calendar year was not more than EUR 800,000.
• Until 31 December 2027, EDI procedures that do not already meet the e-invoice requirements may continue, with the recipient's consent.

From 2028, none of that remains. One detail gets lost in the headlines: the threshold is total turnover, and for 2027 the year that counts is 2026, which is not over yet. If you are near EUR 800,000 you will not know which side you are on until the books close.

The exceptions are narrow. According to the BMF's FAQ (opens in new tab) (as of March 2026), no e-invoice is needed for B2C sales, many tax-exempt supplies, small-amount invoices up to EUR 250 gross, tickets that count as invoices, supplies made by Kleinunternehmer, and supplies to legal entities that are not businesses. Receiving has no exception: every business, Kleinunternehmer included, has had to be able to receive e-invoices since 1 January 2025.

How ready is the market? The most recent number we found is a YouGov survey of 502 companies commissioned by the invoicing vendor easybill, reported in June 2026: 33% had never sent an e-invoice, 29% had not started the transition, and 36% named technical implementation as the main obstacle (Händlerbund, June 2026 (opens in new tab)). It is vendor-commissioned, so discount accordingly, but it matches what Datev reports.

The XML is the easy tenth

Generating syntactically correct UBL or CII from an invoice record is a solved problem. There are mature open-source libraries for it, and most ERPs and invoicing tools have shipped an export. But EN 16931 is a semantic data model with business rules, and those rules expose the state of your master data.

Master data is where projects stall

A PDF invoice tolerates sloppy data because a human reads it. A structured invoice does not. The patterns we see in these integrations:

• Buyer identifiers. Customer records with no VAT ID, an outdated one, or one typed into a free-text notes field. For public-sector customers, the Leitweg-ID that routes the invoice to the right authority is missing or stored on the wrong entity. XRechnung requires the buyer reference field (BT-10) to be filled for every invoice, public sector or not.
• Tax categories. Internally, many systems know "19%", "7%" and "0%". EN 16931 wants to know why it is zero: exempt, reverse charge, intra-community supply, export, outside scope. Each has its own category code, and exempt categories need a reason. A single "0%" tax key that has covered four different legal situations cannot be mapped automatically.
• Units of measure. The standard expects UN/ECE Recommendation 20 codes. Your article master has "Stk", "Stck.", "St", "pauschal" and "siehe Angebot".
• Arithmetic. Line net amounts, allowances, tax breakdowns and totals must reconcile under defined rounding. Systems that round per line in one place and per document in another produce invoices a cent off, which a human ignores and a validator rejects.

An export button fixes none of this. It takes a data cleanup that somebody in finance owns, plus rules in the system that stop the mess from growing back.

Validation belongs before sending, not after rejection

The BMF's second circular, dated 15 October 2025, introduced a distinction that every engineer on these projects should know. As summarised by Deloitte (opens in new tab) and the IHK Köln (opens in new tab), there are three classes of error:

• A format error means the file does not meet the syntax of the standard or cannot be reliably extracted. Such a file is not an e-invoice at all. It is treated as an "other invoice" in some electronic format.
• A business rule error means the file is well-formed but violates the logical rules: a mandatory field is missing, or amounts and rates contradict each other.
• A content error means the legally required invoice particulars are wrong, whatever the validator says.

For an issuer above the threshold in 2027, a file with a format error is not a compliant invoice, and a careful recipient will bounce it rather than risk their input VAT deduction. You find out when the payment does not arrive.

The BMF FAQ says validation is not a formal precondition for tax recognition, but recommends running it at creation and dispatch. We would go further and make it a gate in the invoicing pipeline, the way a failing test blocks a deploy. The reference tooling is public: KoSIT publishes its validator (opens in new tab) under Apache 2.0, it runs as a CLI, a Java library or an HTTP daemon, and the XRechnung rule set ships as a separate configuration. Wire it in so that a failing invoice cannot be sent, and so that the failure reaches the person who can fix the customer record.

XRechnung or ZUGFeRD: decide per recipient, not per company

Both are accepted. The BMF FAQ names XRechnung and ZUGFeRD from version 2.0.1 as compliant, with the exception of the MINIMUM and BASIC-WL profiles. If your current tool emits one of those two profiles and calls it "ZUGFeRD", you do not have an e-invoice.

Our default for B2B is ZUGFeRD in the EN 16931 profile: the recipient's clerk can still open a PDF, and their software gets the XML. XRechnung is pure XML with no visual part; public-sector buyers expect it, and some large customers demand it.

Hybrid files carry a trade-off most teams miss. The BMF FAQ states that the old precedence has been reversed: in a hybrid invoice the structured part now leads, and if PDF and XML disagree, the XML wins. If the PDF comes from a Word-style template and the XML from a separate export path, you have two sources of truth, and the one nobody looks at is the binding one. Render the PDF from the same data object that produces the XML, or do not ship hybrid.

The specs also move. KoSIT (opens in new tab) states that XRechnung 3.0 stays in force until at least 31 July 2027 and that the final 4.0 is expected in spring 2027; FeRD (opens in new tab) published ZUGFeRD 2.5.2 in August 2026. Whatever you build or buy needs an owner for format updates.

Downstream: inbound, archive, corrections, transport

Issuing gets the attention because of the deadline. Receiving has been mandatory for almost two years and is often in worse shape.

Inbound. The legal minimum for receiving is an email inbox; the BMF FAQ says so directly. That minimum has produced a common anti-pattern: the ZUGFeRD file arrives, someone opens the PDF, approves it, and keys the amounts into the accounting system. The XML, which is the invoice, is never read. A minimal correct inbound flow extracts the XML, validates it, renders the visual from the XML, and shows the approver that rendering.

Archiving. Invoices must be kept for eight years (§ 14b UStG (opens in new tab)), and for an e-invoice at least the structured part has to be preserved intact in its original form. Printing it, or storing only a rendered PDF in the DMS, does not do that. The BMF says that storing e-invoices outside a GoBD-compliant system is not by itself a breach of § 14b, but GoBD still applies to your bookkeeping as a whole. The engineering requirement: the original bytes, immutable, with a hash, linked to the booking record, retrievable for eight years, for outbound and inbound invoices alike.

Corrections. Where an e-invoice is mandatory, the correction has to be an e-invoice too, using the invoice type for a correction and referring specifically and unambiguously to the original (BMF FAQ, citing § 31 Abs. 5 UStDV). Many invoicing systems handle corrections today by regenerating the PDF or by a free-text Storno. Neither survives the move to structured data. You need real document types for correction and credit note, a stored reference to the preceding invoice, and immutability of whatever was already sent.

Transport. Email is permitted. It is not a strategy. It gives you no delivery receipt, no status, no structured rejection, and a real chance that a mail gateway on the other side quarantines an .xml attachment. The law leaves the channel to the parties. Large customers will dictate a portal or Peppol; public-sector buyers already do. Treat transport as an adapter behind an interface with at least three states per invoice: sent, accepted, rejected with reason.

What fits in 80 days, and what does not

Assuming you are above the threshold and starting now, we would cut the scope hard.

Do now:

1. Audit master data for your top customers. Check VAT IDs, buyer references, addresses and units for the customers behind most of your B2B invoice volume. Fix the data, then add input validation so new records cannot be saved incomplete.
2. Untangle your tax keys. Map every internal tax code to an EN 16931 category with your tax advisor. This is the task with the longest calendar time, because it needs a human decision per case.
3. Generate one format well. ZUGFeRD in the EN 16931 profile for B2B, with the PDF rendered from the same data. Add XRechnung only for customers who require it.
4. Put the validator in the pipeline as a hard gate, with a readable error for the back office.
5. Archive the original XML and the validation report immutably, outbound and inbound.
6. Implement corrections and credit notes as first-class document types.
7. Dual-run in December. Send the PDF you send today, generate and validate the e-invoice in parallel, and treat every validation failure as a defect to fix before January. Ask two or three friendly customers to ingest your test files.

Defer, deliberately:

• Full inbound automation: line-level matching against purchase orders, automatic posting, approval workflows. Get extraction, validation, correct visualisation and archiving right first.
• Peppol and an adapter for every customer portal. Start with email plus whatever your largest customers mandate. Build the interface now, the adapters later.
• Cross-border invoices. The mandate covers supplies between businesses established in Germany. The EU's VAT in the Digital Age package, adopted on 11 March 2025, brings digital reporting requirements for cross-border B2B transactions from 1 July 2030 (European Commission (opens in new tab)). That is a reason to model your invoice data on EN 16931 semantics rather than on one German flavour, not a reason to build anything this quarter.

What we would not defer is the master data work. Most other items can be bought or added quickly. That one cannot.

Build versus buy, honestly

We build custom software, so discount what follows accordingly. Most companies should not build this.

The ERP or Datev route is enough when your invoices are created in a mainstream ERP or accounting package whose vendor has shipped an EN 16931 module, your tax cases are standard, you have one invoicing system, and your customers accept email. Turn the module on, spend the remaining time on master data and tax-key mapping, and do the December dual-run. Writing your own XML generator in that situation is vanity.

A custom integration layer earns its cost when:

• Invoices originate outside the ERP: in an industry-specific system, a booking or ordering platform, a dealership system, or software you built yourself, where no vendor is going to ship a module for you.
• You have several invoicing sources and want one validation gate, one archive and one audit trail instead of three half-configured ones.
• The vendor add-on produces a file but leaves validation, archiving, corrections or transport to you, which is common.
• Your customers impose requirements the add-on does not cover: specific buyer references, order references per line, a portal upload, Peppol.
• The only "standard" option on offer is replacing the system that creates the invoices, and a migration under deadline pressure is a larger risk than the mandate.

The right shape is small: a canonical invoice model based on EN 16931, mappers from each source system, the KoSIT validator as a gate, a format renderer, an immutable archive, and transport adapters. No rewrite of the source system. This is the pattern behind our own E-Rechnung integration work (the page is in German): add XRechnung and ZUGFeRD to the software where invoices already originate, rather than swapping that software out.

The option we would steer anyone away from tends to appear late: a standalone web tool where someone retypes invoices from the real system to get a compliant file. It meets the deadline and leaves you with a second system of record and a permanent reconciliation problem.

What we are not saying

We are not saying 80 days is hopeless. For a company with clean master data and a current ERP, this is a configuration project. Nor is the structured invoice bureaucratic overhead: a validated, machine-readable invoice that can be booked without retyping is a better artifact than a PDF.

We are saying the deadline tests whether your customer records, tax keys and document lifecycle are in a state a machine can check. A validator is far less forgiving than the accounts-payable clerk who has been quietly fixing your invoices for years. Start with the data.

Further reading

• BMF, Fragen und Antworten zur Einführung der obligatorischen E-Rechnung (as of March 2026) (opens in new tab): scope, exceptions, formats, validation and archiving from the tax administration itself.
• § 14 UStG (opens in new tab) and § 27 Abs. 38 UStG (opens in new tab): the definition and the transition rules in the original wording.
• KoSIT, XRechnung (opens in new tab): the current specification, validity dates and release plan.
• KoSIT Validator on GitHub (opens in new tab): the open-source validation engine.
• FeRD, ZUGFeRD (opens in new tab): the hybrid format and its current version.
• Deloitte Tax-News on the BMF circular of 15 October 2025 (opens in new tab): the error classes and their consequences.