What is EN 16931?

 What is EN 16931?

EN 16931 is the European standard defining the semantic data model for electronic invoices, published by CEN and mandated by EU Directive 2014/55/EU.

How EN 16931 Works

EN 16931 works on two levels:

1. Semantic Model (What)

The standard defines 162 business terms that an invoice can contain, organized into groups:

• Invoice identification (number, date, type)
• Seller and buyer information
• Payment details
• Tax information
• Line items
• Totals

2. Technical Syntaxes (How)

The semantic model can be expressed in two XML syntaxes:

• UBL 2.1: Used by Peppol, XRechnung (UBL variant)
• UN/CEFACT CII: Used by ZUGFeRD, Factur-X, XRechnung (CII variant)

CIUS: Country Extensions

Countries can create "Core Invoice Usage Specifications" (CIUS) that add rules without breaking EU compatibility. Examples:

• XRechnung: German CIUS with Leitweg-ID requirement
• Peppol BIS: Peppol's CIUS with network-specific rules

Why EN 16931 Matters

Legal Requirement

EU Directive 2014/55/EU mandates EN 16931 for public procurement. All EU governments must accept EN 16931-compliant invoices.

Cross-Border Interoperability

An EN 16931 invoice from Germany works in France, Italy, or any EU country. The standard ensures data can be understood regardless of the sender's software.

Future Mandate

ViDA (VAT in the Digital Age) will make EN 16931-based e-invoicing mandatory for all EU B2B transactions by 2030. Starting now puts you ahead.

How to Get Started

Step 1: Understand Your Requirements

Check which CIUS applies to your situation. Germany uses XRechnung, Belgium uses Peppol BIS, France uses Factur-X.

Step 2: Choose Your Syntax

UBL for Peppol/international; CII for ZUGFeRD/Factur-X. Both are equally compliant.

Step 3: Validate Compliance

Use validation tools to check both EN 16931 base rules and any CIUS-specific rules.

 

What is ZUGFeRD?

 What is ZUGFeRD?

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid e-invoice format that embeds machine-readable XML data inside a PDF/A-3 document. Open the file in a PDF reader — you see a normal invoice. Parse the embedded XML — you get structured data that an ERP can process automatically. ZUGFeRD 2.x and Factur-X are the same specification. They unified in 2020. The only difference is the name: ZUGFeRD is the German branding, Factur-X is the French. The underlying XML is CII (Cross Industry Invoice) D16B syntax, and the embedded file is always named factur-x.xml. The current version is ZUGFeRD 2.3.2 (aligned with Factur-X 1.07.2), released in late 2024. It’s EN 16931-compliant and accepted as a valid e-invoice format under Germany’s B2B mandate.

How ZUGFeRD Works

A ZUGFeRD invoice is a PDF/A-3 file with a structured XML attachment. The PDF/A-3 standard (ISO 19005-3) allows embedding arbitrary files inside a PDF — ZUGFeRD uses this to embed a CII XML file containing all the invoice data in machine-readable form.

The Dual-Readability Concept

When you open a ZUGFeRD invoice in any PDF reader (Adobe, Preview, browser), you see a normal, human-readable invoice. The visual layout, formatting, and branding are all there — exactly like a traditional PDF invoice.

When software processes the same file, it extracts the embedded XML attachment and reads the structured data directly. No OCR, no parsing, no guessing where the invoice number is. The data is typed, structured, and follows the EN 16931 data model.

This is what makes ZUGFeRD hybrid: one file serves both human readers and machine processors.

The XML Attachment

The embedded XML file is always named factur-x.xml (even in ZUGFeRD-branded invoices — this is part of the unified specification). The XML uses CII (Cross Industry Invoice) D16B syntax, which is one of the two syntaxes defined by EN 16931 (the other being UBL 2.1).

The XML is attached to the PDF via the PDF’s Associated File mechanism. The relationship type is set to Alternative — meaning the XML is an alternative representation of the same document content.

Why PDF/A-3 Specifically

Regular PDFs don’t allow embedded file attachments in a standards-compliant way. PDF/A-3 does. It’s the archival variant of PDF that:

