E-Invoicing in Europe: ZUGFeRD, Factur-X, and the Path to Mandatory Compliance

If your company does business in Europe, e-invoicing compliance is no longer optional — it's becoming mandatory. Germany mandated B2B e-invoicing from January 2025 (with transition periods through 2027). France follows in 2026. Italy has required it since 2019. Country by country, the EU is moving toward fully digital, structured invoicing.

But "e-invoicing" doesn't just mean emailing a PDF. It means sending invoices in a machine-readable, structured format that tax authorities can process automatically. This has fundamental implications for how your invoice system works.

This article covers the landscape: what the standards require, when the deadlines are, and what technical changes you need to make.

What Is E-Invoicing (Exactly)?

E-invoicing means exchanging invoices in a structured electronic format between seller and buyer, with the data machine-readable from end to end. There are three levels of "electronic invoicing" that are often confused:

Level 1: PDF Invoice (Not E-Invoicing)

A PDF sent by email. Looks pretty, but is essentially a picture of an invoice. To extract data, you'd need OCR or manual entry. This is NOT e-invoicing under EU regulations.

Level 2: Hybrid Invoice (PDF + Data)

A PDF with an embedded structured data file (XML). The PDF is for humans; the XML is for machines. This is what ZUGFeRD and Factur-X provide. It's accepted as e-invoicing in most contexts.

Level 3: Pure Structured Invoice

A pure XML or UBL file with no PDF representation. This is what Peppol BIS and Italy's FatturaPA use. The "invoice" is just data — no visual representation is included (though one can be generated from the data).

The Major Standards

ZUGFeRD (Germany)

ZUGFeRD ("Zentraler User Guide des Forums elektronische Rechnung Deutschland") is the German standard for e-invoicing. It's a PDF/A-3 document with an embedded XML file:

invoice.pdf (PDF/A-3)
├── Human-readable invoice (visual PDF)
└── factur-x.xml (structured data)
    ├── Seller information
    ├── Buyer information
    ├── Line items with descriptions, quantities, prices
    ├── Tax calculations (VAT rates, amounts)
    ├── Payment terms and bank details
    └── Totals

ZUGFeRD has five conformance profiles, each adding more data:

Profile	Data Level	Use Case
Minimum	Invoice reference only	Cross-referencing
Basic WL	Key fields, no line details	Simple invoicing
Basic	Full line item details	Standard B2B invoicing
EN 16931 (Comfort)	Full EU standard compliance	Regulatory compliance
Extended	Maximum detail	Complex enterprise needs

For most companies, EN 16931 is the target — it satisfies the EU regulation and covers all mandatory fields.

Factur-X (France / EU)

Factur-X is the Franco-German standard, technically identical to ZUGFeRD 2.x but used in the French regulatory context. The XML schema is the same; only the marketing name differs.

France is implementing mandatory e-invoicing in phases:

• September 2026: Large enterprises must send and receive
• September 2027: Mid-sized enterprises
• September 2028: Small enterprises and micro-enterprises

XRechnung (Germany - Public Sector)

XRechnung is the German standard specifically for invoices to public authorities. It's a pure XML format (no PDF component), based on the EU standard EN 16931.

Key difference from ZUGFeRD: XRechnung is pure data — no visual representation. The receiving authority generates whatever visual format it needs from the data.

FatturaPA (Italy)

Italy was the pioneer. Since January 2019, ALL invoices (B2B and B2C) must be sent electronically through the SDI ("Sistema di Interscambio") in FatturaPA XML format. Italy's experience provides valuable lessons for other countries.

Peppol (Pan-European)

Peppol is a network and standard for exchanging electronic documents across borders. It uses UBL (Universal Business Language) or CII (Cross Industry Invoice) format and routes documents through Access Points — similar to how email works with SMTP servers.

Seller → Seller's Access Point → Peppol Network → Buyer's Access Point → Buyer

Peppol is increasingly the default for cross-border B2B invoicing in the EU, especially for public procurement.

Technical Implementation

Generating ZUGFeRD / Factur-X Invoices

A ZUGFeRD invoice is technically a PDF/A-3 with an embedded XML attachment. Here's the implementation approach:

Step 1: Generate the XML

The XML must conform to the CII (Cross Industry Invoice) schema. Here's a simplified structure:

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">

    <rsm:ExchangedDocumentContext>
        <ram:GuidelineSpecifiedDocumentContextParameter>
            <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
        </ram:GuidelineSpecifiedDocumentContextParameter>
    </rsm:ExchangedDocumentContext>

    <rsm:ExchangedDocument>
        <ram:ID>INV-2026-001</ram:ID>
        <ram:TypeCode>380</ram:TypeCode> <!-- 380 = Commercial Invoice -->
        <ram:IssueDateTime>
            <udt:DateTimeString format="102">20260211</udt:DateTimeString>
        </ram:IssueDateTime>
    </rsm:ExchangedDocument>

    <rsm:SupplyChainTradeTransaction>
        <!-- Seller -->
        <ram:ApplicableHeaderTradeAgreement>
            <ram:SellerTradeParty>
                <ram:Name>Acme Corp</ram:Name>
                <ram:SpecifiedTaxRegistration>
                    <ram:ID schemeID="VA">DE123456789</ram:ID>
                </ram:SpecifiedTaxRegistration>
            </ram:SellerTradeParty>
            <!-- Buyer details... -->
        </ram:ApplicableHeaderTradeAgreement>

        <!-- Line Items -->
        <ram:IncludedSupplyChainTradeLineItem>
            <ram:AssociatedDocumentLineDocument>
                <ram:LineID>1</ram:LineID>
            </ram:AssociatedDocumentLineDocument>
            <ram:SpecifiedTradeProduct>
                <ram:Name>Web Development Services</ram:Name>
            </ram:SpecifiedTradeProduct>
            <ram:SpecifiedLineTradeAgreement>
                <ram:NetPriceProductTradePrice>
                    <ram:ChargeAmount>150.00</ram:ChargeAmount>
                </ram:NetPriceProductTradePrice>
            </ram:SpecifiedLineTradeAgreement>
        </ram:IncludedSupplyChainTradeLineItem>

        <!-- Totals and tax... -->
    </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Step 2: Generate the PDF/A-3

