Factur-X Format: Complete Guide to All 5 Invoice Profiles

Factur-X is a hybrid electronic invoice format that pairs a machine-readable XML file with a human-readable PDF/A-3 document in a single package. Created through a joint Franco-German initiative, it specifies five compliance profiles ranging from MINIMUM to EXTENDED, each defining progressively richer structured data. Factur-X is technically identical to ZUGFeRD 2.x and serves as the mandatory format for France's national e-invoicing mandate, with the first phase taking effect in 2026.

This guide provides field-level coverage of the entire Factur-X standard. It explains how the hybrid PDF/XML dual-layer structure works, breaks down all five compliance profiles with the specific data elements each one carries, documents the technical equivalence between Factur-X and ZUGFeRD 2.x, details France's CIUS-FR extension requirements, and maps the data extraction depth available at each profile level so you can evaluate what your systems will actually receive.

Most official Factur-X documentation is published in French, and the German-language ZUGFeRD resources rarely address the France-specific extensions. English-language technical coverage of this standard remains thin, particularly for the receiver side of the equation. If you are integrating with French or German e-invoicing infrastructure, processing Factur-X invoices from European trading partners, or evaluating which profile level your organization should request, this reference consolidates what you need in one place.

Understanding Factur-X starts with its dual-layer architecture: a visible PDF for human review and a structured XML payload for automated processing.

How the Hybrid PDF/A-3 Plus XML Structure Works

A Factur-X invoice is a single file that contains two complete representations of the same invoice data. One is designed for human readers. The other is designed for software. Both live inside one PDF, and understanding how they coexist is essential for anyone building or integrating with systems that handle these invoices.

The outer container is a PDF/A-3 file. PDF/A-3 is a specific variant of the PDF format defined under ISO 19005-3, purpose-built for long-term archival storage. What distinguishes PDF/A-3 from a standard PDF is its ability to carry embedded file attachments while maintaining full archival compliance. When a recipient opens a Factur-X invoice in any standard PDF viewer, they see a conventional, visually formatted invoice with headers, line items, totals, and branding. This is the human-readable layer, and it functions identically to any other PDF invoice.

The machine-readable layer is an XML file embedded as an attachment inside that PDF/A-3 container. This attachment is always named factur-x.xml and follows the UN/CEFACT Cross Industry Invoice (CII) data model. The CII standard provides a well-defined schema for representing invoice fields (seller, buyer, line items, tax breakdowns, payment terms, and more) as structured data. Because the XML conforms to this schema, any compliant software can parse the attachment and extract invoice data directly, with no OCR, no template matching, and no visual interpretation required.

This hybrid architecture solves a real problem in invoice exchange. Rather than sending separate files (a formatted PDF for humans plus a data file for ERP import), the sender produces and transmits one document that serves both purposes. Recipients who process invoices manually can open the PDF and read it. Recipients with automated AP workflows can ignore the visual layer entirely and extract structured data from the XML. And because the PDF/A-3 standard enforces archival requirements (embedded fonts, color profiles, no external dependencies), the file meets long-term storage obligations without any additional conversion step.

The Factur-X specification is maintained jointly by FNFE-MPE (Forum National de la Facture Electronique et des Marches Publics), the French e-invoicing standards body, and FeRD (Forum elektronische Rechnung Deutschland), its German counterpart. This Franco-German governance is a direct reflection of the standard's cross-border design goals, and it underpins the formal equivalence between Factur-X and ZUGFeRD that later sections of this guide address. For readers who want to understand how Factur-X fits within the broader global e-invoicing standards ecosystem, our comprehensive guide to e-invoicing standards worldwide provides that context.

The XML attachment is where the structured data lives, but not every Factur-X invoice carries the same depth of data in its XML. The richness of that embedded data depends entirely on which of the five compliance profiles the sender has implemented.

The Five Factur-X Profiles: From MINIMUM to EXTENDED

Factur-X defines five compliance profiles arranged as a strict hierarchy. Each profile includes all structured data from the levels below it and adds new fields. For receivers, this hierarchy directly determines how much machine-readable data you can extract from an incoming invoice without relying on OCR or manual interpretation of the visual PDF layer.

The five Factur-X profiles are MINIMUM, BASIC WL (Without Lines), BASIC, EN 16931 (also referred to as COMFORT), and EXTENDED.

