gPdf render/edge
Use cases · EU e-invoicing & finance

EU e-invoices: PDF/A-3 with embedded Factur-X / ZUGFeRD

Generate EN 16931 e-invoices from JSON — PDF/A-3 wrapper with embedded CII XML attachment, Factur-X or ZUGFeRD compliant. Verify both layers free at gpdf.com/validator/.

Job to be done

Issue EU-compliant electronic invoices from a JSON DocumentRequest: a PDF/A-3 wrapper that an AP team can read, with an embedded CII XML attachment conforming to EN 16931 that a tax authority can machine-process. One API call must produce both — and both must validate against reference engines, not just the vendor's own checker.

Why gPdf for this

  • POST /api/v1/e-invoice/render — single endpoint, returns a Factur-X or ZUGFeRD PDF/A-3 in one round trip.
  • PDF/A-3b wrapper auto-emitted with the correct XMP namespace, AFRelationship='Alternative' and embedded-file metadata per the Factur-X / ZUGFeRD baseline.
  • EN 16931 CII XML attached as the canonical structured payload — readable by AP automation tools across the EU.
  • Strict-validation mode runs full Schematron checks asynchronously and returns a report artifact alongside the PDF.
  • Data residency profiles (`eu` / `global` / `auto`) so AP/AR teams subject to GDPR can keep e-invoice artifacts inside EU regions.
  • Free public validator at gpdf.com/validator/ runs veraPDF (PDF/A side) AND Mustang (CII XML / EN 16931 side) in parallel — independent verification before you wire it to production.

Sample request

POST /api/v1/e-invoice/render — minimum Factur-X request with embedded CII XML.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    { "size": "a4", "elements": [] }
  ]
}

Compliance and conformance

  • Factur-X 1.0 — joint Franco-German specification, mandatory for French B2B invoices from 2026 (phased).
  • ZUGFeRD 2.x — German specification, EN 16931 conformant; mandatory for German B2B receipt-of-invoice from 2025.
  • EN 16931 — the pan-EU semantic model for e-invoices that both Factur-X and ZUGFeRD wrap.
  • PDF/A-3 — the archival wrapper format required to legally hold an embedded XML attachment (ISO 19005-3).
  • Validation: don't trust a single vendor's self-check. Independent verification with veraPDF (PDF/A) + Mustang (CII XML) is the audit-grade pattern.

The shape of an EU e-invoice (and why it’s two formats stacked)

A modern EU e-invoice is two documents wrapped in one file:

  1. A PDF/A-3 that a human can read — invoice number, line items, totals, supplier branding. The PDF/A-3 spec (ISO 19005-3) is the only PDF/A variant that allows arbitrary file attachments inside the archival wrapper.
  2. An EN 16931 CII XML attachment inside that PDF — the same invoice expressed as structured data that AP automation, ERP imports and tax-authority systems can parse without OCR.

Factur-X (France) and ZUGFeRD (Germany) are the same idea, different national labels. Both attach an EN 16931 Cross-Industry Invoice (CII) XML to a PDF/A-3 wrapper. ZUGFeRD has been mandatory for German B2B invoice receipt since 2025; Factur-X is phasing into mandatory B2B issuance in France through 2026–2027.

If you’re sending invoices to French or German customers in 2026, one of these two formats is no longer optional.

Why generating it from scratch is painful — and why gPdf is one endpoint

Stitching this together from scratch involves:

  1. Generating PDF bytes (typesetting, fonts, layout).
  2. Generating the CII XML separately, matching EN 16931.
  3. Setting the PDF/A-3 XMP namespace correctly (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# for Factur-X; the ZUGFeRD 2.x namespace differs).
  4. Embedding the XML with AFRelationship="Alternative" per spec.
  5. Marking the embedded file in PDF/A-3’s /AF array correctly.
  6. Validating the result with veraPDF (PDF/A side) AND Mustang (CII XML side) — both must pass.

A typical team gets this wrong twice before it passes both engines. The gPdf API collapses all six steps into a single POST /api/v1/e-invoice/render call. You provide:

  • settings.e_invoice.standard — factur_x or zugferd
  • settings.e_invoice.xml.content — your CII XML
  • pages[] — the visible invoice layout
  • everything else is auto-emitted with the correct PDF/A-3 metadata.

See §5 of the E-Invoice API reference for the full request schema, validation modes (basic vs strict), and async job lifecycle for strict-validation runs.

Verifying the output — the audit pattern

A vendor saying “yes our PDF passes PDF/A-3” is worth nothing if the audit auditor uses the reference engines. The audit-grade pattern is:

  1. Generate the e-invoice via POST /api/v1/e-invoice/render.
  2. Drop the resulting PDF into validator — runs:
    • veraPDF: the official reference implementation maintained by the PDF Association. PDF/A-3 conformance.
    • Mustang: open-source German project (mustangproject.org) that is the de-facto Factur-X / ZUGFeRD reference checker — extracts the embedded CII XML, validates against EN 16931 Schematron, reports field-by-field.
  3. Both reports return side-by-side in the same UI. Both must show “Pass” before you ship to production AP automation.

This pattern matters because:

  • A PDF that passes veraPDF but fails Mustang means the wrapper is conformant but the XML inside is malformed — the AP system rejects the invoice on receipt.
  • A PDF that passes Mustang but fails veraPDF means the XML is fine but the archival wrapper doesn’t satisfy PDF/A-3 — long-term archival rejected.
  • Either failure breaks the end-to-end flow. Both must pass.

The validator is free, requires no login, and produces JSON reports you can attach to your QA evidence. It’s the same dual-engine pattern Big-Four audit firms use internally — gPdf just hosts it publicly.

Beyond Factur-X / ZUGFeRD

If you’re also working with:

  • FatturaPA (Italy, mandatory since 2019) — already on the validator roadmap.
  • Peppol BIS 3.0 UBL (Nordic / Benelux / increasingly cross-border) — roadmap.
  • KSeF (Poland, mandatory 2026) — roadmap.

gPdf’s e-invoice endpoint will extend coverage as each format graduates from “early roadmap” to “live in the validator and the renderer”. The shape is the same: one JSON request, the right XMP namespace and AFRelationship handled internally, both engines verify before you ship.

TL;DR

  • One API call → PDF/A-3 + embedded EN 16931 CII XML.
  • Choose Factur-X or ZUGFeRD via settings.e_invoice.standard.
  • Verify with validator — veraPDF + Mustang in parallel, free.
  • Both engines must pass. The gPdf API is built so they do; the validator is the public receipt.

Keep reading