The PDF your invoicing tool sends has an end date as an invoice
The invoicing tool does its job well. The order closes, the invoice is generated, a PDF goes out by email with the logo in the right corner, and the chasing sequence starts counting days. In Germany that PDF has, since 1 January 2025, a new name in the tax code: an "other invoice". It can still be sent until 31 December 2026, or a year longer if the issuer's turnover in the previous year was up to 800,000 euro.
Germany is the worked example because its dates are written into the statute and explained in an official FAQ; the definition underneath is European. German sources are quoted in my translation, every page was read on 12 September 2026, and I am not a tax adviser.
The definition moved from "electronic" to "structured"
German VAT law now has two kinds of invoice. Section 14 of the VAT Act says (in translation): "An electronic invoice is an invoice issued, transmitted and received in a structured electronic format that allows electronic processing. An other invoice is an invoice transmitted in another electronic format or on paper." The Finance Ministry's FAQ spells out what fell on which side:
"A simple PDF document, for example, no longer falls under this definition, because it has no structured format. ... In particular, invoices on paper or in an unstructured electronic format (e.g. a simple PDF document) are an other invoice."
Bundesministerium der Finanzen, FAQ on the mandatory e-invoice, question 2, version of March 2026, translated from the German
The wording follows the EU standard. Of the Commission's list of what does not count as an e-invoice, three items describe what most tools send today: "Unstructured invoice data issued in PDF or Word formats. Images of invoices such as JPG or TIFF. Unstructured HTML invoices on a web page or in an email." The VAT directive adopts the same definition for the whole Union from 1 July 2030; Germany wrote it into national law early.
The dates are set, and they follow the date of the transaction
Since 1 January 2025 every German business must be able to receive an e-invoice, and the FAQ sets the bar low: "An e-mail inbox is already sufficient for that." Until 31 December 2026 anyone may still issue an "other invoice" instead, and a PDF by email remains allowed "only if the recipient agrees to that format". If the issuer's turnover in the previous calendar year was up to 800,000 euro, that period "is extended to the end of 2027". The FAQ states the test for the first cut-over, and the statute applies it to the later ones: "What counts is the time of the transaction". An invoice written in January for work done in December belongs to December's rules.
The obligation covers invoices between businesses established in Germany; invoices to consumers are outside it, as are amounts up to 250 euro gross and businesses under the small-business VAT scheme (Kleinunternehmer), who are exempt from issuing e-invoices "but must still be able to receive them".
What happens to a plain PDF sent where an e-invoice was due is written in the ministry's letter of 15 October 2024. In translation: such an invoice "is not a proper invoice" and "does not, in principle, entitle to input VAT deduction" (the customer's right to reclaim the tax they paid you); the sender may repair it with a later e-invoice. The pressure on the sender comes from the customer's accounts-payable team, whose deduction is at stake; neither the FAQ nor the letter names a fine.
Two files that look the same
A PDF can still be an e-invoice if it carries the structured data inside it. The ZUGFeRD format is a PDF with an XML file embedded, and from version 2.0.1 the ministry accepts it, except for the two stripped-down profiles, MINIMUM and BASIC-WL. The Lexware Office help centre describes what the recipient sees (in translation): "With ZUGFeRD files the XML is integrated into the visible PDF; they end in .pdf. ... You see only a PDF and no XML with a ZUGFeRD invoice? That is intended!"
So the recipient opens the same kind of file the tool sent before, and the ministry decides which of the two it is by what is inside. Where the picture and the data disagree, "the invoice data in the structured part (e.g. XML) is now the leading part"; a file whose XML has format errors "is an other invoice in another electronic format", the same status as a plain PDF; and a link to an external page "does not meet the requirements", so the email with a "view your invoice" button and the hosted page behind it are both outside the definition.
What the tools send by default
I read the documentation of six tools that produce or send invoices for small businesses, on 12 September 2026, for one question: what file leaves the system by default. XRechnung, in the table, is Germany's pure-XML format for the same standard, with no picture at all.
| Tool | What it produces | In its own words |
|---|---|---|
| Stripe Invoicing | invoice records through its API and webhooks; XML through partner apps | "doesn't generate or transmit legally compliant e-invoice files on its own" |
| Zoho Books (Germany) | PDF, with XRechnung XML or ZUGFeRD as an export step | "attach the invoice as a PDF file as well as attach e-invoice files when sending by e-mail" (translated) |
| Lexware Office | ZUGFeRD PDF or XRechnung XML attached to the email | "a digital PDF invoice is not a legally compliant e-invoice!" (translated) |
| Xero | e-invoices over the Peppol exchange network in listed EU countries, Germany included, since December 2025 | "register for, send, and receive compliant Peppol e-invoices" |
| Zapier | a help-centre search for "ZUGFeRD" returns two partner apps and no Zapier action | "We support ZUGFeRD and EN16931" (a partner app's listing) |
| Shopify Flow | "Send order invoice" emails an invoice; no file format is named | "sends an email invoice for the order that triggers the workflow" |
Even where the tool offers the format, the file has to pass the customer's validator: a user of an open-source invoicing tool reported in April 2026 that its generated XRechnung was rejected by every conformant validator because two XML elements were in the wrong order. The invoicing step is one line in a chain that a process audit writes down whole.
The other direction: what lands in your inbox
The receiving side needs no software to satisfy the law, and it removes an option: since 1 January 2025 a German business that cannot handle an e-invoice "has no right to have the issuer issue an other invoice instead". The supplier's XML is the invoice, and the recipient cannot demand a PDF in its place; any PDF sent on top of it is a copy. The FAQ adds that the recipient "is not obliged to carry out any further electronic processing than is already required by the rules on retention".
For anyone who has built or bought invoice extraction from PDFs, the receiving side changes first: the fields the extractor guesses from a picture are, in a compliant file, already sitting in the XML with names, and the checks you run before paying a supplier gain a clean input. The chasing sequence on the sales side keeps counting from a document that now has two layers.
Where this leaves you
Two questions for the invoice run:
What file does your tool send by default? If it is a PDF and a link, that setup expires on the German dates above for customers that are German businesses. The Commission's country pages, dated March 2026, record Italy's business-to-business mandate as in force since 2019, Belgium's from 1 January 2026, Poland's during 2026 and France's in stages from September 2026; the pages are summaries, so check the national source.
Can your inbox side read what arrives? An inbox satisfies the law; the bookkeeping still has to post from the XML, which is the file the tax office will treat as the invoice.
If you would rather have someone map which of your documents go out in what format, to whom, and what changes on the day the exemption ends: that is part of the process audit. $299, three business days, and a written map you keep whether or not you hire us.
Nothing here is tax or legal advice.
Related: the register of what is automated is where "what file this step sends" belongs as a column.