• Embeds all fonts (no missing character issues decades later)
• Includes ICC color profiles
• Allows associated file attachments (the XML)
• Guarantees long-term readability without external dependencies

This matters for compliance. Tax authorities require invoice archives to be readable for 7–10+ years. PDF/A-3 guarantees this. A regular PDF with an XML attachment might not pass archive compliance checks.

Generating a ZUGFeRD Invoice

The production flow has four steps:

1. Generate the visual PDF — your ERP’s existing PDF generation, but output as PDF/A-3 (not regular PDF). This means embedding fonts, including ICC profiles, and setting the PDF/A conformance level.
2. Generate the CII XML — create the structured invoice data in CII D16B syntax with the correct ZUGFeRD profile (see profiles section below). The XML must be EN 16931-compliant.
3. Embed the XML in the PDF — attach factur-x.xml to the PDF/A-3 file with the correct relationship metadata (AFRelationship = Alternative).
4. Validate — check both the PDF/A-3 conformance and the CII XML validity against EN 16931 + profile rules. Validate a ZUGFeRD invoice →

Most ERP vendors handle steps 1–3 in their invoice output module. Step 4 is where a pre-submission compliance gate catches issues before the invoice reaches customers or archives.

Why ZUGFeRD Matters

ZUGFeRD Profiles Explained

ZUGFeRD defines six profiles, each adding more data fields than the last. The profile you choose determines what data must be present in the XML.

Profile	Data Depth	EN 16931 Compliant	Use Case
Minimum	Invoice metadata only	No	Archival, payment reference only
Basic WL	Header + totals, no line items	No	Basic accounting without line detail
Basic	Full line items with prices and quantities	No	Standard B2B invoicing
EN 16931 (Comfort)	Full EN 16931 data model	Yes	Cross-border EU, government invoicing
Extended	EN 16931 + additional fields	Yes (superset)	Complex scenarios (logistics, manufacturing)
XRechnung	German CIUS rules applied	Yes	German public sector invoicing

Which Profile Do I Need?

Sending to German government? Use XRechnung or EN 16931. The Minimum and Basic WL profiles are explicitly not accepted for the German B2B mandate — they lack required data fields.

Standard B2B in Germany? EN 16931 is the safe choice. It meets the mandate requirements and works cross-border. Basic works for domestic-only if you don’t need full EU compliance.

Cross-border EU trade? EN 16931. It’s the European standard — any EU trading partner’s system should process it.

France? EN 16931 (remember: ZUGFeRD 2.x = Factur-X, so the same profile works for French compliance).

Archival only? Minimum — but be aware this won’t meet Germany’s e-invoicing mandate requirements.

ZUGFeRD in Germany: Mandate Status

Germany’s e-invoicing mandate rolls out in three phases:

Date	Requirement
January 1, 2025	All businesses must be able to receive structured e-invoices (ZUGFeRD, XRechnung)
January 1, 2027	Businesses with revenue > €800,000 must send e-invoices
January 1, 2028	All businesses must send e-invoices

ZUGFeRD (profiles EN 16931, Extended, or XRechnung) is one of the accepted formats. XRechnung (pure XML without PDF wrapper) is the other. Both are valid.

During the transition period (2025–2026), paper and PDF invoices are still explicitly allowed for sending. But reception capability is already mandatory — your ERP must be able to ingest ZUGFeRD and XRechnung invoices now.

ZUGFeRD for ERP Vendors

If you maintain an ERP serving German businesses, ZUGFeRD support is on your roadmap. Here’s what matters:

PDF/A-3 output is the first hurdle. Most ERPs generate regular PDFs. Converting to PDF/A-3 requires font embedding, ICC profile inclusion, and conformance-level metadata. Libraries like Apache PDFBox, iText, or pdf-lib can handle this — but your existing PDF templates may need adjustments.

CII XML generation is the data challenge. Your ERP has the invoice data. The question is mapping it to CII D16B fields with the right profile. The EN 16931 data model defines ~180 business terms (BT-1 through BT-180+) — the profile determines which are required.

Embedding is the assembly step. Attach the XML to the PDF with the right metadata. This is a one-time implementation.

