Is a PDF an e-Invoice? What EN 16931 Requires

No. A plain PDF is a picture of an invoice. It is not an e-invoice under the European standard EN 16931. That distinction matters for France's 2026 reform, Germany's E-Rechnung rules, Peppol networks, and any client workflow built around EN 16931. The rule is simple: an e-invoice needs structured, machine-readable data; a PDF alone does not qualify.

What people mean when they say "e-invoice"

In casual speech, "electronic invoice" often means "not printed on paper." Emailing a PDF qualifies under that loose definition. Tax law in the EU moved past that years ago for mandatory regimes. Under EN 16931, an e-invoice is a structured electronic document that follows a defined semantic model, a shared list of business terms and meanings, so software can process it without a human retyping amounts into accounting software. The European Commission published EN 16931 as the core semantic standard. Member states then map national formats onto it.

What EN 16931 actually is

EN 16931 is not a file extension. It is the rulebook for what an invoice must say in data terms: seller, buyer, invoice number, dates, line items, VAT breakdowns, totals, and the rest of the required fields. Two common syntaxes (how you write those fields in XML) are UBL (ISO/IEC 19845 Universal Business Language) and CII (UN/CEFACT Cross Industry Invoice). If the structured file uses a compliant syntax and passes the applicable EN 16931 business rules, it can qualify as an e-invoice. Humans may need a viewer to read it. Machines do not.

Why a plain PDF fails

A PDF (or a scanned JPG saved as PDF) stores visual layout. Text might be extractable. It might not. There is no guarantee that "Total" in the bottom-right maps to the semantic field for invoice total payable. OCR guesses. Field order varies. Logos get in the way. From a compliance perspective for EN 16931 mandates, that is not good enough. The invoice must carry structured data, not only pixels that look like an invoice.

Think of it this way: if you are a freelance photographer in Berlin and you email Invoice-047.pdf, your client's finance tool cannot reliably auto-book VAT the way it can from an XRechnung XML file. Same commercial document. Different legal and technical category.

What does count as an e-invoice

Hybrid formats are the compromise freelancers usually prefer. You open a PDF. Inside it sits the XML. ZUGFeRD and Factur-X use the same basic hybrid model. Germany leans on XRechnung and ZUGFeRD; France accepts UBL, CII, and Factur-X for its mandate. A PDF can be part of an e-invoice if it is a hybrid container with the right embedded XML. A PDF by itself is still just a PDF.

Hybrid formats explained

Factur-X and ZUGFeRD use PDF/A-3 as a container. The visual PDF layer is for humans: you open it, read the invoice, print it if needed. The embedded XML layer is the e-invoice: software reads seller, buyer, line items, VAT, and totals from structured data without guessing. When you receive a hybrid file, archive the original file, not a printed or flattened copy. The XML is the point.

How this ties to national mandates

Germany: EN 16931 is the usual route for an E-Rechnung. XRechnung and ZUGFeRD (eligible profiles) qualify. Plain PDF does not. Receive since 2025; issue phases 2027/2028. See our XRechnung vs ZUGFeRD guide for freelancers.

France: structured formats move through an approved platform, with the public system handling the directory and tax data layer. Factur-X, UBL, CII. Receive for all in-scope businesses from 1 September 2026; micro/SME issuing from 1 September 2027. See our France e-invoicing mandate guide for freelancers.

Same European semantic core. Different national pipes. France routes through certified platforms and the public portal. Germany uses a post-audit model with no central clearance platform. Italy runs FatturaPA through the SDI exchange system.

"But my accountant accepts PDFs"

Many accountants still do. That is a workflow preference, not a definition of EN 16931. During transition periods (Germany still allows other invoices for issuing until 2027 or 2028 depending on prior-year revenue; French micro-entreprises need not issue structured invoices for in-scope B2B invoices until September 2027) a PDF may remain commercially fine. The mandate vocabulary still reserves "e-invoice" for the structured thing.

Since 1 September 2026, when a large French client issues to you, expect Factur-X or XML through a platform, not a casual PDF. When a German supplier sends an E-Rechnung, expect XRechnung or ZUGFeRD. Your receive-side duty is already live in Germany since 1 January 2025.

The wording I recommend

Stop calling every emailed PDF an "e-invoice" in client contracts and blog posts. The wording creates false confidence. Say "PDF invoice" when you mean PDF. Say "EN 16931 e-invoice" or name the format (ZUGFeRD, Factur-X, XRechnung, UBL) when you mean structured. Clarity here prevents the worst AP arguments.

What freelancers should do now

• When a client asks "can you send e-invoices?", ask which format they mean: XRechnung, ZUGFeRD, Factur-X, UBL, or CII.
• Keep using clear PDF invoices where the law still allows other invoices, but plan the structured switch before your national issuing date.
• If you receive a hybrid file, archive the original file, not only a printed or flattened copy.
• Use precise language in contracts: say "PDF invoice" when you mean PDF; say "EN 16931 e-invoice" or name the format when you mean structured.
• Use ordinary invoicing tools for numbering, reminders, and tracking while you add the structured formats. Do not wait until the week before your deadline.

The definitive answer

Is a PDF an e-invoice? Not under EN 16931. What makes an e-invoice? Structured data conforming to the EN 16931 semantic model, usually expressed as UBL or CII XML, standalone or embedded in a hybrid PDF/A-3 such as ZUGFeRD or Factur-X. Is there any PDF that counts? Yes: hybrid formats where the PDF/A-3 carries the embedded XML. The PDF skin is for humans. The XML is the e-invoice.