An electronic invoice can look correct to a person while carrying different or invalid information for an accounting system. That risk matters with hybrid formats such as ZUGFeRD and Factur-X, which combine a visible PDF with structured invoice data. A recent API release makes this two-layer workflow easier to automate—and gives finance teams a useful reason to review both layers.
What changed
pdfRest's 17 September 2026 release added `/zugferd-pdf` and `/validated-zugferd` endpoints for creating and validating ZUGFeRD invoice PDFs. A 24 September follow-up improved invoice processing and the clarity of error messages. These are developer-facing API capabilities, not a feature that has appeared automatically in every PDF reader or accounting package.
The underlying format is broader than one product. The Forum elektronische Rechnung Deutschland explains that ZUGFeRD embeds structured XML invoice data inside a PDF/A-3 document. The PDF is the human-readable view; the XML allows software to process the invoice. Its current information package is ZUGFeRD 2.5.2, dated 4 August 2026. Factur-X is the technically aligned French name for the same hybrid approach.
A safer two-layer invoice workflow
1. Confirm the required format and profile. Ask the recipient, accounting provider or relevant authority which version and profile they accept. A file being called “ZUGFeRD” is not enough to prove it matches the required rules. 2. Generate both views from one approved data source. Avoid separately retyping the visible invoice and the XML. Using the same source data reduces the chance that totals, tax values or customer details drift apart. 3. Validate the structured layer. Use a validator that checks the required XML schema, business rules and invoice profile. Read every error and warning; a PDF opening successfully does not prove the embedded data is valid. 4. Compare the visible and machine-readable facts. Check supplier and customer identities, invoice number, dates, currency, line totals, tax and final amount in both representations. FeRD specifically recommends controls that keep the PDF and XML content identical. 5. Preserve the received electronic original. Store the validated file without passing it through an ordinary PDF editor. Follow the retention and audit requirements that apply to the organisation and country; a printed copy does not preserve the machine-readable layer.
Important limits
A successful API response or technical validation is not a guarantee of tax, accounting or legal compliance. National rules, accepted profiles and migration dates can differ. The European Commission notes that EN 16931:2026 was published in May 2026, while the 2017 version remains compliant during a migration period whose details are still being developed by relevant authorities.
General PDF editing may also change the file after validation or fail to preserve embedded data. Test the exact system that receives, stores and forwards the invoice. Keep audit logs and rejected-file messages where your process requires them.
FileStation does not create, extract or validate ZUGFeRD/Factur-X XML and does not certify PDF/A-3 conformance. You may use PDF Reader for an ordinary visual check and the CLEAR document check for visible handoff mistakes, but use approved e-invoicing software for the structured layer. The dependable result comes from treating the PDF and XML as one controlled invoice, not two unrelated files.
Primary sources: pdfRest API Toolkit release notes, FeRD: ZUGFeRD/Factur-X standard and European Commission guidance on EN 16931.