E-invoicing
The e-invoice PDF nobody tagged
Last updated 2 September 2026
Between January 2026 and January 2028 every invoicing platform serving Europe is rebuilding the same part of its stack: the step that turns an invoice into a PDF. Belgium's mandate is live. France requires reception in September 2026 and issuance from large and mid-size businesses at the same time. Germany extends issuance to businesses over €800k in January 2027 and to everyone in January 2028.
The work is well understood — embed an EN 16931 XML payload in a PDF/A-3 container and you have a Factur-X or ZUGFeRD hybrid invoice. What is not understood is what that container leaves behind.
PDF/A-3 says nothing about tagging
PDF/A-3 comes in three conformance levels. Only Level A requires a tagged structure tree. Level B guarantees visual appearance and nothing else, which is to say it guarantees that a sighted person can read it.
The German implementation guide for ZUGFeRD, published by the PDF Association itself, is explicit about which one you need:
“Dabei spielt die Konformitätsstufe (d.h. 3a, 3b oder 3u) keine Rolle.”
The conformance level — 3a, 3b or 3u — is irrelevant.
Irrelevant to the e-invoice, and the ecosystem read it that way. Sample code, tutorials and reference implementations reach for PDF/A-3b almost without exception. It is the easiest level to hit, and nothing in the e-invoicing specification asks for more.
| Level | Guarantees | Tagged | Screen reader |
|---|---|---|---|
| PDF/A-3b | Visual appearance | No | Cannot read it |
| PDF/A-3u | Appearance + Unicode text | No | Extracts characters, no structure |
| PDF/A-3a | Appearance + Unicode + structure tree | Yes | Reads it as a document |
So the machine-readable half of a hybrid invoice is immaculate. Any tax authority in Europe can parse the XML. The half a human is supposed to read is a picture of a table.
Both standards in one file is a documented, recommended combination
This is not a trade-off anyone has to make. The PDF Association's best practice guide Conforming to both PDF/A and PDF/UA, published 11 June 2025, is unambiguous:
“When creating PDF/UA-1 files, the PDF Association RECOMMENDS using PDF/A-2 or PDF/A-3.”
“The PDF Association RECOMMENDS using PDF/A conformance Level A for documents that comply with both PDF/UA-1 and PDF/A-2 or PDF/A-3.”
PDF/A-3a plus PDF/UA-1, in a single file, carrying the e-invoice XML as an embedded attachment. Archival, machine-readable and accessible at once. The standards body recommends exactly this container, and the e-invoicing specifications simply never mention it.
One caution on versions: this pairing lives on PDF 1.7. PDF 2.0 documents pair PDF/UA-2 with PDF/A-4, and PDF/A-4 cannot serve as a Factur-X container. For hybrid invoices the target is PDF/A-3a with PDF/UA-1.
Who this lands on
Not the accountant. The obligation to produce an accessible document sits with the business sending the invoice, and that business did not build its own PDF renderer. It bought a platform.
Under the European Accessibility Act, in force since 28 June 2025, service providers below ten people and €2m are exempt. The platforms serving tens of thousands of businesses are not, and neither are most of their customers. Where the EAA's route to a specific PDF runs through EN 301 549 clause 10 on non-web documents rather than through the directive's own text, the honest framing is that the legal position on transactional invoices is still being drawn — strongest for consumer banking and account documents, less settled for a B2B invoice.
Which is why the argument that matters here is not the legal one. It is that the pipeline is open right now.
The cost of doing it later
Adding a structure tree while you are already rewriting the PDF path for Factur-X is marginal work. Adding it in 2029, to a renderer that has since been wrapped in template logic, customer branding and per-country layout rules, is a project.
Most platforms generate invoices from HTML through headless Chrome, Gotenberg, wkhtmltopdf or a similar engine. None of those can emit a structure tree — the reason is architectural, not a missing flag. The tagging has to come from somewhere else, and the cheapest moment to decide that is while the pipeline is already apart.
What Wellform does about it
Wellform takes the HTML you already render invoices from and returns a tagged PDF that passes PDF/UA-1, with a conformance report attached to every document. Same input you have now. No template rewrite, no change to how your invoices look.
Table headers are the specific thing to check on an invoice. An invoice is a table, and a table without header scope is a grid of numbers with no relationship to the words above them. Most generators that do emit tags still drop the scope. That gap is the difference between tagged and conformant.
See what your invoice renderer actually emits. Post the HTML your platform already builds invoices from and read the report. It names every machine-checkable condition the file failed, by its Matterhorn number, so the answer is a list of specifics rather than a verdict.
100 documents a month on the free plan. No card, and nothing expires.