The PDF itself must be PDF/A-3 compliant (fonts embedded, ICC profiles, no JavaScript).

Step 3: Embed the XML in the PDF

The XML file must be attached as a file association with the relationship type "Data":

// Using a library that supports PDF/A-3 attachments
$pdf->attachFile('factur-x.xml', $xmlContent, [
    'relationship' => 'Data',
    'mime_type' => 'text/xml',
    'description' => 'Factur-X XML invoice data',
]);

Validation

Before sending, validate your invoices against the standard. The KoSIT validator is the reference tool for German e-invoicing:

java -jar validationtool.jar -s scenarios.xml -r rules/ invoice.xml

Using Libraries

Several libraries simplify e-invoicing:

PHP:

• horstoeko/zugferd — Full ZUGFeRD/Factur-X support for PHP
• easybill/zugferd-php — Another PHP implementation

use horstoeko\zugferd\ZugferdDocumentBuilder;

$builder = ZugferdDocumentBuilder::CreateNew(ZugferdProfiles::PROFILE_EN16931);
$builder
    ->setDocumentInformation('INV-2026-001', '380', new DateTime('2026-02-11'))
    ->addDocumentSellerContact('John Smith')
    ->setDocumentSeller('Acme Corp', 'DE123456789')
    ->setDocumentBuyer('Client GmbH', 'DE987654321')
    ->addNewPosition('1')
    ->setDocumentPositionProductDetails('Web Development', '', '12345')
    ->setDocumentPositionNetPrice(150.00)
    ->setDocumentPositionQuantity(10, 'HUR'); // 10 hours

$xml = $builder->getContent();

Python:

• facturx — Generate and parse Factur-X/ZUGFeRD PDFs

Node.js:

• zugferd — JavaScript implementation (less mature than PHP/Python options)

Migration Strategy

If you're currently sending plain PDF invoices, here's a practical migration path:

Phase 1: Understand Your Requirements (2 weeks)

1. Which countries do you invoice to?
2. What regulations apply to each country?
3. What conformance level do you need? (Usually EN 16931)
4. Do you need to send via Peppol or directly?

Phase 2: Update Your Data Model (1-2 weeks)

E-invoicing requires data fields that you might not currently store:

• VAT identification numbers for seller and buyer
• Bank account details (IBAN, BIC)
• Tax breakdown per VAT rate
• Payment terms with specific codes
• Product classification codes (optional but recommended)
• Line item quantities with unit codes (hours, pieces, kilograms)

Phase 3: Implement XML Generation (2-4 weeks)

Use a library to generate compliant XML. Validate against the official schema. Test with real scenarios:

• Standard invoice with multiple VAT rates
• Credit note (TypeCode 381)
• Invoice with discounts
• Invoice in a foreign currency
• Invoice to a non-EU buyer

Phase 4: Generate PDF/A-3 (1-2 weeks)

Either update your PDF generation to produce PDF/A-3 with the embedded XML, or use an API service that handles this automatically.

For teams using PDF-API.io, the ZUGFeRD/Factur-X generation can be handled on the rendering side — you provide the invoice data, and the API generates a compliant PDF/A-3 with embedded XML.

Phase 5: Peppol Integration (if needed) (2-4 weeks)

If you need to send invoices via Peppol, you'll need to register with a Peppol Access Point provider. This is essentially a "mail server" for invoices.

Common Mistakes

1. Assuming PDF = e-invoice: A regular PDF is not an e-invoice. It must contain structured, machine-readable data.

2. Ignoring tax calculation rules: E-invoicing enforces strict tax calculation rules. The XML total must match the sum of line items × VAT rates exactly — rounding errors will cause rejection.

3. Missing mandatory fields: Each profile has required fields. The EN 16931 standard has ~50 mandatory fields. Missing any one will fail validation.

4. Wrong TypeCode: Invoice (380), Credit Note (381), Debit Note (383), Corrected Invoice (384) — using the wrong code causes processing errors.

5. Late start: These regulations have deadlines. Starting implementation 3 months before a deadline is risky.

Conclusion

E-invoicing in Europe is not a trend — it's a regulatory mandate. The transition from PDF-as-picture to PDF-as-data is happening country by country, and the technical standards (ZUGFeRD, Factur-X, Peppol) are mature and well-documented.

The good news: the standards are converging around EN 16931, meaning a single implementation can cover most European countries. The investment in compliance today will save you from scrambling when your next target market mandates e-invoicing.

Start with your highest-priority country, implement the EN 16931 profile, validate rigorously, and expand from there.

---

Need ZUGFeRD/Factur-X compliant invoices? PDF-API.io generates PDF/A-3 with embedded XML — fully compliant with European e-invoicing standards. Start your compliance journey.