Which endpoint renders ZUGFeRD?

Use POST /api/v1/e-invoice/render with settings.e_invoice.standard set to zugferd.

Does this page cover XRechnung?

No. This page is limited to the public ZUGFeRD contract. XRechnung is not claimed as native output here.

Does gPdf create the CII XML?

Your system supplies the EN 16931 CII XML and owns its correctness.

Can I verify the result?

Use your ZUGFeRD validation workflow and the gPdf validator pages for validation context.

Compliance and archival

ZUGFeRD API for PDF/A-3b hybrid invoices

Generate ZUGFeRD PDF/A-3b invoices with embedded EN 16931 CII XML using the public gPdf E-Invoice Render endpoint.

PRIMARY API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTEMS ERP / billing backend / German finance workflow / compliance automation service

Try in Playground → Read the docs

Job to be done

Package invoice PDF output as ZUGFeRD PDF/A-3b with embedded EN 16931 CII XML after your ERP or billing system has prepared the correct invoice data.

When to use this API

You need native ZUGFeRD output from the public E-Invoice Render endpoint.
Your system already has valid EN 16931 CII XML for the invoice.
You need PDF/A-3b packaging with ZUGFeRD metadata and associated-file wiring.
You need a clear sibling page to the broader e-invoice and Factur-X pages.

What it does not replace

You need native XRechnung generation or portal submission.
You need gPdf to calculate tax, infer invoice semantics, or create XML from accounting records.
You need standards not listed in the public OpenAPI contract.

Which endpoint to call

PRIMARY

/api/v1/e-invoice/render

E-Invoice Render is the default path for this workflow.

SECONDARY 1

/api/v1/e-invoice/capabilities

Use this when the workflow needs the related API path, template contract, or capabilities lookup.

Minimal request

POST /api/v1/e-invoice/render - minimal ZUGFeRD package shape.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "zugferd",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "ZUGFeRD invoice",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

What gPdf handles

ZUGFeRD packaging through E-Invoice Render.
PDF/A-3b profile handling for hybrid invoice output.
Embedding CII XML as an associated file with ZUGFeRD metadata.
Inline PDF or object delivery behavior as documented.

What your system owns

EN 16931 CII XML correctness, invoice data, tax logic, buyer and seller semantics.
External validation, recipient requirements, portal submission, and legal interpretation.
Retry behavior, storage, audit evidence, and customer delivery.

Production checklist

Set settings.e_invoice.standard = zugferd and settings.e_invoice.profile = en16931.
Use CII XML with format = cii and encoding = utf8.
Set settings.profile to pdfa-3b or omit it so the e-invoice default applies.
Validate the returned PDF with your ZUGFeRD validation workflow.
Keep XRechnung or portal submission work outside this endpoint.

Claim boundaries

This page covers ZUGFeRD output through E-Invoice Render.
It does not claim native XRechnung generation.
Your system owns invoice business data and XML validity.

ZUGFeRD uses the e-invoice render path

ZUGFeRD is not a separate root endpoint. It is selected through the settings.e_invoice.standard field on POST /api/v1/e-invoice/render. The same boundary applies: gPdf packages the PDF/A-3b hybrid invoice; your system owns the invoice facts and XML validity.

FAQ

Which endpoint renders ZUGFeRD?: Use POST /api/v1/e-invoice/render with settings.e_invoice.standard set to zugferd.
Does this page cover XRechnung?: No. This page is limited to the public ZUGFeRD contract. XRechnung is not claimed as native output here.
Does gPdf create the CII XML?: Your system supplies the EN 16931 CII XML and owns its correctness.
Can I verify the result?: Use your ZUGFeRD validation workflow and the gPdf validator pages for validation context.