A supplier can send a flawless-looking PDF invoice, get paid without friction, and still be non-compliant the moment a national e-invoicing mandate applies to that transaction. Under EU e-invoicing law, looking electronic and being a structured e-invoice are not the same test.
As Germany, Italy, Spain, and the rest of the EU phase in structured e-invoicing mandates, the gap between “sent electronically” and “issued as a compliant e-invoice” is exactly the gap that gets a supplier's invoice rejected, a payment delayed, or a business found non-compliant mid-rollout.
TL;DR
- A paper invoice, a PDF invoice, and a scanned invoice are functionally the same thing under EU e-invoicing law: none of them is structured data, so none of them qualifies as an e-invoice.
- Only an invoice issued, transmitted, and received in a structured format, such as UBL or CII XML, as defined by Directive 2014/55/EU, counts as electronic for mandate purposes.
- A PDF with an embedded XML file, like ZUGFeRD or Factur-X, can count as a true e-invoice, but only if that embedded data uses a profile carrying full EN 16931 structured data.
- Reduced-data ZUGFeRD/Factur-X profiles such as MINIMUM and BASIC WL don't satisfy Germany's B2B e-invoicing requirement from January 2026 onward, even though the file itself is technically electronic.
- Emailing an invoice, uploading it to a portal, or sending it as HTML doesn't change its underlying format; the delivery channel can't turn an unstructured invoice into a structured one.
What actually separates paper, PDF, and a true e-invoice?
The difference between a paper invoice, a PDF invoice, and a true e-invoice comes down to one property: whether the data is structured for a machine to read, not how the file travels.
A paper invoice carries its data embedded in a printed layout meant for a person's eyes.
A PDF invoice does the same thing digitally: the amounts, dates, and line items sit inside a visual layout, and a computer receiving that PDF has no reliable way to extract them without OCR or manual entry.
A true e-invoice removes the layout as the carrier of meaning. The data lives in labeled XML fields, in a schema a receiving system can parse directly, and any human-readable version is a rendering generated from that data, not the source of it.
That distinction is why fiskaly's guide to what an e-invoice is treats the legal definition (issued, transmitted, and received in structured format) as the test, rather than asking whether a document moved over email or the postal service.
Why doesn't a PDF invoice count as an e-invoice, even when sent by email?
A PDF sent by email is digital, but digital and structured are different properties, and only structured invoices meet EU e-invoicing mandates. The European Commission's eInvoicing building block is explicit on this point: PDF and Word files, image formats like JPG or TIFF, unstructured HTML invoices, and OCR output from scanned paper invoices are all excluded from the legal definition of an e-invoice, regardless of how they were delivered.
The practical reason is automation. A receiving system can't reliably pull the invoice number, VAT amount, and line items out of a PDF's visual layout without a person checking the result, and that manual step is exactly what structured e-invoicing exists to remove. Sending the same invoice as an email attachment instead of printing it changes the channel, not the underlying data format.
What about a PDF with an embedded XML file, like ZUGFeRD or Factur-X?
Hybrid formats complicate the picture, because they genuinely can count as e-invoices, depending on which profile they use. ZUGFeRD and Factur-X embed a structured CII XML file inside a human-readable PDF/A-3 document, and since ZUGFeRD 2.1 in 2020, the German and French specifications have been technically identical, down to the shared embedded filename, factur-x.xml.
The catch is that both formats define multiple profiles, and not every profile carries full structured data. MINIMUM and BASIC WL are reduced-data profiles originally built around French booking-aid requirements; they carry only a subset of the invoice's fields and don't satisfy Germany's B2B e-invoicing requirement from January 2026 onward. For B2B invoicing into Germany, a COMFORT-level profile or higher, aligned with EN 16931, is the practical baseline. A PDF that technically contains embedded XML but uses one of the reduced profiles is still not a compliant e-invoice for that mandate, even though the file format looks identical from the outside.
Does a scanned invoice or OCR'd PDF count as electronic?
No. A scanned invoice is an image of a document, and running OCR on it afterward doesn't retroactively make it a structured e-invoice; OCR output is a best-effort text extraction prone to misreads, not a legally structured data format a receiving system can trust without verification. The European Commission's own eInvoicing guidance names OCR output from scanned paper invoices as one of the excluded categories specifically because of this reliability gap.
Does emailing, uploading to a portal, or sending an invoice as HTML change this?
No. Structure and channel are separate questions, and getting the channel right doesn't fix an unstructured file. Directive 2014/55/EU requires an invoice to be issued, transmitted, and received in structured format, all three, and most national mandates also specify which networks satisfy the transmission step (Peppol, Italy's Sistema di Interscambio, Germany's OZG-RE for federal public-sector invoices). Sending a properly structured XML file over an unapproved channel can create its own compliance gap, but sending an unstructured PDF over the correct channel doesn't turn it into an e-invoice either. For the full breakdown of what “issued, transmitted, and received in structured format” requires, see fiskaly's guide to what an e-invoice is.