PDF Days Europe 2020 — Cancelled / Online Pivot: PDF 2.0 Corrigendum and Pandemic Impact on PDF Workflows
PDF Days Europe 2020 was originally planned as an in-person event in Berlin but pivoted to online sessions due to the COVID-19 pandemic. Virtual sessions covered the ISO 32000-2:2020 corrigendum addressing PDF 2.0 specification errata, the abrupt surge in electronic document workflows, digital signing needs created by lockdowns, and early discussions that would lead to PDF/UA-2.
Official event page →Key takeaways
- COVID-19 created an immediate, urgent e-signature adoption surge — law firms, financial services, real estate, and healthcare moved to electronic workflows within weeks.
- Remote qualified certificate issuance (video-based identity verification) was validated as technically and legally viable, removing the in-person barrier to qualified signatures.
- PDF/A-3 with ZUGFeRD/Factur-X and XRechnung found a major adoption driver in electronic invoicing mandates for B2G procurement.
- The virtual format proved accessible to a much wider geographic audience but could not replace informal networking and hands-on workshop interactions.
- Session recordings from the virtual event created a lasting resource for the PDF developer community beyond the live event.
Electronic signature surge during COVID-19
PDF/A-3 and electronic invoicing
ZUGFeRD-invoice.xml or factur-x.xml) that can be parsed by accounting systems. The PDF/A-3 container is the archival presentation; the XML is the machine-readable data. This hybrid approach is required by Germany's X-Rechnung mandate for B2G (business-to-government) invoices and is widely used for B2B invoicing in Germany, France, and other European countries.
XRechnung — Germany's mandatory electronic invoice format for invoices to federal public authorities. XRechnung is pure XML (following the EN 16931 European Invoice standard) and can optionally be embedded in a PDF/A-3 container using the Factur-X/ZUGFeRD model. The PDF/A-3 wrapping makes XRechnung invoices readable by recipients who cannot process raw XML.
PDF/A-3 verification challenges — Validating a PDF/A-3 document with embedded ZUGFeRD XML requires validating both the PDF/A-3 container (with veraPDF) and the embedded XML structure (against the ZUGFeRD/Factur-X schema). Tools like Mustang Project (Java) provide both PDF/A-3 creation and ZUGFeRD XML validation in a single library.The virtual conference format: lessons and legacy
Frequently asked questions
What is ZUGFeRD and how does it use PDF/A-3?
ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a German standard for electronic invoices that embeds structured XML data inside a PDF/A-3 container. The PDF provides a human-readable invoice presentation; the embedded XML (following the EN 16931 European Invoice standard) provides machine-readable data for automated processing by accounting systems. The current version is ZUGFeRD 2.x, which aligns with the European Factur-X standard. The embedded file must be attached to the PDF/A-3 document with a specific conformance level designation in the /AFRelationship entry. French implementations use the Factur-X name for the same technical specification. ZUGFeRD is required for invoices to German federal authorities (under the E-Rechnungsverordnung) and is widely adopted for B2B invoicing in Germany and France.
Did COVID-19 change the legal requirements for electronic signatures?
COVID-19 did not change the underlying legal frameworks for electronic signatures (eIDAS in the EU, ESIGN/UETA in the US) but prompted several jurisdictions to issue guidance clarifying existing laws and, in some cases, temporary regulations. In the UK, HM Land Registry issued practice guidance clarifying that electronic signatures using platforms like DocuSign are valid for property transactions under existing law. Several US states issued executive orders temporarily expanding the use of remote notarization. The EU Commission issued guidance confirming that qualified electronic signatures via remote identity verification were valid under eIDAS. Post-pandemic, most of these clarifications and temporary measures were either made permanent or incorporated into updated regulations — the net effect was a permanent expansion of accepted electronic signature use cases rather than a temporary crisis accommodation.
What is PDF/A-3 and how does it differ from PDF/A-1 and PDF/A-2?
PDF/A-1 (2005) and PDF/A-2 (2011) are strict archiving formats that require the PDF to be self-contained — no external references, all fonts embedded, no JavaScript. The key constraint is that embedded file attachments (other than ICC profiles and XMP) are not permitted. PDF/A-3 (2012) relaxes this one constraint: it allows embedding arbitrary file types (XML, CSV, Excel spreadsheets, source files, etc.) as attachments within a PDF/A compliant container. The PDF/A-3 container itself must still meet all PDF/A-2 requirements; only the embedded attachments are unrestricted. The /AFRelationship entry in the embedded file specification must declare the relationship type (Source, Data, Alternative, Supplement, or Unspecified). PDF/A-3 is the format used for ZUGFeRD/Factur-X hybrid invoices and any other workflow where a human-readable archival PDF must carry embedded machine-readable data.
Try it in your browser
The PDF tools and standards discussed at this event are available free — no account needed.