Build e-invoicing into your own product

Creator, validator and your own PDF templates behind your UI — without keeping a format specialist.

Your product already writes invoices. What is missing is the format: XRechnung, ZUGFeRD and the rules that move with every revision. Instead of running a format library, you call two endpoints — generate and validate — and keep your UI, your numbering and your layout. The PDF template is a JSON document you override per tenant, so the invoice looks like your customer and not like us.

What comes in

The invoice record from your application — header, parties, line items, totals

Tenant master data: logo, colors, bank details, tax numbers

Your PDF template as BlockTemplate JSON

The target format per recipient: XRechnung, ZUGFeRD or PDF

What this solves

01

Two endpoints instead of a format library

Generating and validating are two calls behind one adapter. What moves in the rules moves on our side — not inside your release cycle.

02

Your layout, not ours

Invoice templates are JSON in the BlockTemplate format: placeholders, design tokens for colors and font sizes, nine block types. Logo and brand colors are overridden per tenant.

03

Errors your support can act on

The response names the rule code and the field. Your support reads which master-data field the tenant is missing, instead of forwarding “invoice failed”.

04

Switching vendors stays an adapter

XRechnung, ZUGFeRD and Peppol BIS 3.0 are public standards under EN 16931. What the API produces stays valid without us and remains processable by other systems.

One real example

An excerpt from the recipe “Generate and send a ZUGFeRD PDF” — the fields ZUGFeRD requires on top of XRechnung.

json
{
"invoice": {
"seller": {
"bankAccount": {
"iban": "DE89370400440532013000",
"bic": "COBADEFFXXX"
}
},
"paymentTerms": {
"dueDays": 30,
"description": "Zahlbar innerhalb von 30 Tagen"
},
"subtotal": 1500,
"total": 1785
}
}

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

Response: a Base64-encoded PDF/A-3 with embedded EN 16931 XML over 1,785.00 €. Without IBAN, BIC and the payment term, generation fails — unlike XRechnung, they are mandatory here.

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 is running a library yourself — Mustang, for instance. Then the process next door, the format versions and the question of who updates the Schematron on a Friday evening are yours too.

Read the comparison

How it runs

  1. 1

    Build the adapter: map your invoice object onto the field reference (/docs/api/schema).

  2. 2

    POST /api/v1/invoice/DE/validate in tests, POST /api/v1/invoice/DE/zugferd/generate in the application.

  3. 3

    Handle errors by class: never retry 4xx, retry 5xx with growing backoff, delay on 429.

What it costs at this volume

Around 5,000 invoices per month fit the Premium plan at 79 € per month.

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

All plans

Limits

  • Peppol dispatch is not available yet (planned 2027); generating and checking Peppol BIS 3.0 works today.
  • Webhook callbacks do not exist yet — the result is in the response of the call.
  • Template upkeep per tenant stays with you: we supply the format, not your customers' corporate design.

Frequently asked questions

How deeply do I need to understand the format?

As deeply as the fields you fill. The field reference gives type, whether it is mandatory and what it means; the rules behind them are checked by the validate endpoint.

Can I adapt the PDF layout to my customers' corporate design?

Yes. Invoice templates are JSON documents in the BlockTemplate format with placeholders and design tokens for colors and font sizes; logo and brand colors are overridden per tenant.

What happens to my customers' invoices if you disappear?

XRechnung, ZUGFeRD and Peppol BIS 3.0 are public standards under EN 16931. Every generated invoice stays valid and processable by other providers; a switch would affect your adapter, not your invoicing.

E-invoicing inside your own product — without keeping a format specialist.