What Are Factur-X and ZUGFeRD?
If you've been following the EU's push toward mandatory e-invoicing, you've probably come across the names Factur-X and ZUGFeRD. They sound like different standards, but they're actually the same specification maintained jointly by France (FNFE-MPE) and Germany (FeRD). Factur-X is the French name, ZUGFeRD is the German one. Under the hood, they're identical.
The core idea is simple: take a regular PDF invoice that any human can read, and embed a structured XML file inside it that machines can process automatically. The result is a hybrid document. Your client opens the PDF and sees a normal invoice. Their accounting software opens the same file and extracts all the data it needs without any manual entry.
This approach is especially appealing for small businesses and freelancers because it doesn't require the recipient to have special software. The PDF always works. The XML is a bonus for anyone whose systems can use it.
Why Does This Matter Now?
Several EU countries are rolling out mandatory e-invoicing, and the timelines are approaching fast. Germany requires all businesses to accept e-invoices from January 2025, with mandatory sending following in 2027. France has been phasing in its own mandate since 2024. Other EU member states are following similar paths.
The European standard EN 16931 defines what a valid e-invoice looks like at the data level. Factur-X and ZUGFeRD are one of the approved ways to deliver an EN 16931 compliant invoice. If you're invoicing clients in Germany, France, or across the EU more broadly, this format is one of the simplest routes to compliance.
Beyond the legal requirements, there's a practical benefit. Invoices that carry structured data get processed faster. They're less likely to sit in someone's inbox waiting for manual entry. For freelancers and small businesses, that can mean getting paid sooner.
The Profile System
Not every invoice needs the same level of detail. Factur-X defines several profiles, each adding more structured data to the embedded XML. Think of them as levels of completeness.
Minimum contains just enough to identify the invoice: the invoice number, date, seller, buyer, and total amount. There are no line items. This profile is mainly useful for archiving or when the PDF itself carries all the detail and the XML just serves as a reference.
Basic WL (Without Lines) adds currency, tax breakdown, and payment information, but still no individual line items. It works for simple invoices where the totals are enough.
Basic is the first profile that includes line items with prices, quantities, and tax rates. For most small businesses, this covers the typical use case.
EN 16931 is the profile that fully conforms to the European standard. It includes all mandatory fields defined by EN 16931, making the invoice valid for cross-border compliance and Peppol-compatible workflows.
Extended goes beyond the European standard, adding optional fields for complex scenarios like detailed delivery information, additional document references, or trade-specific data.
For EU compliance, the EN 16931 profile is the one that matters. If you're unsure which to pick, start there. It satisfies the legal requirements while keeping things manageable.
What Fields Does a Compliant Invoice Need?
EN 16931 defines a specific set of mandatory and conditional fields. Here's what your invoice must include at the document level:
Document information covers the invoice number (unique within your system), the issue date, the type code (380 for a standard invoice, 381 for a credit note), and the currency. If payment terms include a due date, that goes here too.
Seller information means your business name, postal address with country code, and at least one tax identifier. For EU businesses, this is typically your VAT number. If your country uses a business registration number (like Germany's Handelsregister or France's SIREN), that should be included as well, along with an electronic address such as your email.
Buyer information follows the same pattern: the client's name, address, country code, and their VAT number if applicable. For B2B invoices within the EU, the buyer's VAT ID is usually required.
Line items are where the actual goods or services appear. Each line needs a description, the quantity, the unit price (net of tax), the VAT rate and category, and the line total. The unit of measure should follow UN/ECE Recommendation 20 codes, so "HUR" for hours, "DAY" for days, "C62" for units, and so on.
Tax summary aggregates the tax information across all line items. For each distinct VAT rate, you list the taxable base amount, the tax amount, the rate, and the category code. The standard category code for regular VAT is "S." For reverse charge situations, it's "AE."
Totals tie everything together: the sum of all line totals (before tax), the total tax amount, and the grand total including tax. The amount due for payment must also be stated, which in most cases equals the grand total.
Payment information specifies how the buyer should pay. The payment means code indicates the method: 30 for generic bank transfer, 58 for SEPA credit transfer, 59 for SEPA direct debit. If you're using bank transfer, include your IBAN and optionally your BIC.
The XML Structure
Under the hood, the embedded XML follows the Cross Industry Invoice (CII) format, specifically the D16B version defined by UN/CEFACT. If you've never looked at CII XML before, here's the basic skeleton:
<?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:ReusableAggregate..."
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
<rsm:ExchangedDocumentContext>
<!-- Profile identifier goes here -->
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<!-- Invoice number, type code, issue date -->
</rsm:ExchangedDocument>
<rsm:SupplyChainTradeTransaction>
<!-- Line items -->
<!-- Seller and buyer details -->
<!-- Delivery information -->
<!-- Payment and tax summary -->
<!-- Totals -->
</rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>
The XML is divided into three main blocks. The ExchangedDocumentContext identifies which profile you're using, such as urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931 for the EN 16931 profile. The ExchangedDocument carries the invoice metadata. And the SupplyChainTradeTransaction contains everything else: the trade parties, the line items, the tax calculations, and the monetary totals.
You don't need to write this XML by hand. Invoicing tools that support Factur-X generate it automatically from your invoice data.
How the PDF Embedding Works
A Factur-X invoice isn't just a PDF with an XML file zipped alongside it. The XML is embedded inside the PDF itself as a file attachment, following the PDF/A-3 standard. This is what makes it a true hybrid document: one file, two representations.
The PDF must conform to PDF/A-3b, an archival standard that ensures the document can be reliably opened decades from now. This means the PDF includes an ICC color profile, XMP metadata, and specific flags that mark it as PDF/A compliant.
The embedded XML file is always named factur-x.xml and is attached with an AFRelationship of "Alternative," which tells PDF readers that the attachment is an alternative representation of the document content (not just a random file someone attached).
The XMP metadata inside the PDF also includes Factur-X-specific fields: the document type (INVOICE or CREDITNOTE), the XML filename, the Factur-X version, and the conformance level (which profile you're using).
Common Mistakes to Avoid
Using the wrong profile identifier. The guideline ID in the XML must exactly match the profile you intend. For EN 16931 compliance, it should be urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931. A typo or the wrong URI means validators will reject the file.
Missing or incorrect tax category codes. Every line item and every entry in the tax summary needs the right category code. Standard VAT is "S," exempt is "E," reverse charge is "AE," and zero-rate is "Z." Mixing these up is one of the most common validation errors.
Inconsistent totals. The sum of your line totals must equal the tax basis total. The tax basis plus the tax total must equal the grand total. Validators check these arithmetic relationships, and even a one-cent rounding difference will cause a failure.
Omitting the seller or buyer electronic address. EN 16931 requires both parties to have an electronic address. For most businesses, this is simply the email address with a scheme ID of "EM."
Forgetting the business registration scheme ID. When you include a business registration number, the scheme ID must be a valid ISO 6523 ICD code. For example, Germany uses 0204, France uses 0002, the Netherlands uses 0106. Using an incorrect code will fail Peppol validation.
How to Validate Your Invoice
Before sending a Factur-X invoice to a client or submitting it to a government portal, it's worth running it through a validator. Several free options exist:
ecosio offers an online validator at ecosio.com that checks both the XML structure and the business rules. Upload the extracted XML file and it will tell you immediately whether your invoice passes EN 16931 and Peppol validation, including any warnings.
FeRD (the Forum for Electronic Invoicing Germany) provides a validator specifically designed for ZUGFeRD and Factur-X documents.
Chorus Pro is France's government portal for e-invoicing. If you're invoicing French public entities, your invoices ultimately need to pass Chorus Pro's validation.
The key thing to remember is that validators check the XML, not the PDF. If you're working with a hybrid Factur-X PDF, you first need to extract the embedded factur-x.xml file before uploading it.
How Facturwise Handles This
Facturwise generates Factur-X compliant invoices automatically. Every time you create an invoice, the system builds the CII XML from your invoice data, embeds it into a PDF/A-3 document with the proper metadata, and produces a single file that's both human-readable and machine-processable.
The XML conforms to the EN 16931 profile, meaning it meets the European standard right out of the box. Seller and buyer details, line items, tax breakdowns, payment information, and SEPA bank details are all mapped to the correct CII fields. ISO 6523 scheme IDs are assigned automatically based on each party's country.
You don't need to configure anything or understand the XML format. Just fill in your invoice as you normally would, and the compliance layer works in the background.
If you need to verify a specific invoice, you can extract the XML from the PDF and upload it to a validator like ecosio to confirm it passes. But in day-to-day use, the process is invisible. You create an invoice, send it to your client, and the structured data rides along inside the PDF.
Facturwise is an invoicing tool built for freelancers and small businesses in Europe. Every invoice includes embedded Factur-X XML at the EN 16931 profile level, so you stay compliant without extra effort. Create your first invoice for free.