Which e-invoice standards are native public output today?

The public native output is Factur-X and ZUGFeRD PDF/A-3b with embedded EN 16931 CII XML. Check /api/v1/e-invoice/capabilities for the current contract.

Does gPdf generate the EN 16931 XML for me?

No. Your system provides the XML content. gPdf packages it into the PDF/A-3b e-invoice wrapper with the required attachment metadata.

Can I send settings.e_invoice to JSON Render?

No. E-invoice packaging belongs on POST /api/v1/e-invoice/render. The public docs state that settings.e_invoice is route-specific.

How should I validate output?

Use the gPdf validator or your own reference-engine workflow to check both the PDF/A layer and the embedded e-invoice XML layer.

Compliance and archival

E-Invoice API for Factur-X and ZUGFeRD PDF/A-3b

Generate Factur-X and ZUGFeRD PDF/A-3b e-invoices with embedded EN 16931 CII XML through the public gPdf e-invoice endpoint.

PRIMARY API E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTEMS ERP / finance backend / accounts receivable system / compliance workflow

Try in Playground → Read the docs

Job to be done

Package a human-readable invoice PDF and caller-provided EN 16931 CII XML into a Factur-X or ZUGFeRD PDF/A-3b e-invoice that can be validated by external PDF/A and e-invoice reference engines.

When to use this API

You need Factur-X or ZUGFeRD output, not only an ordinary invoice PDF.
Your system can provide correct EN 16931 CII XML for the invoice.
You need PDF/A-3b packaging, attachment metadata, and e-invoice XMP wiring.
You want the public capabilities endpoint to confirm supported standards and profiles.

What it does not replace

You only need an ordinary customer invoice PDF. Use JSON Render or Template Render.
You need native XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, or GST output before OpenAPI lists it.
You expect gPdf to create legally correct invoice XML from incomplete business data.

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 PDF/A-3b request.

{
  "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": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

What gPdf handles

Factur-X or ZUGFeRD PDF/A-3b packaging through POST /api/v1/e-invoice/render.
Embedding the caller-provided EN 16931 CII XML as the associated file.
PDF/A-3b wrapper metadata and standard-specific e-invoice XMP wiring.
Capabilities discovery through GET /api/v1/e-invoice/capabilities.

What your system owns

Invoice business semantics, tax rules, buyer/seller identifiers, and EN 16931 XML correctness.
Choosing whether Factur-X or ZUGFeRD is appropriate for the recipient workflow.
External acceptance testing with the receiver, AP automation system, or local compliance process.

Production checklist

Call /api/v1/e-invoice/capabilities before assuming a standard or profile.
Validate the EN 16931 CII XML before embedding it.
Run the output through /validator/ or your own reference-engine pipeline.
Keep ordinary invoice PDF generation and legal e-invoice packaging separate in code.
Log request IDs, standard, profile, XML source version, and validation evidence.

Claim boundaries

Native public e-invoice output is Factur-X / ZUGFeRD with EN 16931 CII XML.
Other national e-invoice names are market context unless OpenAPI lists them as supported standards.
gPdf packages caller-provided XML; your system remains responsible for XML business correctness.

One endpoint for the e-invoice package

The e-invoice endpoint exists because this workflow is not just “render an invoice PDF.” It must produce a PDF/A-3b wrapper with the correct associated file metadata and standard-specific XMP, while embedding the caller-provided EN 16931 CII XML.

Call POST /api/v1/e-invoice/render when the required output is Factur-X or ZUGFeRD. Use GET /api/v1/e-invoice/capabilities when your integration wants to confirm supported standards, profiles, document types, and XML formats before sending work.

What remains outside gPdf

The XML semantics remain your responsibility. gPdf cannot know whether an invoice number is legal, a tax amount is correct, a buyer identifier matches the trading partner, or a specific receiver will accept a business process variant. Generate and validate the XML upstream, then use gPdf for PDF/A-3b packaging and rendering.

Keep roadmap terms out of native-support claims

It is valid to discuss XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e, or GST as market context. Do not present those names as native public renderer output unless the OpenAPI capabilities contract lists them.

FAQ

Which e-invoice standards are native public output today?: The public native output is Factur-X and ZUGFeRD PDF/A-3b with embedded EN 16931 CII XML. Check /api/v1/e-invoice/capabilities for the current contract.
Does gPdf generate the EN 16931 XML for me?: No. Your system provides the XML content. gPdf packages it into the PDF/A-3b e-invoice wrapper with the required attachment metadata.
Can I send settings.e_invoice to JSON Render?: No. E-invoice packaging belongs on POST /api/v1/e-invoice/render. The public docs state that settings.e_invoice is route-specific.
How should I validate output?: Use the gPdf validator or your own reference-engine workflow to check both the PDF/A layer and the embedded e-invoice XML layer.