Generate compliant e-invoices from n8n | E-Invoice API

Is your ERP or invoicing software already producing compliant electronic invoices? In France the obligation has been live since 1 September 2026, and more countries follow every year. If your provider already covers it, you are set. If it does not yet, you do not have to wait for their roadmap. If your system already produces invoice PDFs, you are most of the way to a compliant electronic invoice, and you can close the gap yourself from an n8n workflow. The piece that is missing is structured data, and that is exactly what our electronic invoice endpoints add. This article shows how to go from the invoice data you already have to an EN 16931, XRechnung, or Factur-X file.

A PDF and an electronic invoice are two different things

An electronic invoice carries structured data in a fixed schema that accounting systems, ERPs, and tax authorities read directly, without anyone retyping the figures. A PDF on its own does not carry that data, so it does not meet EN 16931, the European semantic standard, and it will not pass the validation that more and more countries now require. The useful part is that you are already sending us the invoice data when you generate the PDF. The same JSON can produce the compliant file, so this is a reuse of what you have rather than a rebuild.

EN 16931, XRechnung, and Factur-X endpoints

The API works as a compliance layer. You send clean JSON, and you receive a validated, compliant file. JSON to XML transformation, schema mapping and validation, UBL and CII support, and embedded metadata are handled for you. Our guide to generating compliant invoices walks through the fields for each format.

• POST /einvoice creates an EN 16931 invoice, the European baseline.
• POST /einvoice/xrechnung creates an XRechnung invoice as UBL or CII, for public sector and business transactions in Germany.
• POST /einvoice/facturx creates a Factur-X invoice, also known as ZUGFeRD in Germany, a single file that is both a readable PDF (in the archival PDF/A-3 format) and an embedded XML payload, used in France and Germany.
• GET /einvoice/schema returns the exact JSON the API expects, so you map your fields once.

Doing it in n8n

We publish an n8n node, and the same tools are also available through our MCP server, which exposes 49 tools, so an AI agent inside n8n can call them directly and a single node gives a workflow every operation at once. A workflow to convert the invoices you already produce looks like this:

1. Trigger on a new invoice or order in your system, from a webhook, a database row, or a node from your billing tool.
2. Fetch the expected shape once with GET /einvoice/schema and map your fields to it.
3. Call POST /einvoice/facturx with your template id and the invoice data.
4. Store the returned file on the customer record, or send it straight on.

Because Factur-X returns one file that is both the readable invoice and the machine data, you can replace the plain PDF you send today with the compliant version, and nobody downstream has to change how they open it.

The same setup does more than invoices

The invoice endpoints sit on the same API as the rest of the platform, so the same n8n connection can also convert HTML to PDF with POST /conversion/html2pdf, produce accessible PDF/UA documents, and move a finished document into a review and sign flow. Once the node is in place, invoices are the first job it does, not the only one.

Ready to try it? Sign up and start right away, book a meeting with Michal, or read the electronic invoice documentation to see the full field list.