ZUGFeRD, XRechnung, KSeF, UBL: A Developer's Map of the 2026–2030 E-Invoicing Mandates
France's Factur-X mandate, effective September 2026, was the warm-up. By 2030, every EU business and most UK suppliers will face a rolling schedule of e-invoicing requirements: Belgium and Croatia are live now, Poland's KSeF is expanding through 2026, Germany's phased rollout begins in 2027, Spain and Greece follow, and ViDA cross-border rules take effect July 2030. A structured XML payload is the legal invoice. The PDF is the human-readable rendering. Developers who treat this as "generate a PDF and attach a file" will fail compliance audits. This post maps the 2026–2030 mandate schedule, the four compliance architectures that determine integration complexity, and where an HTML-to-PDF rendering pipeline fits in a compliant stack.
The Two Halves of Every E-Invoice Mandate
Every mandate, regardless of country, splits the invoice into two distinct layers. The structured payload carries the legal data: seller and buyer VAT IDs, line items with correct classification codes, tax breakdowns, and payment terms. The human layer presents this data in a readable format: a PDF, a QR code, or a portal view.
The XML is the legal invoice. The PDF is a visual rendering for humans [1][2]. ZUGFeRD embeds XML inside PDF/A-3, creating a hybrid file where both layers travel together. XRechnung is XML-only, transmitted through dedicated networks with no PDF required. KSeF generates its own PDF after clearance, separate from whatever visual document you create for your customer.
Teams that scrape PDFs to create XML are building compliance violations. The direction must flow from structured data to visual output, never the reverse. Your accounting system or ERP holds the canonical data. That data feeds a compliance API to generate valid XML. The same data feeds a rendering API to generate the PDF your customer sees.
The developer's job is usually the visual layer, not the XML generation. Most SaaS products and custom platforms already integrate with compliance APIs or ERP modules that handle XML validation and network submission. Where engineering time gets underestimated is the PDF: branded, correct, accessible, and legally coherent with the XML it represents.
Country-by-Country Mandate Schedule and Formats
Belgium made B2B e-invoicing mandatory for large businesses in 2026, with gradual expansion to smaller entities. The required format is Peppol BIS Billing 3.0, transmitted through a Peppol access point. Croatia runs its Fina e-Račun system, using UBL 2.1 XML submitted to a government platform.
Poland's KSeF system uses the FA(3) format, mandatory for large taxpayers since 2024 and expanding through 2026 to cover progressively smaller businesses. Greece's myDATA integration, already required for B2B reporting, expands to full e-invoicing compliance through 2026–2027.
Outside the EU, the UAE's PINT-AE pilot moves toward mandatory implementation in 2027, following a pattern similar to European clearance systems.
Germany's phased approach is the most consequential for developers serving European markets. Under the Growth Opportunities Act, every company must be able to receive EN-compliant e-invoices from 1 January 2025 [2]. Issuing becomes mandatory for large businesses in 2027, with all businesses covered by 2028 [2]. Germany recognizes three national CIUS formats: XRechnung as a purely digital data file, ZUGFeRD 2.2.0 (Profile XRechnung) as a hybrid combining PDF with embedded XML, and Peppol BIS Billing 3.0 for network transmission [2].
Spain's Facturae and BATUZ systems begin phased rollout in 2027–2028. The UK, post-Brexit but deeply integrated with EU supply chains, is expected to mandate B2B e-invoicing around 2029.
The ViDA (VAT in the Digital Age) cross-border Digital Reporting Requirements apply from 1 July 2030. This is the endgame: any EU business selling cross-border will need real-time or near-real-time digital reporting, not just periodic VAT returns.
Four Compliance Architectures That Determine Your Integration
Format-only means you generate valid XML and send it through any channel. Germany's XRechnung works this way for direct transmission. You need a compliance API that validates against the correct CIUS schema and produces the XML. The sending mechanism is your responsibility.
Network means transmission through a dedicated infrastructure. Belgium, the Netherlands, and Nordic countries use Peppol access points. You register with an access point provider, they handle routing, and the XML format is standardized. Your integration is with the access point's API, not directly with every recipient.
Clearance means submitting to a government platform and receiving an approval ID before the invoice is legally issued. Poland's KSeF and Italy's SDI operate this way. The platform validates the XML, assigns a KSeF number or SDI identifier, and often generates an official PDF. Your system must wait for this confirmation before considering the invoice sent.
Approved-platform means registering with a certified provider who routes invoices through a government system. France's PDP/PPF model works this way. You integrate with a certified platform, they handle the France-specific formatting and submission.
Hybrid combines embedded XML inside PDF/A-3 with a visual layer. ZUGFeRD and Factur-X use this approach. The PDF contains both the human-readable invoice and the machine-readable XML as an attachment. Recipients without XML-capable systems can still process the PDF visually; automated systems extract the XML.
Architecture determines whether you need a compliance API, a network gateway, or both [1][2]. A German business might need ZUGFeRD for some customers, XRechnung for others, and Peppol BIS for international trade. The visual layer, however, can stay consistent across all three if built correctly.
Where HTML-to-PDF Rendering Plugs Into Each Architecture
For ZUGFeRD and Factur-X, MarkupGo renders the visual PDF layer while a compliance API handles XML generation, embedding, and PDF/A-3 packaging [1][2]. The workflow is sequential: data produces XML through the compliance layer, the same data produces PDF through MarkupGo, and a final step embeds the XML into the PDF with correct MIME type and AFRelationship metadata.
For XRechnung, no PDF is required for transmission. Buyers often request one for their records, and internal workflows need human-readable versions. MarkupGo renders this from the same data model that feeds the XML generator, ensuring the visual document matches the structured data even though no embedding occurs [1][2].
For KSeF, the Polish government generates the official PDF after clearance. International recipients and internal processes need a branded version showing the KSeF ID and a scannable QR code. MarkupGo renders this with the verified KSeF number returned from the clearance platform [1][2].
For Peppol BIS, the access point handles XML transmission. MarkupGo renders PDF for buyers who need records outside the Peppol network, or for internal approval workflows before submission [1][2].
For PINT-AE and similar formats, the pattern repeats: compliance platform handles XML, MarkupGo renders visual PDF for recipients who need it [1][2].
Legal Gotchas That Break Naive PDF Generation
In ZUGFeRD, the embedded XML is the legal invoice. The PDF must not contradict it. A total shown in the PDF that rounds differently from the XML total creates a compliance violation. Payment terms rendered in the PDF but omitted from the XML create a mismatch. Every field in the visual layer must derive from the same structured data that produces the XML, never from separate sources or manual entry.
XML must be generated from structured data, not scraped from PDF text. Some teams attempt to generate a PDF first, then extract text to create XML. This reverses the legal hierarchy and produces invalid classification codes, incorrect decimal handling, and missing mandatory fields.
PDF/A-3 attachment requires correct MIME type and AFRelationship metadata. The embedded XML must use application/xml or the format-specific MIME type, with AFRelationship set to Alternative or Data per the specification. Incorrect metadata causes validation failures in recipient systems.
Font embedding and color profiles matter for PDF/A-3 validation. Subset embedding is required for all fonts. RGB color spaces need correct output intent declarations. These must be handled by your rendering pipeline when producing the PDF/A-3 visual layer [1].
KSeF FA(3) has strict field lengths and enumeration values. A seller name truncated to fit a visual layout but submitted in full to KSeF creates divergence. The visual PDF must match the submitted data exactly, or the KSeF ID becomes associated with a different document than what the customer sees.
QR codes for KSeF ID and payment must be generated from verified data, not hardcoded. A QR code containing a provisional invoice number that changes after clearance links to nothing. The QR must use the final, assigned KSeF identifier and the exact payment amount from the cleared XML [1][2].
A Worked Example: ZUGFeRD Visual Layer with MarkupGo
Start with invoice data as JSON. This same structure feeds your compliance API for XML generation and MarkupGo for PDF rendering. A typical payload includes seller and buyer objects with VAT IDs, line items with unit prices and tax rates, payment terms, and a unique invoice identifier.
Create an HTML template with CSS for branded layout. Include seller information header, buyer block, line item table with correct column alignment, subtotal and tax breakdown, total with currency, and payment instructions. The template lives in MarkupGo's reusable template system [1].
Add a payment QR code using MarkupGo's built-in support. For SEPA payments, this encodes the EPC QR structure with IBAN, amount, and reference. The QR data derives from the same JSON fields that populate the visual amount and reference fields, ensuring consistency [1].
Send the invoice data to the MarkupGo API to render the visual PDF from your template [1].
Pass this PDF to your compliance API for XML embedding and validation. The compliance layer extracts or generates the XML, validates against ZUGFeRD 2.2.0 schema, attaches it to the PDF with correct metadata, and returns the final hybrid file.
The result is one data source producing two outputs: XML for machines, PDF for humans, both legally compliant and mutually consistent [2].
What Changes When You Add KSeF, XRechnung, or PINT-AE
For KSeF, the same HTML template adds two fields: the KSeF ID returned from clearance, and a QR code encoding that ID for verification. The compliance API handles FA(3) XML generation and platform submission. MarkupGo renders the branded version with verified data [1][2].
For XRechnung, no PDF is required for transmission. Generate an optional PDF from the same template for buyer records or internal approval. The compliance API endpoint changes to XRechnung validation, but the visual layer remains identical [1][2].
For PINT-AE, adapt the template for Arabic/English bilingual if serving UAE recipients. The compliance platform handles PINT XML formatting. MarkupGo's reusable templates let you maintain the layout variants each regime needs [1].
Only the data mapping and compliance API endpoint change. The same reusable-template approach extends to each new regime as you add it [1][2].
Building a Multi-Country Pipeline Without Puppeteer
Self-hosted Chromium fails predictably in production. Serverless cold starts exceed timeout limits. Font loading depends on system-installed fonts that differ between environments. CORS blocks asset URLs that work in local development. Memory consumption spikes on complex layouts. Each failure mode requires infrastructure work that has nothing to do with invoice compliance [1].
MarkupGo renders HTML templates remotely. No Puppeteer, no self-hosting, no font installation on your servers. The template is stored once, called with dynamic data per invoice [1].
The pipeline works from multiple entry points. An n8n workflow triggers on a new Stripe payment, calls MarkupGo with payment data, and stores the PDF. A Make.com scenario watches a Google Sheets row, generates an invoice PDF, and emails it. A direct API call from your Node.js backend handles high-volume batch generation. No code nodes or custom scripts required [1].
You don't need separate systems for images and PDFs. That invoice template you built for ZUGFeRD compliance? MarkupGo's Magic Template URLs also generate dynamic OG images from templates [1].
Choosing Your Compliance Stack and Rendering Layer
Compliance APIs handle XML validation against CIUS schemas, network submission through Peppol or direct protocols, clearance platform integration for KSeF and SDI, and audit trail generation for tax authority review. These are specialized services with deep regulatory knowledge and certified status.
MarkupGo handles the visual PDF generation, payment QR codes, and branded presentation that makes the invoice usable for your customers [1].
For France specifically, the Factur-X deep dive covers PDF/A-3 and the September 2026 enforcement timeline [1].
Start with one country where you have immediate customer concentration. Build the HTML template for that regime's required fields. Integrate the compliance API for XML generation and submission. Verify end-to-end with test invoices. Then templatize variations for the next mandate: add KSeF fields for Poland, switch to bilingual layout for UAE, enable Peppol routing for Belgium. The visual layer expands; the architecture stays constant.
Sources
- markupgo.com
- eInvoicing in Germany (ec.europa.eu)