Factur-X REST API: The Complete Hybrid E-Invoice Toolkit for France and Beyond

France's B2B e-invoicing mandate begins September 2026. Large and mid-sized companies must be able to both send and receive structured e-invoices through a certified Plateforme Agréée (PA) connected to government infrastructure. Factur-X — the Franco-German hybrid format that embeds machine-readable CII XML inside a human-readable PDF/A-3 document — is one of the three accepted formats alongside plain CII and UBL. For most French businesses, it will be the preferred choice: it looks like a normal PDF invoice while carrying the structured data layer that tax authorities and ERP systems require.

Building Factur-X support into your product, however, is not simply a matter of appending XML to a PDF. Factur-X has specific requirements around PDF/A-3 conformance, embedded file naming conventions, attachment relationships, XMP metadata, and ICC colour profiles that must all be correct for the output to be accepted by certified platforms and validated successfully. Get any one of them wrong and your invoices fail at the PPF (Portail Public de Facturation) or your trading partner's AP system — often with an error message that gives you no clue which part of the PDF/A-3 structure failed.

InvoiceXML handles all of this for you via a complete Factur-X API toolkit. This post covers every tool available, what makes Factur-X technically distinct from plain CII or UBL, and why the PDF/A-3 embedding layer is where most self-built implementations go wrong.

What is Factur-X? The hybrid format explained

Factur-X is a hybrid e-invoice format co-developed by France (FNFE-MPE) and Germany (FeRD). At the technical level it is identical to ZUGFeRD 2.x — the same CII XML structure, the same EN 16931 profiles, the same Schematron validation rules. The difference is purely in the declared specification identifier and the naming conventions used in the PDF/A-3 container.

What makes Factur-X fundamentally different from standalone CII or UBL is the dual-layer architecture:

Factur-X Invoice
├── PDF/A-3b visual layer       ← what humans see when they open the file
│   ├── Visual invoice layout
│   ├── Company logo, formatting
│   └── XMP metadata (declares Factur-X compliance)
└── factur-x.xml attachment     ← what machines read
    ├── CII XML data
    ├── EN 16931 profile declaration
    └── All structured invoice fields (BT-xx)

Both layers must contain the same invoice data. The PDF visual layer exists for human readability — AP staff, auditors, and recipients without ERP systems can open it in any PDF viewer. The embedded XML exists for machine processing — ERP import, automated AP matching, tax authority reporting. The legal standing belongs to the XML layer; the PDF layer is presentation only.

This dual-layer design is Factur-X's main advantage over pure XML formats like XRechnung or standalone CII: it eliminates the "we can't open this XML file" problem entirely. The same file is valid for both human and automated workflows. But it also creates a unique compliance challenge: you must ensure both layers are consistent and that the PDF/A-3 container meets archival standards.

Here is the specification identifier that distinguishes Factur-X profiles in the embedded XML:

<!-- Factur-X EN 16931 (Comfort) profile -->
<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:factur-x.eu:1p0:en16931</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

<!-- Factur-X MINIMUM profile -->
<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:factur-x.eu:1p0:minimum</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

<!-- Factur-X EXTENDED profile -->
<ram:GuidelineSpecifiedDocumentContextParameter>
  <ram:ID>urn:factur-x.eu:1p0:extended</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

Compare this to ZUGFeRD, which uses identifiers like urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:en16931 — technically the same XML underneath, different spec identifier string. The InvoiceXML API handles both and generates the correct identifier automatically based on the requested output format.

The PDF/A-3b requirement: why it matters and what it means

PDF/A-3 is the ISO archival PDF standard that permits embedded file attachments. Not all PDF files qualify as PDF/A-3. The requirements include:

• All fonts must be embedded in the document (no external font references)
• No encryption, password protection, or JavaScript
• Colour profiles must be explicitly specified (typically sRGB with an ICC profile embedded)
• XMP metadata must be present and correctly structured
• The embedded XML attachment must be declared with the correct MIME type (text/xml) and the specific AFRelationship value (Alternative for Factur-X)
• The embedded file must be named exactly factur-x.xml (not invoice.xml, not FX.xml)

