Accessible E-Invoices: XRechnung and ZUGFeRD for Everyone

An invoice is not just any document but a record with legal and financial weight. Anyone who cannot read it independently depends on others - and loses a piece of autonomy over their own finances. For blind and visually impaired people, the technical preparation alone decides whether an invoice can be read aloud or ends up as an impenetrable surface in the screen reader. In Germany, around 7.9 million (Federal Statistical Office) people live with a severe disability, which is 9.3 percent (Federal Statistical Office) of the population; worldwide, according to the World Health Organization, about one in six people, roughly 16 percent (WHO), live with a significant disability. Documents that exclude these people are not a fringe issue.

The e-invoice mandate sharpens the situation because it multiplies the volume of structured invoices. Millions of documents that used to be plain paper or simple PDFs now run through automated output pipelines. This is exactly where it is decided whether accessibility is considered or falls by the wayside. Automatically generated PDFs are especially prone to failure: without deliberate configuration, many invoicing systems produce a visually correct but technically structureless document. Anyone who knows the BFSG requirements for digital documents can set this switch correctly early - before thousands of faulty documents are in circulation.

This is where the most common misconception hides. ZUGFeRD PDFs follow the PDF/A-3 standard (ISO 19005-3). This standard ensures that a document is stable for long-term archiving and that foreign files - here the XML invoice - may be embedded. Yet PDF/A-3 has nothing to do with accessibility: the widely used conformance level requires no tagged structure, no defined reading order and no alternative text. A PDF can therefore be fully compliant with PDF/A-3 and at the same time unusable for a screen reader. Accessibility is governed by a different standard: PDF/UA (ISO 14289-1) describes how a PDF becomes usable for assistive technology. Only when a document meets both standards is it archive-proof and accessible.

The two standards do not exclude each other; on the contrary, a document can be both PDF/A-3 and PDF/UA if it is generated from the outset with tags, reading order and text alternatives. This very combination is the goal for consumer documents. In accessible PDF preparation we therefore check not only whether a document is valid as ZUGFeRD but whether its visible side meets the PDF/UA criteria - and where the invoicing system needs adjusting so that this succeeds automatically. The methodology behind it matches a structured WCAG audit that transfers the same checks to documents.

Here a distinction is decisive that often gets lost. The e-invoice obligation comes from tax law and concerns trade between companies. The BFSG, by contrast, implements the European Accessibility Directive (Directive 2019/882, European Commission) and targets offerings for consumers. The two worlds meet where a company also uses the same invoicing pipeline for its consumer documents. A document in electronic commerce, a bank's fee information or a telecommunications bill falls within the scope of the BFSG - and then the human-readable document must be accessible since 28 June 2025 (Bundesfachstelle Barrierefreiheit). Microenterprises with fewer than ten employees and at most two million EUR (BFSG) in annual turnover are exempt for services; for many mid-sized online retailers, financial service providers and passenger transport operators, however, the obligation applies without restriction.

The path to an accessible invoice leads through the template, not the individual document. Once the output pipeline is cleanly configured, every document is generated accessibly by default. The following checklist summarizes what matters.

In practice it is worth looking at the toolchain: where is the PDF created, which library generates it, and can tagging be enabled there? Technical publications such as those from PDFlib and barrierefreies.design stress that the ZUGFeRD visualization must meet the requirements of PDF/UA in its own right - the embedded data record alone does not make the document accessible. We build this check into accessible web development and our other services, so that invoices, confirmations and forms become accessible from a single source. That accessibility and discoverability often flow from the same clean structure is shown in addition by the article on the double lever of accessibility and SEO.

In 2026 the e-invoice mandate and the BFSG hit the same workflow in many companies at the same time. This is not a double burden but an opportunity: anyone who sets up the output pipeline correctly once meets both requirements at once and, along the way, reaches an audience that others exclude. A technical migration thus becomes a sign of reliability towards all customers. How this can be implemented in concrete projects is shown by our reference projects; adjacent topics such as accessible appointment booking follow the same logic of turning obligation into usable substance.