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
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.
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.
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”.
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.
{ "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 recipeThe endpoints involved
- Invoice CreatorLive
POST /api/v1/invoice/{countryCode}/{format}/generate
- ValidatorLive
POST /api/v1/invoice/{countryCode}/validate
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 comparisonHow it runs
- 1
Build the adapter: map your invoice object onto the field reference (/docs/api/schema).
- 2
POST /api/v1/invoice/DE/validate in tests, POST /api/v1/invoice/DE/zugferd/generate in the application.
- 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 plansLimits
- 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.