A PDF that fails any of these requirements is not PDF/A-3b compliant and will fail validation by tools like veraPDF, the Mustang validator, or the PPF acceptance checks. Many invoices generated by accounting software are not PDF/A-3 compliant even though they look identical to compliant invoices in a PDF viewer. Ordinary PDF viewers do not enforce PDF/A-3 conformance — you will not see an error opening a non-compliant file. You only discover the problem when you submit it.

The InvoiceXML Factur-X API toolkit

Every endpoint in the Factur-X toolkit produces output validated against the EN 16931 Schematron and — for endpoints that produce PDF/A-3b output — verified for PDF/A-3b conformance before delivery.

Base URL: https://api.invoicexml.com
Authentication: Authorization: Bearer YOUR_API_KEY
Content-Type: multipart/form-data

Tool 1: Create Factur-X from JSON data

What it does: Accepts structured invoice data as form fields and returns a complete, valid Factur-X PDF/A-3b file. Unlike the transform endpoint (which starts from an existing PDF), the create endpoint generates both the XML and a clean PDF visual layer from your data — no source document required.

When to use it: You are building invoicing into a SaaS product and want to offer Factur-X output as a native feature. You have invoice data in your database and want to produce a complete Factur-X file ready for transmission or storage. You want to generate Factur-X invoices programmatically without maintaining a PDF template engine alongside a CII XML generator.

curl -X POST https://api.invoicexml.com/v1/create/facturx \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "InvoiceNumber=FA-2025-0142" \
  -F "IssueDate=2025-09-01" \
  -F "PaymentDueDate=2025-10-01" \
  -F "SellerName=Dupont Conseil SARL" \
  -F "SellerTaxId=FR32123456789" \
  -F "SellerStreet=12 Rue de Rivoli" \
  -F "SellerPostcode=75001" \
  -F "SellerCity=Paris" \
  -F "SellerCountry=FR" \
  -F "BuyerName=Martin Industries SAS" \
  -F "BuyerTaxId=FR98765432100" \
  -F "BuyerStreet=45 Avenue des Champs-Elysées" \
  -F "BuyerPostcode=75008" \
  -F "BuyerCity=Paris" \
  -F "BuyerCountry=FR" \
  -F "Currency=EUR" \
  -F "TaxBasisTotal=2500.00" \
  -F "TaxTotalAmount=500.00" \
  -F "GrandTotalAmount=3000.00" \
  -F "PaymentMeansCode=30" \
  -F "IBAN=FR7630006000011234567890189" \
  -F "Lines[0][description]=Conseil en transformation digitale" \
  -F "Lines[0][quantity]=10" \
  -F "Lines[0][unitPrice]=250.00" \
  -F "Lines[0][lineTotal]=2500.00" \
  -F "Lines[0][unitCode]=HUR" \
  -F "Lines[0][taxPercentage]=20" \
  -F "Lines[0][taxCategoryCode]=S"

The response is a binary PDF/A-3b file with the factur-x.xml attachment embedded, the XMP metadata correctly populated, and the EN 16931 Schematron validated before delivery. Ready to transmit to a certified Plateforme Agréée, send to a French trading partner, or store in a GDPR-compliant document archive.

Tool 2: Validate Factur-X

What it does: Accepts a Factur-X PDF and runs a multi-layer validation pipeline: extracts the embedded factur-x.xml attachment, validates it against the CII D16B XSD schema, validates it against the EN 16931 Schematron business rules, and checks the PDF container for PDF/A-3b conformance. Returns a structured result with per-rule violation detail.

This is the validation that matters before submission to a French Plateforme Agréée. The PPF and certified PAs run their own validation on receipt — if your invoice fails there, it is rejected and you typically receive a rejection notification without a detailed explanation. Running validation through InvoiceXML before submission gives you the specific rule violations with human-readable descriptions, so you can fix the problem before it becomes a submission failure.

