Guide · Invoicing

EU e-invoicing: generating the human-readable invoice document

EU e-invoicing mandates are about structured, machine-readable XML — not PDFs. But in a real invoicing flow you still need a document a human can read: for the customer, for sales, for your own records. This guide covers that second artifact, and how to generate it inside the same automation that builds the XML.

What the mandates mean in practice

Across the EU, "e-invoice" has a specific legal meaning: a structured data file a tax platform or the buyer's system can parse automatically. In practice that ecosystem looks like this:

• A semantic standard — EN 16931 defines what an electronic invoice must express (parties, VAT identifiers, line items, tax breakdowns…).
• Syntaxes — that model is serialized as XML, typically UBL or UN/CEFACT CII. A PDF, however pretty, is not an e-invoice in this sense.
• Exchange rails — invoices travel over networks like Peppol or through national platforms; Italy, for example, routes domestic invoices through its national exchange system, and other member states run or are building their own clearance or reporting models.
• Timelines that differ by country — business-to-government e-invoicing is widely established, and member states are phasing in business-to-business mandates on different schedules. Those schedules shift; verify your country's current rules rather than trusting any blog post's dates — including this one, which deliberately names none.

The two-artifact pattern

Teams that automate invoicing under these mandates almost always end up producing two artifacts from the same invoice data:

The XML satisfies the tax platform; the readable document satisfies everyone else. Generating both from one data source keeps them consistent — the classic failure mode is a PDF produced by one system and XML produced by another, drifting apart on totals or terms.

Building the document side in n8n or Make

Wherever your flow already assembles invoice data and builds/submits the XML, add one Docmill step branching off the same data. In n8n, for example:

1. Trigger + data assembly

   Order created (webhook, Stripe, your database) → a Set/Code node shapes the invoice data: seller and buyer details, VAT identifiers, line items, tax rates, totals.

2. Branch A — structured XML

   Your existing XML-building step and submission to your access point or national platform, via your e-invoicing provider's node or API.

3. Branch B — Docmill: Generate Document

   The same data object goes into the Docmill node (or Make module / Zapier action): template ID, Data (JSON), Output Format PDF or DOCX. The file comes back as binary output ready for the next step.

4. Deliver and archive

   Email the PDF to the customer, and store XML + PDF together (Drive, S3, your DMS) so every invoice's two artifacts stay paired.

Setup for each platform is covered step by step in the n8n guide, the Make guide, and the Zapier guide — including credentials, field mapping, and troubleshooting.

Starting point: the invoice starter template

Every Docmill account ships with starter:invoice — line items, totals, payment terms — which renders a finished invoice PDF in one call:

# one POST, one invoice
curl https://api.docmill.io/v1/documents \
  -H "Authorization: Bearer dk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "template_id": "starter:invoice",
    "data": { "client": {"name": "Northwind Traders"},
              "items": [{"description": "Design sprint",
                         "quantity": 1, "unitPrice": 4800}],
              "total": 4800 },
    "output": "pdf"
  }' --output invoice.pdf
# → %PDF-1.7 …

For EU invoices you'll usually want a richer layout — both parties' VAT identifiers, per-line VAT rates, a tax breakdown table, the invoice number and dates displayed prominently. Rather than hand-building that, describe it once and let Docmill draft a reusable template:

curl https://api.docmill.io/v1/templates/generate \
  -H "Authorization: Bearer dk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "prompt": "An EU-style invoice: seller and buyer blocks with
        VAT identifiers, invoice number and issue/due dates, line items
        with per-line VAT rate, a VAT breakdown table by rate, totals
        net/VAT/gross, 30-day payment terms and bank details." }'
# → template id + sample data showing exactly which fields to send

The response includes sample data that tells you the exact field names to map from your workflow — the same fields your XML step already has. Templates are plain HTML underneath, so you can adjust wording, add your logo, or translate labels. The same template renders as PDF or DOCX (and XLSX for tabular documents) by switching the output format.

FAQ