MINIMUM

The MINIMUM profile carries the bare essentials of invoice identification in the embedded XML. You get the invoice number, invoice date, seller and buyer identification (typically through tax registration numbers such as VAT IDs, or French SIREN/SIRET numbers), the currency code, and total amounts at the document level (net, tax, and gross).

No line-item detail is present. The structured data here is roughly equivalent to what OCR would extract from a paper invoice header. Organizations use MINIMUM when the visual PDF remains the primary record and the XML serves only as a basic archival or routing identifier.

BASIC WL (Without Lines)

BASIC WL expands the XML with richer header-level information while still omitting individual line items. Beyond the MINIMUM fields, you gain:

Full seller and buyer names and postal addresses
Payment terms and payment means (bank transfer, direct debit, credit transfer, etc.)
Tax breakdown by rate category, showing each applicable tax rate and its corresponding amount
Document-level references such as purchase order numbers and contract references

This profile suits lightweight AP automation scenarios where matching against a purchase order at the header level is sufficient, and where individual line items are verified visually from the PDF rather than parsed from structured data.

BASIC

BASIC is the first profile that includes structured line-item data in the XML. On top of all BASIC WL fields, each invoice line carries a description, quantity, unit price, and calculated line amount.

For organizations processing multilingual and multi-currency invoices from European trading partners, the BASIC profile is often the minimum practical threshold. It provides the granularity needed for line-item matching against purchase orders, spend categorization, and three-way matching workflows.

EN 16931 (COMFORT)

The EN 16931 profile delivers full compliance with the European semantic data model defined in EN 16931. This is the interoperability standard that underpins e-invoicing across the European Union.

In addition to all BASIC fields, the EN 16931 profile adds:

Item classification codes using standardized schemes (CPV, UNSPSC) for spend analytics and automated categorization
Buyer and seller references for cross-referencing against internal systems
Delivery information including delivery dates and delivery location addresses
Allowances and charges at both the document level and the individual line-item level, covering discounts, surcharges, and adjustments
Standardized code lists for units of measure (UN/ECE Recommendation 20) and tax categories

This profile is required for B2G (business-to-government) invoicing in EU member states. The EN 16931 data model guarantees that any compliant e-invoicing system in the EU can interpret the invoice without ambiguity, making it the baseline for cross-border interoperability.

EXTENDED

The EXTENDED profile provides maximum data richness, adding industry-specific and logistics-oriented fields that go beyond the EN 16931 data model. These additions include:

Detailed delivery and transport information such as consignment references, shipping marks, and transport service descriptions
Additional party roles beyond buyer and seller, including carrier, consignee, invoicee, and payee as distinct entities
Bank account details for multiple parties, enabling automated payment routing in complex supply chain arrangements
Custom extension fields for sector-specific data requirements

EXTENDED is designed for industries with intricate supply chains (manufacturing, logistics, construction) where invoices must carry granular trade and transport data alongside standard financial fields.

Profile Comparison

Profile	Data Scope	Line Items	EN 16931 Compliant	Typical Use Case
MINIMUM	Invoice ID, dates, tax IDs, totals	No	No	Archival compliance, basic routing
BASIC WL	+ Addresses, payment terms, tax breakdown, PO references	No	No	Header-level AP automation
BASIC	+ Line descriptions, quantities, unit prices, line amounts	Yes	No	B2B automation, spend analysis
EN 16931	+ Classification codes, delivery info, allowances/charges, standardized code lists	Yes	Yes	EU B2G invoicing, cross-border interoperability
EXTENDED	+ Transport data, additional party roles, multi-party banking, custom fields	Yes	Yes (superset)	Complex supply chains, logistics, manufacturing

Factur-X and ZUGFeRD 2.x: One Standard, Two Names

Since ZUGFeRD 2.0 was released in 2019, Factur-X and ZUGFeRD have been technically identical specifications. They share the same XML schema (based on UN/CEFACT Cross Industry Invoice), the same five profiles, and the same PDF/A-3 container structure. The only differences between a Factur-X invoice and a ZUGFeRD invoice are the name on the label and the filename of the embedded XML: Factur-X files contain factur-x.xml, while ZUGFeRD files contain zugferd-invoice.xml.

