E-invoicing

LightningPDF emits validator-passing structured e-invoice formats for the regions where the mandate matters. Every supported format produces two legs in a single API call:

The visual leg: a normal PDF your customer reads, rendered through the Chromium engine.
The structured leg: XML (or IRP JSON for India) conformant to the format's official schema, ready for the network exchange.

For Factur-X and ZUGFeRD, the structured leg is embedded inside a PDF/A-3 wrapper with the /AFRelationship /Alternative marker required by the standard. For Peppol BIS 3.0 and ZATCA, the structured leg is delivered alongside the visual PDF. For India GST, the JSON payload is what the Invoice Registration Portal accepts.

Supported formats

Format	Region	Profile / Customization	Mandate
Peppol BIS Billing 3.0	Belgium / EU	`urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`	Belgian B2B 2026-01-01
ZUGFeRD 2.1 BASIC	Germany	`urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic`	Germany 2027-01-01 (over EUR 800k), 2028-01-01 (all)
Factur-X 1.0 BASIC	France	Same as ZUGFeRD 2.1 BASIC (byte-identical)	Chorus Pro accepted
ZATCA Phase 2	Saudi Arabia	`clearance:1.0` (B2B) or `reporting:1.0` (B2C)	Phase 2 integration
India GST e-invoice	India	NIC IRP JSON v1.1	Over INR 5 crore turnover
Japan qualified invoice	Japan	Visual layout only (no national XML standard yet)	October 2023

Plan requirement

The e-invoicing formats are a Pro plan feature. The Free and Starter tiers can use the visual PDF templates but the structured XML emission, PDF/A-3 conformance, and validator-pass reporting are Pro-only.

The API

Two endpoints, both Pro and above.

`POST /api/v1/einvoice/generate`

Returns a PDF/A-3 with the structured document embedded — the hybrid file ZUGFeRD and Factur-X define, and the artifact the EU mandates ask a supplier to produce. One call, both legs.

curl -X POST https://lightningpdf.dev/api/v1/einvoice/generate \
  -H "X-API-Key: $LPDF_API_KEY" \
  -H "Content-Type: application/json" \
  -o invoice.pdf \
  -d '{
    "format": "zugferd",
    "profile": "EN16931",
    "invoice": {
      "id": "INV-2026-0042",
      "issue_date": "2026-10-03",
      "due_date": "2026-11-02",
      "currency": "EUR",
      "payment_means_code": "30",
      "supplier": {
        "name": "Muster Handels GmbH", "vat_id": "DE123456789", "country_code": "DE",
        "address": {"street": "Hauptstraße 1", "city": "Berlin", "post_code": "10115"}
      },
      "customer": {
        "name": "Client SARL", "vat_id": "FR12345678901", "country_code": "FR",
        "address": {"street": "Rue de Rivoli 5", "city": "Paris", "post_code": "75001"}
      },
      "lines": [{
        "description": "Consulting services", "quantity": 10, "unit_code": "HUR",
        "unit_price": 120.00, "line_total": 1200.00,
        "tax_category_id": "S", "tax_percent": 19
      }]
    }
  }'

format accepts peppol, zugferd (or factur-x), zatca, india-gst. profile applies to ZUGFeRD/Factur-X only. Dates are YYYY-MM-DD.

The response carries X-EInvoice-Format and X-EInvoice-Attachment so you can assert what you got without parsing the PDF. The attachment name is fixed by each specification — factur-x.xml for ZUGFeRD/Factur-X — because readers locate it by name.

`POST /api/v1/einvoice/xml`

Returns only the structured document, no PDF. Use this when your access point wants UBL and you already have a renderer, or when you want to run the XML through a validator before committing to it.

Same request body; responds application/xml (or application/json for India GST).

What this does and does not do

It produces the file. It does not transmit it. Sending over Peppol requires an accredited access point, so the intended shape is: you generate the compliant artifact here and hand it to whoever holds the accreditation — or to a buyer who asked for ZUGFeRD directly. If you need help wiring that last hop, say so and we will point you at a provider rather than pretend we are one.

Onboarding help

Self-serve works from the first call, but for a first regulated deployment we will still share sample payloads matched to your buyer's expectations and run a validator pass with you. That avoids the failure mode where a customer ships a non-conformant XML in week one and burns the relationship with their buyer's accounting team.

To ask for that, email the founder directly at the address shown in your dashboard, or open a ticket from Support → New ticket, with the following:

The format(s) you need (Peppol BIS 3.0 / ZUGFeRD / ZATCA / India GST / Japan).
Your buyer's identifier (Peppol Participant ID, VAT registration, GSTIN, etc.) for the validator-pass test.
The volume you expect (per month).
Your stack (WordPress plugin, Shopify app, or direct API).

The turnaround is usually one business day for the initial setup and one more for the validator-pass sign-off.

What we will not claim

We will not claim that emitting structured XML is the same thing as transmitting it. For most regions, transmission requires an Access Point on the relevant network: Storecove, Pagero, or EDICOM for Peppol; the IRP API for India GST; Fatoora for ZATCA; the prefecture portals for Japan if any structured exchange happens at all. LightningPDF produces both legs of the document. Your Access Point delivers the structured leg over the network.

Frequently asked questions

Do you publish the validator reports?

We ran the following on 2026-06-03 against the sample invoices in pkg/einvoice/:

Peppol BIS Billing 3.0: PASS against the official OpenPEPPOL Schematron, both rule packs (CEN EN 16931 and Peppol BIS 3.0). Zero errors, zero warnings.
ZUGFeRD 2.1 BASIC / Factur-X 1.0 BASIC: PASS against Mustang-CLI 2.23.1. The validator reports XML:valid for our claimed profile (urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic).
Saudi ZATCA Phase 2: PASS on a structural conformance check (11/11 required ZATCA fields present). Full Schematron run pending Fatoora portal access; the SDK ships only to registered taxpayers.
India GST IRP (NIC v1.1 JSON): PASS on a structural conformance check (47/47 required fields per the published spec). NIC IRP runtime validation pending sandbox credentials.

The raw validator outputs (Mustang report, Peppol SVRL files, structural-check JSON) are stored in the repo under test-results/validators/ and the toolchain to reproduce is documented in test-results/validators/summary.md. Abridged screenshots are published on lightningpdf.dev/proof. When you onboard, we run the same validators against your real supplier and customer details and share the report before you go live.

Why is the structured leg sometimes embedded in the PDF and sometimes separate?

The German mandate explicitly requires the hybrid PDF/A-3 with embedded XML (Factur-X / ZUGFeRD). The Belgian Peppol mandate requires the structured XML to be transmitted over the Peppol network; the visual PDF is for human consumption only. ZATCA Phase 2 accepts both clearance modes. India IRP returns the IRN and signed QR after registration; the PDF carries the QR for the visual leg. Japan's mandate is visual-only.

We follow the format's convention. If you have a customer-specific requirement (some German buyers prefer the structured leg as a separate file even when the mandate accepts the hybrid), tell us in the onboarding ticket and we configure accordingly.

What about PDF/A-3 conformance on the visual leg?

The Pro-tier flow runs the rendered PDF through a Ghostscript-based PDF/A-3 conversion pipeline (embedded sRGB ICC, font subsetting, XMP conformance metadata) and then attaches the XML with the /AFRelationship /Alternative marker and the /AF array entry on the document Catalog. Final PDF/A-3 conformance is verified against veraPDF as part of the onboarding pass.

The Free and Starter tiers do not run this pipeline. Their PDFs are normal PDFs; the structured XML is delivered as a separate file. Both work for the structured-leg validator; only the hybrid PDF satisfies the PDF/A-3 archival requirement.

Can I extend a template to a region you do not yet support?

If you face a regulated mandate not in the supported list (UAE FTA, Mexico CFDI 4.0, Brazil NF-e, Poland KSeF), tell us. We add formats when the mandate deadline aligns with a customer we can onboard. The line-item data model is shared across formats, so adding a new emitter is a focused effort once a customer has signed up.

Do you store the structured XML I generate?

No. The XML is produced at request time and returned to you. We do not retain copies after the request completes, the same retention policy that applies to the PDF leg.

Free online validators

Two free validation tools run the EN 16931 structural and arithmetic checks in the browser, no signup needed:

Peppol BIS 3.0 Validator for UBL invoices
ZUGFeRD / Factur-X Validator for CII XML or complete hybrid PDFs (the embedded XML is extracted automatically)

Both cite the official business rule ids (BR-02, BR-CO-15, and so on) so findings line up with access point rejections. They are a quick pre-flight check; invoices generated by this API are additionally tested against the official Peppol Schematron and Mustang validators.