From your existing PDF to an e-invoice — without changing the template

Your invoice template stays as it is. The machine-readable XML is created alongside it.

Today the invoice is written in Word, Excel or a vertical application and leaves the house as a PDF. What the e-invoicing mandate asks for is not a new look but structure: number, date, parties, line items and tax amounts as fields instead of text. The API takes exactly those fields and returns a PDF/A-3 that looks like before and carries the embedded EN 16931 XML. Keeping your template does not require changing your invoicing software.

Request an integration Get Started

What comes in

A PDF invoice from Word, Excel or a vertical application

Line items with quantity, unit, unit price and tax rate

Seller master data: address, VAT ID, IBAN, payment term

Recipient data from the address block, plus the Leitweg-ID for public bodies

What this solves

The template stays where it is

No new invoicing software, no new layout, no training. Your template keeps producing the look; the API produces the structure the recipient has to read.

One PDF is not automatically one invoice

A combined PDF can hold several invoices. Assuming one invoice per file loses the second one with no error at all. The mapping therefore starts at the invoice, not at the file.

Mandatory fields that are only text in a PDF

Tax category, unit, payment term and a reachable contact sit in the PDF as running text. As fields they are missing — which is exactly where a first XRechnung fails. Validation names the rule and the field before the invoice leaves.

The recipient still sees a PDF

ZUGFeRD is a PDF/A-3 with conformant embedded XML. People read the page, systems read the attachment — nobody has to move to a format they cannot open.

One real example

An excerpt from the recipe “Generate and send a ZUGFeRD PDF” — the same fields that are only text in today's PDF.

json

{
  "invoice": {
    "invoiceNumber": "RE-2025-002",
    "issueDate": "2025-01-15",
    "seller": {
      "name": "Muster GmbH"
    },
    "buyer": {
      "name": "Beispiel AG"
    },
    "items": [
      {
        "position": 1,
        "description": "Beratungsleistung",
        "quantity": 10,
        "unit": "HUR",
        "unitPrice": 150,
        "taxRate": 19,
        "netAmount": 1500,
        "taxAmount": 285,
        "grossAmount": 1785
      }
    ],
    "subtotal": 1500,
    "total": 1785
  }
}

POST /api/v1/invoice/DE/zugferd/generate

Response: a Base64-encoded PDF/A-3 with embedded EN 16931 XML. The line item computes 10 × 150.00 € = 1,500.00 € net, 19 % adds 285.00 € tax, total 1,785.00 € — the same values that appear in the input above.

The full recipe

The endpoints involved

Invoice Creator
POST /api/v1/invoice/{countryCode}/{format}/generate
Live
Validator
POST /api/v1/invoice/{countryCode}/validate
Live

Compared to the alternative

The alternative to this route is switching invoicing software and rebuilding the template. That solves e-invoicing too — at the price of the template you grew, your numbering and the retraining.

Read the comparison

How it runs

1
Get the invoice data out of the template — as an export or through fixed rules per template type. Without a language model: a rule that is wrong is visible, a model that guesses is not.
2
POST /api/v1/invoice/DE/zugferd/generate with the fields from step 1.
3
Decode the response, save it as a PDF and send it by email as before.

What it costs at this volume

Around 300 invoices per month fit the Starter plan at 23 € per month.

All prices net, plus VAT · 20 % off when billed annually · Free tier without a credit card

All plans

Limits

The API does not read a PDF: it takes fields. Getting those fields out of your template stays the step before.
Peppol dispatch is not available yet (planned 2027). Generating and checking Peppol BIS 3.0 works today.
Audit-proof archiving is not part of the API (Archive API planned 2027).

Where to go next

Recipe: generate and send a ZUGFeRD PDF

n8n template: PDF invoice per department to e-invoice

From practice: what the first pipeline cost us

Field reference of the invoice object

Frequently asked questions

Do I have to change my invoice template?

No. What is needed are the values, not the layout. As long as number, date, parties, line items and tax amounts can be extracted from your template, the page stays as it is.

Does the API read an existing PDF?

The parse endpoint reads e-invoices — XML and PDFs with embedded XML. A PDF without embedded data holds no structured fields; on this route they come from your template, not from the picture.

What happens when one PDF holds two invoices?

Then it is two operations. The mapping has to work per invoice, otherwise the second one disappears silently — the most expensive mistake of our first real pipeline.

From the template you have to an e-invoice — without touching the template.

Request an integration Get Started