Is an invoice PDF the same as an e-invoice?

No. An ordinary invoice PDF is human-readable output. A Factur-X or ZUGFeRD e-invoice also embeds EN 16931 CII XML inside a PDF/A-3b wrapper.

Which endpoint should repeated invoices use?

Use Template Render when the invoice layout is stable and callers should only send template_id plus data. Use JSON Render when code owns the layout.

Does gPdf calculate taxes?

No. Your billing or accounting system calculates taxes, totals, discounts, and payment state before sending render data.

Can invoice PDFs use PDF/A?

Yes, JSON Render supports PDF/A settings. Use E-Invoice Render specifically when the invoice must be packaged as Factur-X or ZUGFeRD.

Invoicing and finance

Invoice PDF API for billing and finance systems

Generate ordinary invoice PDFs from billing data with JSON Render or Template Render, while keeping tax and accounting logic in your system.

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS billing backend / ERP / accounting system / SaaS app

Try in Playground → Read the docs

Job to be done

Turn invoice data from a billing, ERP, or SaaS system into a readable PDF invoice while keeping numbering, tax, payment state, and accounting semantics inside the caller's system.

When to use this API

You need ordinary invoice PDFs for customers, receipts, statements, or accounting exports.
Your system already owns invoice numbers, tax calculation, line items, and payment state.
You want tables, totals, metadata, and optional PDF/A settings without running a browser.
You want a template_id contract for repeated invoice layouts.

What it does not replace

You need a legal e-invoice package such as Factur-X or ZUGFeRD. Use E-Invoice Render.
You expect gPdf to calculate tax, validate accounting rules, or reconcile payments.
You want arbitrary HTML invoice conversion instead of structured JSON or templates.

Which endpoint to call

PRIMARY

/api/v1/pdf/render

JSON Render is the default path for this workflow.

SECONDARY 1

/api/v1/template-render

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

SECONDARY 2

/api/v1/e-invoice/render

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

Minimal request

POST /api/v1/pdf/render - minimal invoice header and total.

{
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Invoice INV-1007",
          "style": { "font_size": 18, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "text",
          "x": 20,
          "y": 42,
          "content": "Bill to: Example Customer\nAmount due: USD 245.00",
          "style": { "font_size": 11, "font_family": "NotoSans-Regular" }
        },
        {
          "type": "line",
          "x1": 20,
          "y1": 62,
          "x2": 190,
          "y2": 62
        }
      ]
    }
  ]
}

What gPdf handles

Invoice PDF rendering from JSON pages or template data.
Text, tables, totals blocks, pagination, metadata, and optional PDF/A output.
Template Render for stable invoice layouts used by multiple systems.
Binary PDF response and consistent API error envelope.

What your system owns

Invoice numbers, payment state, tax calculation, discounts, credits, and ledger meaning.
Customer and issuer data, line-item mapping, currencies, and rounding rules.
Retention, delivery, email, payment links, and accounting-system reconciliation.

Production checklist

Confirm every visible invoice field maps to source billing data.
Test line-item overflow, long customer names, multi-page invoices, and totals.
Decide whether the layout belongs in JSON Render or a published template.
Keep ordinary invoice PDF generation separate from legal e-invoice packaging.
Store request IDs and output filenames with your invoice records.

Claim boundaries

Ordinary invoice PDFs are not the same as legal e-invoice mandates.
gPdf renders the invoice document; it does not calculate tax or accounting state.
Factur-X / ZUGFeRD output belongs on POST /api/v1/e-invoice/render.

Ordinary invoices versus e-invoices

An ordinary invoice PDF is the document your customer reads. It can be generated from JSON Render or Template Render. Your system decides the invoice number, taxes, line items, currency, and payment state, then gPdf renders the visible PDF.

A legal e-invoice is different. Factur-X and ZUGFeRD combine a readable PDF/A-3b invoice with embedded EN 16931 CII XML. Use POST /api/v1/e-invoice/render for that package.

Template Render is usually the production endpoint

Finance teams rarely want every service to rebuild invoice coordinates. The common path is to design the invoice once, publish it as a template, and give callers a stable template_id plus a data schema. JSON Render stays useful for custom layouts, internal tools, and template prototyping.

Keep accounting logic upstream

gPdf should receive final display values, not unresolved accounting decisions. Compute tax, discounts, rounding, payment status, and invoice eligibility before calling the render API. That makes the PDF output deterministic and keeps the financial system as the source of truth.

FAQ

Is an invoice PDF the same as an e-invoice?: No. An ordinary invoice PDF is human-readable output. A Factur-X or ZUGFeRD e-invoice also embeds EN 16931 CII XML inside a PDF/A-3b wrapper.
Which endpoint should repeated invoices use?: Use Template Render when the invoice layout is stable and callers should only send template_id plus data. Use JSON Render when code owns the layout.
Does gPdf calculate taxes?: No. Your billing or accounting system calculates taxes, totals, discounts, and payment state before sending render data.
Can invoice PDFs use PDF/A?: Yes, JSON Render supports PDF/A settings. Use E-Invoice Render specifically when the invoice must be packaged as Factur-X or ZUGFeRD.