7 rule sets · One key · Live on mandatory dates

One e-invoicing API for Germany, France, the Netherlands, Norway and Peppol

Each European mandate names its own format, and building them one integration at a time is how compliance projects multiply. Here the country is a parameter: the same invoice JSON goes in, and the right national document comes out, validated against that authority's own rules. Below is the exact coverage, endpoint by endpoint.

Get your free API key See the coverage table

Same invoice, Dutch rules

curl -X POST https://api.invoicexml.com/v1/create/ubl \
  -d '{ "invoice": { ... },
     "options": { "profile": "nlcius" } }'
// peppol-bis-3 · nlcius · ehf · pint

Same invoice, French rules

curl -X POST https://api.invoicexml.com/v1/create/facturx \
  -d '{ "invoice": { ... },
     "options": { "rules": ["br-fr"] } }'
// hybrid PDF/A-3, BR-FR Flux 2 checked

Coverage

Country by country, endpoint by endpoint

This table is limited to what the code actually covers. Every rule set is the issuing authority's own artifact, and validation always reads the document's identifier to pick the rulebook, so received files route themselves.

Country	Format & rule set	Create with	What we run
Germany	XRechnung and ZUGFeRD	/v1/create/xrechnung /v1/create/zugferd	The KoSIT XRechnung 3.0 artifacts, and the official Factur-X/ZUGFeRD Schematron per profile
France	Factur-X, MINIMUM to EXTENDED-CTC-FR	/v1/create/facturx	All profiles including EXTENDED-CTC-FR, plus the BR-FR Flux 2 rules via `options.rules`
Netherlands	NLCIUS (SI-UBL 2.0)	/v1/create/ubl · nlcius	SI-UBL 2.0.3.13, the Dutch Peppol Authority's own artifact, BR-NL rules included
Norway	EHF Billing 3.0	/v1/create/ubl · ehf	The BIS artifact including the Norwegian NO-R rules, which trigger on Norwegian suppliers
Belgium & the Nordics	Peppol BIS Billing 3.0	/v1/create/ubl · default	BIS 3.0.21, the release enforced network-wide since 17 August 2026, the default profile
Beyond EuropeAU & NZ, Singapore, Japan, Malaysia	Peppol PINT	/v1/create/ubl · pint	PINT Billing 1.1.3 base rules; jurisdiction variants are accepted and checked against the base set

Cross-syntax needs are covered too: UBL ↔ CII conversion, rendering any of these documents to a readable PDF, and extraction back to JSON for everything you receive. Who mandates what, and from when, is tracked on the Mandate Map.

Release autopilot

Seven authorities publish on their own calendars. You follow none of them.

KoSIT, FNFE-MPE and FeRD, the Dutch Peppol Authority, OpenPeppol: each revs its rule set on its own schedule, each with a date the old release stops being accepted. We vendor every artifact unmodified, regression-test it, and switch server-side on the mandatory day. A multi-country integration that needed seven update calendars now needs zero.

See the update policy and the exact artifacts live right now

Rule sets on autopilot

7 of 7

XRechnung, ZUGFeRD, Factur-X, BR-FR, NLCIUS, EHF and Peppol BIS with PINT all update server-side on their mandatory dates, with no change to your integration.

xrechnung facturx nlcius ehf peppol-bis-3 Live

For developers

Plan the rollout, then build it

E-Invoicing Mandate Map Every country's timeline, model, and deadlines Peppol API hub The network side: BIS, EHF, NLCIUS, PINT in depth API reference: create Every profile, option, and response field Update policy The exact artifact versions live right now

Compliance

Secure by Architecture

Your invoices are processed in memory and returned in the same response. Zero data retention is not a policy we enforce, it is an architecture we built.

Zero data retention

Processed in volatile memory only. Never written to disk, never queued, never backed up.

EU-only processing

Servers in Frankfurt, Germany. No transfers outside the European Economic Area.

No use of your data

Never used for analytics, never to train AI models, never shared with third parties.

Certified infrastructure

SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.

Read the full security overview

GDPR compliant by design · nothing stored on our servers

Coverage questions, answered

Which countries does one API key cover?

Germany (XRechnung and ZUGFeRD), France (Factur-X, including EXTENDED-CTC-FR and the BR-FR rules), the Netherlands (NLCIUS), Norway (EHF), every market that runs on Peppol BIS Billing 3.0, and the PINT countries beyond Europe: Australia, New Zealand, Singapore, Japan, and Malaysia. One key, one JSON model; the country is an options.profile value or its own endpoint.

Do you deliver invoices over Peppol, or by email?

This is the document layer: we make sure what you send is compliant, and we read what you receive. Delivery over the Peppol network is the transport layer, handled by whichever registered access point you contract. The two halves pair cleanly: what you hand over for transport has already passed the checks the network runs.

How do I pick the right rule set per country?

German documents have their own endpoints: /v1/create/xrechnung and /v1/create/zugferd. France runs through /v1/create/facturx, with options.rules set to br-fr when the French business rules apply. Everything UBL-based goes through /v1/create/ubl with options.profile: peppol-bis-3 (the default), nlcius, ehf, or pint. On validation you pick nothing: the document's own identifier decides which rulebook runs.

What about Australia, New Zealand, Singapore, Japan, and Malaysia?

They run PINT, the international extension of Peppol billing. We create and validate against PINT Billing 1.1.3, the base rule set, selected with options.profile set to pint. Documents declaring a jurisdiction variant are accepted and checked against those base rules.

How do the country rules stay current?

Every rule set is the authority's own artifact, vendored unmodified: KoSIT for XRechnung, FNFE-MPE and FeRD for Factur-X and ZUGFeRD, the Dutch Peppol Authority for NLCIUS, OpenPeppol for BIS and PINT. New releases go live server-side on their mandatory dates. Your integration does not change when a country revs its rules.