Validation is the ongoing concern. ERP templates drift across customers. Profile requirements change. Country-specific rules get updated. Validating every ZUGFeRD invoice before delivery catches issues before they become rejections.

Common ZUGFeRD Validation Errors

These are the errors we see most frequently in ZUGFeRD invoices:

PDF/A-3 conformance failures — The most common ZUGFeRD-specific error. The PDF isn’t valid PDF/A-3: missing embedded fonts, wrong color profile, or incorrect conformance level metadata. This is a PDF issue, not an XML issue — but the invoice is invalid without a conformant container.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the invoice total. Rounding differences between the PDF (visual) and XML (structured) representations are the usual cause.

BR-DE-15 — Buyer reference missing. Required by the German CIUS (XRechnung rules). If you’re using the XRechnung profile, BT-10 must be populated.

BR-CO-18 — Tax amount calculation mismatch. The VAT breakdown in the XML doesn’t match the line-level or total-level tax amounts.

BR-DE-16 — Seller contact email missing. Another German CIUS requirement — the seller must provide a contact email address (BT-43).

Wrong profile declaration — The XML declares Minimum or Basic WL profile, but the sender intends EN 16931 compliance. Or the profile declared doesn’t match the data actually present. This causes validation rules to apply incorrectly.

ZUGFeRD vs Other Formats

ZUGFeRD vs XRechnung — ZUGFeRD is a hybrid (PDF + XML). XRechnung is pure XML. Both are EN 16931-compliant. ZUGFeRD gives you visual + machine-readable in one file; XRechnung is structured data only. For German B2B, both are accepted. For situations where the receiver needs a visual PDF, ZUGFeRD is the practical choice. 

ZUGFeRD vs Factur-X — They’re the same specification since 2020. ZUGFeRD is the German name, Factur-X is the French name. The XML structure, profiles, and validation rules are identical. If you implement one, you’ve implemented the other. 

ZUGFeRD vs UBL — Different XML syntaxes. ZUGFeRD uses CII (Cross Industry Invoice). UBL (Universal Business Language) is the other EN 16931-compliant syntax, used by Peppol and XRechnung. You can’t mix them — a ZUGFeRD invoice contains CII XML, never UBL. 

ZUGFeRD vs Peppol BIS — ZUGFeRD is a format (what the invoice looks like). Peppol is a network (how the invoice gets delivered). They serve different purposes, but they overlap: a ZUGFeRD CII invoice can be sent via Peppol (if the receiver’s Access Point supports CII syntax). In practice, most Peppol participants use UBL, not CII. 

How to Get Started

Step 1: Choose Your Profile

For most use cases: EN 16931. It meets Germany’s mandate, works cross-border, and is Factur-X-compatible for France. Only choose XRechnung profile if you’re specifically invoicing German government entities.

Step 2: Generate the PDF/A-3

Your PDF generation must output PDF/A-3 conformant files. Key requirements: all fonts embedded, ICC color profiles included, no transparency effects, no JavaScript, no encryption. Test PDF/A-3 conformance separately — a valid-looking PDF isn’t necessarily PDF/A-3 compliant.

Step 3: Generate the CII XML

Map your invoice data to CII D16B business terms. The EN 16931 profile requires: invoice number (BT-1), issue date (BT-2), currency (BT-5), seller and buyer identification, line items with amounts, and a complete VAT breakdown.

Step 4: Embed and Validate

Embed factur-x.xml in the PDF with AFRelationship = Alternative. Then validate the complete invoice — both the PDF/A-3 conformance and the CII XML against EN 16931 + profile rules + country CIUS.

 

Active FTP vs Passive FTP

 FTP (File Transfer Protocol) uses two distinct connections for a file transfer:¹

1. Control Connection: This connection is used for sending commands and receiving responses between the FTP client and the FTP server.² It typically uses TCP Port 21 on the server side. This connection remains open throughout the FTP session.
2. Data Connection: This connection is used for the actual transfer of file data and directory listings.³ The way this data connection is established is what differentiates Active FTP from Passive FTP.

Here's a breakdown of the differences:

---

Active FTP

How it works:

