Factur-X 2026: Implementation Guide for SMB Construction

You're a developer at a construction SaaS startup. Your product manager walks in and says: "We need Factur-X 2026 compliance by Q3 2026. It's now mandatory in France for e-invoicing."

Your first thought? Panic. Your second? Questions. What is Factur-X? Why does a construction invoice need XML? How does this change our billing pipeline?

By the end of this guide, you'll understand Factur-X 2026, why it matters for French construction SMBs, and how to implement it without reinventing the wheel.

What Is Factur-X 2026?

Factur-X is a hybrid e-invoicing standard that combines:

• PDF (the human-readable layer for clients)
• XML (the machine-readable layer for compliance and automation)

In a single file, you deliver both. Think of it as a JSON-inside-a-PDF for invoices.

Why 2026? The French government (DGFIP) is phasing in mandatory e-invoicing. From January 2026, all B2B invoices issued by French companies with >€10M revenue must be Factur-X or EDI. From 2027, the threshold drops. By 2028, it's universal (with narrow exceptions for micro-enterprises).

For a construction SaaS targeting French SMBs—plumbers, electricians, general contractors—this isn't optional. Your customers will demand it. Worse, they'll expect you to handle the XML so they don't have to.

Why Construction SMBs Care

Construction invoices are complex:

• Line items tied to chantier (jobsite) references, not abstract SKUs
• Retainage clauses (withholding % until project completion)
• Supplier links (materials, subcontractors, labor)
• Regulatory burden — invoices must reference SIRET, SIREN, TVA numbers

A construction SMB invoice isn't just "paid hours"; it's a legal document. Factur-X forces structure into that complexity. Once structured, the invoice becomes:

1. Machine-processable by tax authorities
2. Automatable for accounts payable (AP)
3. Auditable for multi-year project tracking

Factur-X 2026 Technical Anatomy

The File Structure

A Factur-X invoice (.pdf or .xml) is a ZIP-like container with:

invoice.pdf (PDF layer)
  └── metadata.xml (Factur-X metadata)
  └── xbrls/ (optional XBRL tagging for deep compliance)

The PDF is not embedded in XML; rather, the PDF file itself becomes a container with an embedded XML attachment.

The XML Schema (Simplified)

At its core, Factur-X/EN 16931 requires:

<Invoice>
  <ID>INV-2026-001234</ID>
  <IssueDate>2026-01-15</IssueDate>
  <InvoiceCurrency>EUR</InvoiceCurrency>
  <BuyerParty>
    <PartyLegalEntity>
      <RegistrationName>Acme Construction SARL</RegistrationName>
      <CompanyID>SIRET=FR12345678901234</CompanyID>
    </PartyLegalEntity>
  </BuyerParty>
  <SellerParty>
    <PartyLegalEntity>
      <RegistrationName>Build & Co SAS</RegistrationName>
      <CompanyID>SIRET=FR98765432109876</CompanyID>
    </PartyLegalEntity>
  </SellerParty>
  <InvoiceLines>
    <InvoiceLine>
      <ID>1</ID>
      <Description>Plumbing materials, site A</Description>
      <InvoicedQuantity>10</InvoicedQuantity>
      <UnitPrice>25.00</UnitPrice>
      <LineExtensionAmount>250.00</LineExtensionAmount>
    </InvoiceLine>
  </InvoiceLines>
  <DocumentTotals>
    <InvoiceTotal>305.00</InvoiceTotal>
    <TaxTotal>55.00</TaxTotal>
  </DocumentTotals>
</Invoice>

That's it. No PDF generation magic, no cryptography (yet). Just structured data.

The PDF + XML Merge

The tricky part: embedding the XML into the PDF. You can't just append it; you need to:

1. Generate PDF with your current invoice design (HTML→PDF, e.g., via wkhtmltopdf, Puppeteer, or WeasyPrint)
2. Generate XML from your invoice data
3. Embed XML into PDF as an attached file (using PDF's "embedded file" mechanism)
4. Add PDF metadata to signal Factur-X compliance

Libraries that handle this:

• Python: PyPDF2 + lxml (manual), or fabtx (Factur-X specific, but young)
• Node.js: pdfkit + xml2js (manual), or factur-x-js (beta, very new)
• PHP: PhpOffice/PhpWord + custom XML logic, or codefirst/factur-x (experimental)
• .NET: SelectPdf or GemBox + XML helpers

Pro tip: If you're already using a PDF library (e.g., ReportLab in Python, PDFKit in Node), stick with it and write a small XML-embedding wrapper. Don't switch toolchains mid-project.

Implementation Roadmap for SMBs

Phase 1: Understand Your Data (Week 1–2)

Map your invoice schema to Factur-X/EN 16931 fields:

• Invoice ID, date, currency ✓
• Seller details (company name, VAT/SIRET) ✓
• Buyer details ✓
• Line items (description, qty, unit price, tax rate) ✓
• Totals (net, tax, gross) ✓
• Payment terms (optional but good for construction) ✓

Create a checklist. If you're missing seller SIRET or buyer SIRET, you can't be Factur-X-compliant. For construction, also gather jobsite reference (chantier code) — useful for traceability.

Phase 2: XML Generation (Week 3–4)

Build an XML serializer. Start with a template and fill in values:

# Pseudocode: Python example
from lxml import etree

def create_facturx_xml(invoice_dict):
    root = etree.Element('Invoice')
    etree.SubElement(root, 'ID').text = invoice_dict['id']
    etree.SubElement(root, 'IssueDate').text = invoice_dict['date'].isoformat()
    # ... populate seller, buyer, lines, totals ...
    return etree.tostring(root, pretty_print=True, encoding='utf-8')

Validate your XML against the XSD schema (Factur-X provides official XSD files; download from the FNFE-MPP official repo).

Use online validators (e.g., Xeams XML validator) or your language's XSD library. A bad XML will be rejected by French tax systems.

Phase 3: PDF Embedding (Week 5–6)

Once XML is valid, embed it into your PDF:

# Simplified Python + PyPDF2
from PyPDF2 import PdfWriter
import io

pdf_bytes = generate_pdf(invoice_dict)  # Your existing PDF logic
xml_bytes = create_facturx_xml(invoice_dict).encode('utf-8')

writer = PdfWriter()
reader = PdfReader(io.BytesIO(pdf_bytes))
writer.add_pages(reader.pages)

# Attach XML to PDF (PDF-level attachment)
writer.add_attachment('factur-x.xml', xml_bytes)

# Add PDF metadata to signal Factur-X
writer.add_metadata({
    '/Producer': 'MySaaS/1.0',
})

with open('invoice.pdf', 'wb') as f:
    writer.write(f)

Testing: Download the PDF locally. Open it in a Factur-X validator tool (e.g., Chorus Pro validator or open-source Factur-X-checker). It will unzip the PDF, extract the XML, and validate it against the standard. If it passes, you're golden.

Phase 4: Delivery Integration (Week 7–8)

• Email delivery: Attach the PDF to outgoing invoices (your SMTP already does this)
• Portal download: Ensure your SaaS portal serves the PDF with correct Content-Type: application/pdf
• API endpoint: If you have an invoicing API, return the PDF URL so integrations (accounting software, ERP) can fetch it

Phase 5: Tax Authority Submission (Ongoing)

For B2B invoices above the threshold, the buyer may submit to Chorus Pro (French tax platform) or their own e-invoicing system. Your SaaS doesn't submit directly; the buyer does. You just ensure the PDF is valid.

For micro-enterprises (exemption), no submission required. Make this clear in your product.

Common Pitfalls

1. Forgetting SIRET: The XML will be rejected by DGFIP if seller or buyer SIRET is missing. Validate early.
2. Encoding: Always use UTF-8. Non-ASCII characters (é, ç) will cause XML parse errors.
3. Tax calculations: Rounding errors in tax aggregation. Use decimal.Decimal in Python, not floats.
4. Date format: ISO 8601 (YYYY-MM-DD). Not DD/MM/YYYY.
5. Over-engineering: Factur-X is simple; don't add XBRL, cryptographic signatures, or blockchain unless required. Compliance ≠ complexity.

Real-World Example: A Plumber's Invoice

Your SaaS, Anodos, lets a plumber issue an invoice for a bathroom renovation. The plumber wants the PDF and Factur-X compliance. Here's the flow:

1. Plumber fills in: materials (€500), labor (€300), tax (19.6%), payment terms (30 days).
2. Your backend generates PDF (looks nice, professional).
3. Your backend generates XML with plumber SIRET and client SIRET.
4. You embed XML into PDF.
5. Plumber downloads/emails the PDF.
6. Client's accountant imports the PDF into Chorus Pro or QuickBooks.
7. DGFIP eventually audits the plumber; your invoice is machine-readable and compliant. ✓

Wrapping Up

Factur-X 2026 is not a burden if you implement it systematically:

• Phase 1: Map your schema.
• Phase 2: Build XML generation.
• Phase 3: Embed into PDF.
• Phase 4: Integrate with your delivery pipeline.
• Phase 5: Test with real DGFIP validators.

Start now. Even if your deadline is 2026, you'll want months of testing. Construction invoices are complex; edge cases (retainage, multi-site projects, foreign suppliers) will surface. The sooner you build, the sooner your SMB customers stop worrying about compliance and focus on building homes.

---

Olivier Ebrahim, fondateur d'Anodos — a construction SaaS helping French SMBs digitize invoicing, jobsite management, and regulatory compliance. Currently obsessed with making Factur-X 2026 boring (in a good way).