Compliance and archival

Factur-X API for hybrid PDF/A-3b e-invoices

Generate Factur-X PDF/A-3b invoices with embedded EN 16931 CII XML through the public E-Invoice Render endpoint.

PRIMARY API E-Invoice Render
ENDPOINT /api/v1/e-invoice/render
SYSTEMS ERP / billing backend / compliance workflow / finance automation service
Job to be done

Package a rendered invoice PDF as Factur-X PDF/A-3b with embedded EN 16931 CII XML after your ERP or billing system has produced the correct structured invoice data.

When to use this API

  • You need native Factur-X 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 Factur-X metadata and associated-file wiring.
  • You want the capabilities endpoint to confirm the currently published e-invoice contract.

What it does not replace

  • You need gPdf to create invoice business semantics or tax decisions for you.
  • You need native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, or other standards not listed in OpenAPI.
  • You need direct submission to Chorus Pro or another government portal.

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 Factur-X package shape.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "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": "Factur-X invoice",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

What gPdf handles

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

What your system owns

  • Correct EN 16931 CII XML, invoice numbers, tax logic, buyer and seller data, and eligibility.
  • External validation, recipient rules, portal submission, and legal interpretation.
  • Storage, audit trail, retry logic, and delivery to the customer or portal.

Production checklist

  1. Validate the CII XML before sending it to gPdf.
  2. Set settings.profile to pdfa-3b or omit it so the e-invoice default applies.
  3. Use settings.e_invoice.standard = factur_x and settings.e_invoice.profile = en16931.
  4. Run the returned PDF through your Factur-X validator workflow.
  5. Keep submission and recipient routing outside the render API.

Claim boundaries

  • Native public e-invoice output is Factur-X or ZUGFeRD with EN 16931 CII XML.
  • gPdf does not submit invoices to government or buyer portals.
  • Your system owns business, tax, and XML correctness.

Factur-X is an e-invoice packaging workflow

Factur-X combines a human-readable PDF with machine-readable EN 16931 CII XML. The public gPdf endpoint packages that combination into PDF/A-3b output. It does not decide the invoice semantics or submit the file to a portal.

FAQ

Which endpoint renders Factur-X?
Use POST /api/v1/e-invoice/render with settings.e_invoice.standard set to factur_x.
Does gPdf generate the EN 16931 XML?
Your system supplies the CII XML and owns its business correctness. gPdf packages it into the hybrid PDF.
Does gPdf support XRechnung on this page?
No. This page is limited to the public Factur-X contract listed in OpenAPI.
Does gPdf submit Factur-X invoices to portals?
No. Submission and recipient routing remain outside the render API.