1. Control Connection: The FTP client initiates a connection from a random, high-numbered (ephemeral) port (let's say port N > 1023) to the FTP server's command port (typically 21).
2. Client Command: The client then sends a PORT command to the server, informing the server of an ephemeral port (let's say N+1) on the client side that it will use for the data connection, and its own IP address.⁴
3. Server Initiates Data Connection: The FTP server initiates a new connection from its data port (typically 20) to the client's specified IP address and port (N+1).
4. Data Transfer: Once this data connection is established, file transfers (uploads or downloads) and directory listings occur over this connection.⁵

Visual Representation:

Client (Port N) --------> Server (Port 21)  (Control Connection - Client initiates)
Client (Port N+1) <-------- Server (Port 20)  (Data Connection - Server initiates)

Advantages:

• Simpler Server-Side Configuration: The FTP server only needs to open a fixed port (21 for control, 20 for data) for outbound connections, which is often easier to configure on the server's firewall.
• Less Attack Surface on Server: Only specific ports need to be opened inbound on the server.⁶

Disadvantages (and why it's less common today):

• Firewall Issues on Client Side: This is the primary drawback. For the server to initiate the data connection back to the client, the client's firewall needs to allow incoming connections on a specific, dynamic port (N+1). Most client-side firewalls (common in homes and corporate networks) are configured to block unsolicited incoming connections for security reasons. This often results in failed transfers.
• NAT (Network Address Translation) Problems: If the client is behind a NAT router, the IP address the client sends to the server via the PORT command is its private IP address. The server, being on the public internet, cannot connect to this private IP, leading to connection failures.

Use Cases:

• Legacy Systems: Active FTP might still be used in older, more controlled network environments where clients are not behind restrictive firewalls or NAT, or in scenarios where specific firewall rules can be reliably configured on the client side.
• Internal Networks: Within a trusted, internal network where firewall restrictions are minimal.

---

Passive FTP

How it works:

1. Control Connection: Similar to Active FTP, the FTP client initiates a connection from a random, high-numbered port to the FTP server's command port (typically 21).
2. Client Command: The client sends a PASV command (short for "passive") to the server, indicating that it wants to establish the data connection itself.
3. Server Response: The server responds with its public IP address and a randomly chosen ephemeral port (let's say P > 1023) that it has opened and is listening on for the data connection.
4. Client Initiates Data Connection: The FTP client then initiates a new connection from another random client-side port to the server's specified IP address and port (P).
5. Data Transfer: Once this data connection is established, file transfers and directory listings occur.

Visual Representation:

Client (Port N) --------> Server (Port 21)  (Control Connection - Client initiates)
Client (Port M) --------> Server (Port P)   (Data Connection - Client initiates)

Advantages (and why it's more common today):

• Firewall-Friendly: This is the biggest advantage. Since the client initiates both the control and data connections, client-side firewalls typically don't block these outgoing connections. This makes Passive FTP much more reliable for clients behind firewalls or NAT.
• NAT Compatibility: The client connects to the server's public IP address for the data connection, avoiding NAT issues on the client side.
• Default for Browsers and Modern Clients: Most web browsers and modern FTP client software default to Passive mode because of its compatibility with common network configurations.⁷

Disadvantages:

• Server-Side Firewall Complexity: The FTP server's firewall needs to allow incoming connections on a range of high-numbered ports that the server might use for passive data connections.⁸ This requires the server administrator to configure the firewall to open a specific range of ports (e.g., 50000-51000) for incoming connections, which can be a security consideration.
• Higher Resource Usage on Server: Managing a pool of dynamic ports for data connections can be slightly more complex for the server.

Use Cases:

• Internet-facing FTP Servers: Passive FTP is the de facto standard for FTP servers that clients connect to from the public internet, especially when those clients are behind firewalls or NAT.
• General Use: Due to its compatibility, it's the most widely used mode for FTP today.

---

In Summary:

The core difference lies in who initiates the data connection:

• Active FTP: The server initiates the data connection back to the client.
• Passive FTP: The client initiates the data connection to the server.

Passive FTP effectively shifts the responsibility of opening an inbound port from the potentially firewalled client to the typically more controlled and configurable server, making it the preferred and more successful method for FTP transfers in modern network environments.