How Two Standards Became One

ZUGFeRD 1.0 launched in 2014 as a Germany-only hybrid invoice format developed by the Forum elektronische Rechnung Deutschland (FeRD). France began developing its own hybrid format around 2017 under the Factur-X name, led by the Forum National de la Facturation Electronique (FNFE). When the French and German standards bodies recognized the overlap, they collaborated to align their specifications. ZUGFeRD 2.0 adopted the Factur-X technical foundation, and both countries agreed to maintain the standard jointly. From that point forward, every release has been published in lockstep under both names. The current version as of late 2025 is Factur-X 1.0.07 / ZUGFeRD 2.3.2. The version numbers differ because each country maintained its own numbering sequence, but the technical content is identical.

Profile Name Mapping Between Factur-X and ZUGFeRD

Four of the five profiles use the same name in both specifications. The one exception is the fourth profile:

Factur-X Profile	ZUGFeRD Profile	Notes
MINIMUM	MINIMUM	Identical
BASIC WL	BASIC WL	Identical
BASIC	BASIC	Identical
EN 16931	COMFORT	Same data, different profile name
EXTENDED	EXTENDED	Identical

The EN 16931 / COMFORT difference is purely a naming convention. ZUGFeRD adopted "COMFORT" as a more user-friendly label for the profile that implements the full European Norm 16931 data model. The underlying XML structure and required fields are exactly the same.

What This Means in Practice

Software that processes ZUGFeRD 2.x invoices can process Factur-X invoices, and the reverse is equally true. The only adaptation required is checking for both XML filenames when extracting the embedded data from the PDF/A-3 container. A receiver-side implementation should look for factur-x.xml first, then fall back to zugferd-invoice.xml (or check both), to handle invoices originating from either country without requiring the sender to identify which "brand" they used.

This technical equivalence has a broader strategic consequence. Germany's adoption of structured e-invoicing for B2G transactions, and its expanding B2B e-invoicing requirements, is fully compatible with France's Factur-X mandate under the Chorus Pro platform and upcoming B2B obligations. Organizations operating across both markets can implement a single processing pipeline for both regulatory regimes.

While the base Factur-X and ZUGFeRD profiles are interchangeable across France and Germany, France layers additional country-specific requirements on top through a mechanism called CIUS-FR.

CIUS-FR: France's Mandatory Extension for E-Invoicing

The EN 16931 profile within Factur-X establishes a European-wide baseline for structured invoice data. France builds on this baseline through CIUS-FR, the Core Invoice Usage Specification for France. CIUS-FR is France's official customization of the EN 16931 standard, and it does not replace the European norm. Instead, it layers additional mandatory fields on top of EN 16931 to satisfy French regulatory and commercial law requirements.

What CIUS-FR Adds Beyond EN 16931

The additional mandatory fields under CIUS-FR reflect data that French tax authorities and commercial regulations require on every invoice:

SIRET number for both buyer and seller. The SIRET (Systeme d'Identification du Repertoire des Etablissements) is France's 14-digit business establishment identifier. Both trading parties must include theirs in the XML payload.
Legal form of the company (SA, SAS, SARL, EURL, and others). French commercial law requires that the issuing entity's legal structure appear on all invoices.
Share capital amount (capital social). Companies registered in France must disclose their registered share capital.
VAT identification number in the specific French format (FR + 2-digit key + 9-digit SIREN).
Chorus Pro service code for B2G (business-to-government) invoices. This routing code ensures the invoice reaches the correct department within a public entity.
Payment penalty terms. French commercial law (Code de commerce, Article L441-10) mandates that invoices state the late payment penalty rate and the fixed recovery indemnity amount.

For organizations receiving Factur-X invoices from French suppliers, these CIUS-FR fields provide richer identification and compliance data than a standard EN 16931 invoice from another EU country would contain.

Chorus Pro and the French E-Invoicing Mandate

Chorus Pro is the French government's centralized e-invoicing platform, operated by the AIFE (Agence pour l'Informatique Financiere de l'Etat). Since 2020, all suppliers issuing invoices to French public entities must submit them through Chorus Pro. According to the European Commission's eInvoicing country report for France, France's Chorus Pro portal processed 78 million invoices in 2023, up from 68 million in 2021, serving more than 160,000 public entities and approximately 910,000 suppliers.

France's broader e-invoicing mandate extends beyond B2G. Starting in 2026, large enterprises will be required to issue and receive structured e-invoices for B2B transactions, with medium-sized and small businesses following by 2027. Factur-X at the EN 16931 profile level with CIUS-FR compliance is the required format for these exchanges.

Understanding profiles and compliance requirements from the sender's perspective, however, is only half the picture. Equally important is knowing what structured data each Factur-X profile actually delivers when you are on the receiving end of one of these invoices.

What Each Profile Level Delivers for Data Extraction

When you receive a Factur-X invoice, the profile level embedded in its XML determines exactly what structured data your systems can extract and process automatically. This distinction matters because it defines the boundary between what can be read directly from the XML and what still requires OCR or manual effort against the PDF layer. The higher the profile, the more you can automate without human intervention.

MINIMUM: Invoice Identification Only

The MINIMUM profile provides the bare essentials: invoice number, issue date, total amounts, and seller/buyer tax identification numbers. Every other data point you might need, including the vendor's name and address, individual line items, and payment instructions, exists only in the visual PDF layer. To access that information, you must either read the PDF manually or run it through OCR, then reconcile the results.

In practice, MINIMUM functions as an archive-compliant wrapper. The XML confirms the document is an invoice and provides enough data to index it, but automation potential is negligible. If your trading partners send MINIMUM-profile invoices, expect your accounts payable workflow to remain largely manual for those documents.

BASIC WL: Structured Party and Payment Data

BASIC WL (Without Lines) marks the first meaningful step toward automation. The XML now includes structured seller and buyer details (legal names, postal addresses, tax registration numbers), payment information (bank account details, payment terms, due dates, payment method codes), and itemized tax breakdowns by rate.

At this level, your AP systems can route invoices to the correct approver by matching structured vendor identifiers rather than relying on OCR-derived text. Payment scheduling becomes possible because due dates and bank details are machine-readable. Basic ledger posting can proceed using the tax breakdown and total amounts. The limitation remains line items: you cannot extract what was purchased or in what quantity from the XML alone.

BASIC: The Line-Item Threshold

The BASIC profile is where data extraction capability shifts fundamentally. Line-item data, including item descriptions, quantities, unit prices, and per-line amounts, becomes available directly in the XML. No OCR is required to determine what was invoiced at the individual item level.

This is the critical threshold for organizations automating financial document processing workflows. With structured line items, you can perform automated three-way matching between purchase orders, goods receipts, and invoice line items. Spend analysis by product category, vendor, or cost center becomes possible using the extracted item-level detail. For AP teams processing invoices from European trading partners, receiving BASIC-profile Factur-X invoices means the data arrives ready for direct ingestion into your matching and approval workflows.

EN 16931: Full Structured Data with Standardized Semantics

Where BASIC gives you item descriptions as free text that your systems must interpret, the EN 16931 profile (also called "Comfort") provides standardized semantics. Classification codes (CPV, UNSPSC) map directly to your chart of accounts without custom translation layers. Allowances and charges are broken out at both document and line level with standardized type codes. Delivery dates, locations, and buyer/seller references follow defined data models rather than free-form fields.

This standardization is what makes fully automated processing viable. Tools that process Factur-X invoices can read every data point from the XML, validate it against known code lists, and route it through approval workflows without manual review of the PDF. EN 16931 invoices are sufficient for end-to-end automation with minimal exception handling, and the profile satisfies the requirements of the European e-invoicing directive for cross-border interoperability.

EXTENDED: Logistics, Transport, and Multi-Party Data

The EXTENDED profile adds fields beyond the EN 16931 standard: shipment and consignment references, carrier and transport details, additional party roles (such as ship-from and ship-to parties distinct from seller and buyer), and industry-specific data elements. Organizations in logistics, manufacturing, and supply chain operations benefit from extracting these fields alongside core invoice data.

For most finance teams outside these industries, EXTENDED provides no additional extraction value over EN 16931. The added fields serve specialized use cases where invoice processing is tightly coupled with shipment tracking or warehouse management systems.

Extraction Capability by Profile

Profile	Extractable Data	Automation Level	Best-Fit Scenario
MINIMUM	Invoice number, date, totals, tax IDs	Manual (PDF/OCR for everything else)	Long-term archiving, basic indexing
BASIC WL	+ Party details, payment info, tax breakdowns	Partial (vendor matching, payment scheduling)	AP routing and payment processing without line-item needs
BASIC	+ Line items (descriptions, quantities, prices)	Partial to high (three-way matching, spend analysis)	Invoice matching and item-level reporting
EN 16931	+ Standardized codes, allowances/charges, delivery info	Full (automated end-to-end processing)	General-purpose e-invoicing, EU compliance
EXTENDED	+ Logistics, transport, additional parties	Full + industry-specific fields	Logistics, manufacturing, supply chain

The profile that delivers the right extraction depth for your organization depends on several factors: whether you are primarily a sender or receiver of invoices, what industry you operate in, and which regulatory frameworks apply to your transactions.

Choosing the Right Factur-X Profile for Your Organization

Selecting a Factur-X profile depends on three factors: your regulatory requirements, whether you are primarily issuing or receiving invoices, and the level of automated data extraction your workflows demand. The weight of each factor varies by geography, industry, and organizational size, but working through them in sequence will point to a clear answer.

Regulatory Requirements Come First

If you issue invoices to French public sector entities, the decision is already made. The B2G mandate requires EN 16931 with the CIUS-FR extension, and no lower profile is accepted. For the broader B2B mandate taking effect in 2026, the minimum accepted profile is MINIMUM, but issuing at EN 16931 or higher is strongly encouraged. A richer XML payload helps your trading partners automate their accounts payable processing, which reduces disputes and accelerates payment cycles.

In Germany, B2G invoicing requires XRechnung rather than ZUGFeRD, but for B2B transactions, ZUGFeRD 2.x (which is technically identical to Factur-X) is the dominant standard. EN 16931, labeled COMFORT in the ZUGFeRD naming convention, is the recommended B2B profile because it aligns with the European norm and ensures cross-border interoperability.

Issuers vs. Receivers

Issuers control the profile level. If you are the issuing party, choose the richest profile your ERP system can reliably populate. Sending incomplete XML at a higher profile is worse than sending a complete, valid file at a lower one.

Receivers, by contrast, depend on what their suppliers send. You cannot unilaterally upgrade the profile of an incoming invoice. However, you can influence it. Specify a minimum Factur-X profile in your procurement terms, supplier onboarding documents, and contractual agreements. If your AP automation requires line-item data for three-way matching or spend analysis, state that you require BASIC or higher. If you need standardized category codes for direct ERP posting, require EN 16931.

Matching Profile to Organization Size and Automation Goals

A quick decision framework based on where your organization falls:

Small businesses with minimal automation can operate with MINIMUM or BASIC WL. These profiles supply enough structured data for basic bookkeeping without burdening small suppliers with complex XML generation.
Mid-size companies running AP automation should target BASIC or EN 16931. Line-item data at the BASIC level enables automated matching, while EN 16931 adds the standardized codes and tax breakdowns needed for touchless processing.
Organizations with EU-wide operations or complex supply chains should standardize on EN 16931 or EXTENDED. Cross-border trade introduces varying VAT treatments, multiple currencies, and diverse regulatory reporting obligations that only these profiles can represent in structured form.

Factur-X in the Broader Invoice Landscape

Factur-X is one format among many in the global e-invoicing ecosystem. Unlike Peppol BIS, which operates as a network delivery protocol, Factur-X is a format specification: it defines the structure of the invoice file itself, not how it is transmitted. FatturaPA (Italy) and SII (Spain) take yet different approaches. Finance teams often handle different types of invoices used in business that carry different format requirements depending on the jurisdiction and transaction type, so understanding where Factur-X sits relative to other standards prevents over-engineering for one format while neglecting others.

Looking Ahead

The EU's VAT in the Digital Age (ViDA) directive is pushing all member states toward mandatory e-invoicing for B2B transactions. As this regulatory pressure intensifies, Factur-X and ZUGFeRD at the EN 16931 profile level are increasingly becoming the baseline for European B2B trade. Organizations that adopt EN 16931 now will already meet the baseline when these mandates take effect, rather than requiring implementation under deadline pressure.