When to use it: Before submitting to a French Plateforme Agréée or a Peppol access point. When receiving Factur-X invoices from suppliers and wanting to verify their compliance before ingesting into your ERP. When testing your Factur-X generation pipeline during development.

curl -X POST https://api.invoicexml.com/v1/validate/facturx \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

A valid invoice returns:

{
  "valid": true,
  "profile": "urn:factur-x.eu:1p0:en16931",
  "version": "1.07",
  "errorCount": 0,
  "errors": []
}

Note the profile and version fields in the response — these are read directly from the embedded XML's specification identifier, not assumed. This lets you confirm that the invoice declares the profile you intended and that the spec identifier is correctly formed.

A failing validation returns structured errors with rule ID, human-readable message, and XPath context:

{
  "valid": false,
  "profile": "urn:factur-x.eu:1p0:en16931",
  "version": "1.07",
  "errorCount": 1,
  "errors": [
    {
      "rule": "BR-S-08",
      "message": "For invoices with a standard VAT category (S), the VAT category rate must be greater than zero.",
      "source": "schematron",
      "severity": "error",
      "context": "/rsm:CrossIndustryInvoice/.../ram:ApplicableTradeTax"
    }
  ]
}

Pass ?errors=friendly to get user-facing plain-language error descriptions alongside the technical ones — useful when surfacing validation results to non-technical users in a dashboard or no-code workflow.

Tool 3: Extract structured data from Factur-X

What it does: Accepts a Factur-X PDF and extracts the embedded CII XML attachment. If the PDF is a valid Factur-X file, the embedded factur-x.xml is returned directly. If no embedded XML is found (for example, a plain PDF that was incorrectly treated as Factur-X), the AI extraction pipeline falls back to reading the visual PDF layer and generating CII XML from it.

For use cases where you need the invoice data as structured JSON rather than raw XML — for ERP ingestion, database storage, or API integration — the /v1/extract/json endpoint runs the full AI validation pipeline including arithmetic verification, VAT number format checking, and address plausibility analysis before returning a normalised JSON object.

When to use it: You receive Factur-X invoices from French suppliers and need to import the structured data into your ERP or accounting system. You want to archive the CII XML layer separately from the PDF for compliance purposes. You are building an AP automation workflow that processes incoming Factur-X invoices from a shared inbox.

# Extract embedded CII XML
curl -X POST https://api.invoicexml.com/v1/extract/xml \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output invoice-cii.xml

# Extract as validated JSON
curl -X POST https://api.invoicexml.com/v1/extract/json \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

The JSON extraction response includes a confidence score per field — a float between 0 and 1 indicating how confidently the value was extracted. Fields extracted directly from the embedded XML have a confidence of 1.0. Fields that required AI inference (for example, when falling back to PDF text extraction) carry lower scores, allowing your application to flag low-confidence fields for human review rather than silently ingesting potentially incorrect data.

Tool 4: Convert any PDF to Factur-X

What it does: Accepts any invoice document and returns a Factur-X-compliant PDF/A-3b with an embedded factur-x.xml attachment. The AI pipeline extracts every EN 16931 required field from the source document, maps it to the CII schema, validates the XML, converts your source PDF to PDF/A-3b conformance, embeds the XML as an Alternative attachment with correct XMP metadata, and returns the complete hybrid file.

This is what makes InvoiceXML different from a library: producing a valid Factur-X file requires two independent technical capabilities at the same time — AI invoice data extraction and PDF/A-3b conversion. Open-source libraries handle the XML generation side. None of them take a non-compliant PDF and produce a valid PDF/A-3b container. That step requires PDF processing infrastructure that is entirely separate from the compliance layer.

When to use it: Your business sends PDF invoices and needs to add Factur-X compliance for French customers or for France's September 2026 mandate. You are building an invoicing platform and want to add Factur-X output without implementing PDF/A-3b conversion. Your ERP system generates PDF invoices and you want to automate the compliance layer without replacing your existing document generation.

