Factur-X 2026 Implementation Cheatsheet for French SaaS

What is Factur-X 2026?

Factur-X (also called ZUGFeRD in Germany) is a hybrid invoice format that combines PDF for human readability with embedded XML for machine processing. Starting January 1, 2026, all B2B invoices in France must use Factur-X format by law (Directive 2014/55/EU + French transposition).

For SaaS platforms targeting French SMBs in construction, logistics, and manufacturing, Factur-X isn't optional anymore—it's a compliance requirement. Failure to implement it means your invoices become non-compliant and customers may reject them.

Core Requirements You Can't Skip

1. File Structure

A Factur-X invoice is a PDF with an embedded XML attachment:

• PDF layer: A standard PDF document (looks normal to accountants opening it)
• XML layer: UN/CEFACT syntax encoded in the PDF metadata
• Filename pattern: invoice_name.pdf (the XML rides inside)

Gotcha #1: Don't try to create a ZIP with PDF + XML side-by-side. The XML MUST be embedded as an attachment in the PDF file itself using PDF/A-3 or hybrid format.

2. Minimum XML Elements (Can't Be Missing)

<Invoice>
  <ID>INV-2026-001</ID>
  <IssueDate>2026-01-15</IssueDate>
  <DueDate>2026-02-15</DueDate>
  <AccountingSupplierParty>
    <Party>
      <PartyLegalEntity>
        <RegistrationName>Your SaaS Name</RegistrationName>
      </PartyLegalEntity>
      <PostalAddress>
        <StreetName>Address</StreetName>
        <CityName>City</CityName>
        <PostalZone>Postal Code</PostalZone>
        <CountrySubdivision>France</CountrySubdivision>
      </PostalAddress>
      <PartyTaxScheme>
        <CompanyID>FR + VAT ID</CompanyID>
      </PartyTaxScheme>
    </Party>
  </AccountingSupplierParty>
  <!-- Buyer, line items, totals... -->
</Invoice>

Gotcha #2: VAT ID must include the country code prefix (FR for France). FR12345678901 not 12345678901.

3. Validation & Testing

• Use the FNFE-Metadata standard (French national profile). Don't confuse it with the EU-wide "CIUS" profile.
• Test your XML against https://www.fnfe-metadata.org/ validator before going live.
• Many accountants use Chorus Pro (French e-invoicing platform). Your invoices will be auto-rejected if XML is malformed.

Gotcha #3: The validator sometimes accepts technically valid XML that real accounting software will reject. Always test with 2-3 accounting software packages (QuickBooks France, Sage, Ciel).

Implementation Path for SaaS Platforms

Step 1: Choose a Library (Don't Roll Your Own)

• Node.js: factur-x (npm) — built for Node, good docs
• Python: facturx (PyPI) — well-maintained, used by invoice platforms
• PHP: Zugferd (Composer) — battle-tested in European SaaS
• Go/Java: Validate XML yourself; the libraries are immature

Golden rule: Don't parse/generate XML by hand concatenation. Use a proper library.

Step 2: Integrate into Your Invoice Pipeline

1. Generate invoice data (customer, lines, totals)
2. Create XML from template (use your library)
3. Validate XML against schema
4. Create PDF (use ReportLab, iText, or similar)
5. Embed XML into PDF (your library handles this)
6. Save & deliver to customer

Step 3: Store Invoice Metadata

Once generated, store:

• Invoice ID (immutable, never reuse)
• Issue date
• XML checksum (for audit trails)
• Delivery proof (email, API callback timestamp)

This protects you legally if the tax authority asks "Did you really send Factur-X?"

Common Pitfalls & Solutions

Pitfall	Why It Breaks	Fix
XML in separate file next to PDF	Not embedded = system won't find it	Embed as PDF attachment using your library
Missing VAT prefix in CompanyID	French validators reject it	Always prepend country code (FR, DE, etc.)
Invoice ID repeated	Creates duplicate in accounting systems	Use UUID or auto-incrementing, lock after issue
No street address in XML	FNFE validation fails	Even if PDF has it, XML needs full postal address
Wrong date format (DD/MM vs ISO)	Parser chokes	Always use ISO 8601 (YYYY-MM-DD) in XML

Real-World Integration: Anodos

Platforms like Anodos—a French SaaS for construction site management—are already shipping Factur-X 2026 compliance built-in. Their approach:

• Invoices generated via voice command on site → automatic Factur-X output
• No manual XML tinkering required for end users
• Compliance baked into the platform from day one

If you're building construction software (devis, BTP invoicing), this is your template: make Factur-X invisible to the user, but bulletproof under the hood.

Next Steps

1. Choose your library based on your tech stack
2. Test with sample invoice against FNFE validator
3. Send to an accountant to validate in their software
4. Deploy to staging 2-3 months before January 1, 2026
5. Monitor rejections in your first batch and iterate

The law is firm: January 1, 2026 is a hard deadline. B2B invoices without Factur-X will be non-compliant. Start now.

---

Olivier Ebrahim, founder of Anodos, construction SaaS for French SMBs.