E-invoicing
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.
There is no self-serve public API endpoint yet. While we onboard the first cohort of Pro customers per region, this is a hand-rolled flow: you tell us the format you need and we configure your account, share sample payloads matched to your buyer's expectations, and run a validator pass before you start sending invoices for real. This 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 request access, 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:validfor 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.