curl -X POST https://api.invoicexml.com/v1/transform/to/facturx \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  -F "profile=en16931" \
  -F "version=1.07" \
  -F "embed=true"

The version parameter specifies the Factur-X specification version. The current production version is 1.07 (also referred to as ZUGFeRD 2.3.2 in German contexts). The latest release is 1.08 (ZUGFeRD 2.4), which introduced mandatory service period dates and deprecated NIL elements. Defaults to the latest supported version if omitted.

Setting embed=false returns standalone CII XML without a PDF wrapper — useful when you want the structured data only, not the hybrid file.

Accepted input formats: PDF (native and scanned), JPEG, PNG, TIFF, WEBP, HEIC, DOCX, XLSX.

Tool 5: Convert between Factur-X and other formats

What it does: Converts Factur-X to other e-invoice formats and vice versa, enabling interoperability between the Franco-German hybrid ecosystem and UBL-based networks like Peppol.

The cross-border use case: A French company using Factur-X for domestic invoicing needs to submit invoices to a Belgian customer via Peppol (UBL). Rather than maintaining two separate invoice generation pipelines, they generate Factur-X natively, then call the convert endpoint to produce Peppol-ready UBL on demand. Conversely, a French importer receiving Peppol UBL invoices from Dutch suppliers can convert them to Factur-X for archiving in their DMS, since their document management system may expect PDF/A-3 format for long-term compliance storage.

# Extract CII from Factur-X, then convert to UBL (two steps)
curl -X POST https://api.invoicexml.com/v1/extract/xml \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output extracted-cii.xml

curl -X POST https://api.invoicexml.com/v1/convert/cii/to/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output invoice-ubl.xml

# Convert UBL to CII (for embedding into Factur-X)
curl -X POST https://api.invoicexml.com/v1/convert/ubl/to/cii \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output invoice-cii.xml

Once you have the CII XML from the UBL conversion, pass it to POST /v1/create/facturx with the embed=true parameter and supply your source PDF — the API will embed the converted CII XML into a PDF/A-3b Factur-X container.

The Factur-X version history: why staying current matters

Factur-X has evolved significantly since its initial release. Each version introduced new mandatory fields, deprecated elements, and refined business rules:

1.08 is the version that catches teams off guard. The requirement for a machine-readable service period date (when the goods were delivered or services performed) was previously optional. In 1.08 it became mandatory in many contexts. Invoices that passed validation under 1.07 started failing under 1.08 without any change to the invoice data — simply because the standard tightened its rules. Any self-managed Schematron implementation needs to be updated whenever a new version ships, tested, and redeployed before the previous version is deprecated.

InvoiceXML deploys new Factur-X version support ahead of the version's effective date. You do not need to track FeRD releases, download new Schematron files, or update your validation pipeline. The API version is updated transparently and your integration continues working.

The France 2026 mandate: what developers need to know now

France's e-invoicing reform is the largest compliance rollout in Europe since Italy's FatturaPA mandate. The timeline for B2B invoicing via certified Plateforme Agréée (PA):

• September 2026: Mandatory receipt for all businesses. Mandatory issuance for large companies (>5,000 employees or >1.5bn EUR turnover).
• September 2027: Mandatory issuance for mid-sized companies (>250 employees or >50m EUR turnover).
• September 2028: Mandatory issuance for all VAT-registered businesses.

Three formats are accepted: Factur-X, CII, and UBL. In practice, Factur-X will dominate for most French businesses because it is the only format that is simultaneously human-readable (PDF) and machine-processable (XML). Finance teams that currently operate with PDF invoices can switch to Factur-X with minimal workflow disruption — the file looks identical to a normal PDF in their email client.

For developers and ISVs, the opportunity is significant: every French accounting platform, ERP integration, and invoicing tool needs to add Factur-X support before their customers hit the mandate deadline. The InvoiceXML API is designed for exactly this integration pattern — add e-invoicing compliance to your existing product with a single API call, without implementing the PDF/A-3b embedding, CII schema, or Schematron validation yourself.

Why the PDF/A-3b layer is where self-built implementations fail

The XML side of Factur-X is well-served by open-source libraries. The PDF/A-3b side is not. Here is what a correct PDF/A-3b Factur-X implementation actually requires:

Correct ICC colour profile embedding. PDF/A-3b requires that all colour spaces reference an embedded ICC profile. Invoices containing images, logos, or coloured text that do not have embedded ICC profiles fail PDF/A-3b validation, even if the CII XML is entirely correct. Getting this right requires not just adding an ICC profile but ensuring every colour space in the document references it.

Correct XMP metadata. The PDF/A-3b container requires specific XMP metadata extensions that declare the Factur-X version, profile, and conformance level. The metadata must use the correct XML namespace (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#) and contain the correct property values. A missing or malformed XMP block causes the file to fail PDF/A-3 conformance checks even if the attachment and CII XML are both valid.

Correct AFRelationship value. The embedded file attachment must be declared with AFRelationship="Alternative" — not Supplement, not Data, not Unspecified. This specific value tells reading applications that the embedded XML is an alternative representation of the same content as the visual PDF. Many PDF generation libraries either do not support this attribute or set it to an incorrect value.

Font subsetting. All fonts used in the PDF must be embedded, subset, and declared correctly. Invoices generated from HTML-to-PDF renderers, LibreOffice, or some ERP export functions often reference system fonts without embedding them, which fails PDF/A-3 validation.

None of these problems are visible when you open the file in Adobe Acrobat Reader or a browser PDF viewer. They only surface when the file is run through a conformance validator or submitted to a certified PA. InvoiceXML handles every layer of this correctly — PDF/A-3b conformance is tested on every file before it leaves the API.

Security, compliance, and data handling

Factur-X invoices contain particularly sensitive data: French SIRET numbers, IBAN details, professional relationships between companies, payment amounts. A processing service that retains invoice data — even temporarily for logging purposes — creates a GDPR liability for every customer using it.

InvoiceXML is stateless by design. Every document is processed in memory. Nothing is written to disk. Nothing is retained after the API response is delivered. No invoice data is used for model training or analytics. This is not a configurable option or a paid tier — it is the default and only behaviour, enforced at the infrastructure level.

We are GDPR-compliant and HIPAA-certified, independently audited. Our security team monitors the infrastructure 24/7, with automated detection of anomalous API behaviour, regular penetration testing, and dependency audits on every component in the processing pipeline. For French customers specifically: all processing occurs within EU infrastructure. Data never leaves European jurisdiction.

Our status page shows full uptime history. 99.95% uptime is a contractual SLA on Professional and above plans — not a marketing target.

Complete Factur-X API endpoint reference

All endpoints are available at https://api.invoicexml.com. Authentication uses Bearer token in the Authorization header. Error responses follow RFC 7807 ProblemDetails with structured errorCode fields and human-readable friendly error messages.

Full OpenAPI 3.1 schema available at api.invoicexml.com/openapi.

Supported Factur-X profiles

The EN 16931 profile is the recommended default for most B2B use cases. The MINIMUM profile is primarily used for AP automation scenarios where the receiving system only needs the header-level payment data and will match against a purchase order for the line item details.

Get started

Try the Factur-X tools without creating an account: upload any PDF invoice at invoicexml.com/pdf-to-facturx and download a compliant Factur-X file in seconds.

To integrate via API, start your free 30-day trial. The permanent free tier includes 100 credits per month — enough to keep your development and testing environment running indefinitely without a paid plan.

Related resources:

• How the AI document pipeline works
• Full API documentation
• CII API: the complete toolkit
• UBL API: the complete toolkit
• Automation and no-code integrations
• Pricing

InvoiceXML is the compliance layer for modern European e-invoicing. It covers Factur-X, ZUGFeRD, XRechnung, CII, UBL, and EN 16931 via a single REST API — with stateless processing, no data retention, and no PDF/A-3b implementation required on your side.