Prevent Factur-X Rejections in French E-Invoicing Workflows

Share this page

Build and Check the Hybrid Invoice as One Business Document

Factur-X gives a French invoice two coordinated representations: a readable PDF for people and structured Cross Industry Invoice (CII) XML for accounting systems, platforms, and automation. The operational challenge is not merely producing both files. It is ensuring that the XML is complete, the PDF/A-3 package is assembled correctly, and the visible and structured invoice do not contradict each other.

A Factur-X invoice may open normally, show the right customer and totals, and still fail when an accounting system or delivery platform inspects it. Missing metadata, invalid business rules, a false PDF/A claim, or a mismatch between the two representations may be invisible on screen.

The pdfRest Create ZUGFeRD PDF API Tool supports the complete Factur-X document lifecycle. It creates a validated hybrid invoice from XML alone or from XML paired with an existing PDF, and it independently validates completed Factur-X documents without modifying them.

Why Factur-X Matters in France Now

France's electronic-invoicing rollout makes inbound and outbound invoice quality an operational concern, not just a file-format detail. As of September 1, 2026, all affected businesses must be able to receive electronic invoices, and large companies and intermediate-sized enterprises must issue them. The issuance requirement extends to small and medium-sized businesses and micro-enterprises on September 1, 2027, according to the French tax administration's implementation calendar.

Factur-X is designed for this transition because it keeps the familiar invoice PDF together with structured CII XML that software can process. The FNFE-MPE publishes the Factur-X specification and validation resources. But adopting the format also creates a new failure mode: the two representations and the surrounding PDF package can disagree in ways that are invisible on screen.

Creation and validation therefore belong in the same quality strategy. Software vendors, finance platforms, and implementation teams need a repeatable way to produce the hybrid file and inspect it before the invoice reaches a customer, an accounting workflow, or an approved platform.

Create Factur-X from XML or Preserve an Existing PDF

Factur-X creation starts with the CII XML as the canonical invoice data. pdfRest validates the supported profile, schema, business rules, required values, and calculation consistency before producing a document. Invalid XML returns findings rather than a PDF that only appears complete.

Teams can choose the path that fits their current billing system:

XML only: Generate the readable invoice from approved XML, apply optional branding and regional presentation settings, convert it to PDF/A-3, embed the XML, add the required metadata, and validate the completed package.
Existing PDF and XML: Preserve a customer-facing invoice PDF when the information that can be reliably compared agrees with the XML.
Regeneration fallback: Enable regenerate_pdf so canonical XML can produce a replacement visual invoice when the supplied PDF contains a concrete mismatch or cannot be completely confirmed.

Generated and regenerated invoices can use a logo, regular and bold fonts, RGB or CMYK colors, footer text, label language, locale, date formatting, currency presentation, and decimal precision. Label language and regional formatting are independent, which supports multilingual invoice experiences without changing the underlying structured data.

Why Attaching XML Is Not a Complete Factur-X Workflow

Embedding an XML file in a PDF proves only that the PDF has an attachment. Factur-X also depends on the XML profile and business rules, PDF/A-3 conformance, the attachment relationship and MIME type, the expected filename, Factur-X XMP properties, the PDF/A extension schema, and agreement between the visible and structured invoice.

A multi-step homegrown workflow can leave responsibility split between finance, application, and document teams. Each utility may report success while the final package remains unusable. pdfRest treats the XML, visual PDF, PDF/A conversion, embedded attachment, metadata, and final checks as one coordinated output.

Validate the Whole Hybrid Invoice, Not Just the XML

Standalone XML validation answers important questions: Is the XML well formed? Does it satisfy the selected schema and applicable business rules? Are required values and calculations present? It does not answer whether the finished PDF contains that XML correctly or whether the package metadata supports reliable identification and extraction.

A complete Factur-X validation workflow should check:

PDF/A-3 conformance: The document must genuinely conform to its claimed PDF/A-3 level, not merely contain a metadata label.
Embedded invoice XML: The expected CII XML must be present, readable, and associated with a supported Factur-X profile.
Invoice business rules: Required values, code lists, calculations, taxes, totals, and profile-specific rules must be evaluated.
Attachment metadata: Filename, MIME type, relationship, and document catalog entries must identify the XML correctly.
XMP and package metadata: Factur-X properties and the PDF/A extension schema must agree with the embedded invoice.
Detectable PDF and XML consistency: Values that can be reliably associated with visible invoice content should agree with the structured data.

pdfRest combines these checks in one response so teams do not have to reconcile independent tools and invent their own final decision logic.

Use VALID, INVALID, and UNVERIFIED for Different Decisions

Content comparison is not always binary. A PDF can use an arbitrary invoice layout that contains all required visible information but prevents every XML field from being associated with a specific region of the page. Treating that uncertainty as a confirmed match would create false confidence. Treating every incomplete reverse comparison as a definite mismatch would reject otherwise conforming invoices.

pdfRest separates the package decision from content-match confidence:

VALID: The package, XML, business rules, and PDF/A checks pass, with no blocking mismatch.
INVALID: A concrete conformance failure, required missing value, reliable mismatch, or unsupported profile blocks acceptance.
contentMatchStatus: UNVERIFIED: No concrete mismatch was found, but the arbitrary PDF layout did not allow complete reverse confirmation. The response includes a non-blocking PARTIAL_REVERSE_VALIDATION warning.

This distinction lets each organization apply its own policy. A high-volume receiving system might accept a conforming package with an UNVERIFIED content match from a trusted supplier, while a higher-risk workflow routes it for manual review. Concrete mismatches remain blocking in both cases.

Place Validation at the Boundaries That Matter

Factur-X validation is useful at several points in an invoice lifecycle:

Before outbound delivery: Stop malformed packages before they reach a customer or platform and create avoidable rejection cycles.
When onboarding a supplier or generator: Test sample documents from an ERP, billing vendor, or conversion service before approving the integration.
At inbound receipt: Separate usable invoices from documents that need supplier correction or human review.
After system migration: Compare old and new generation pipelines against the same acceptance policy.
After document transformation: Revalidate when another process may have rewritten attachments, fonts, metadata, or PDF structure.

The endpoint accepts a completed hybrid PDF as a direct upload or an existing pdfRest resource ID. It does not accept standalone XML because XML-only validation belongs at the start of creation. Submitting XML to the creation endpoint validates the invoice data before a document is generated; submitting the completed PDF to the validation endpoint checks the final package.

Understand the Supported Profile Boundary

The initial release creates and validates Factur-X 1.09.2 and aligned ZUGFeRD 2.5.2 invoices using the MINIMUM, BASIC WL, BASIC, and EN 16931 profiles. Documents that declare EXTENDED, XRECHNUNG, or another profile outside the current scope return a specific PROFILE_UNSUPPORTED finding instead of being treated as valid.

This boundary matters in procurement and implementation reviews. A buyer should confirm not only that a vendor says it supports Factur-X, but also which versions and profiles the workflow creates and validates. A clear profile result is more useful than a generic pass or an unexplained parser failure.

Common Factur-X Questions

Can I create Factur-X from XML without supplying a PDF?

Yes. Submit the CII XML as a file or resource ID. pdfRest validates the data, generates the visual invoice with the requested styling, completes the PDF/A-3 package, and verifies the result.

Can I preserve my existing branded invoice?

Yes. Supply the PDF with its canonical XML. pdfRest preserves it when the values it can reliably compare agree. If they do not, the request fails by default or can regenerate the visual PDF when that fallback is enabled.

Can a Factur-X PDF look correct and still be invalid?

Yes. Missing or malformed XML, incorrect attachment metadata, incomplete XMP properties, a false PDF/A claim, unsupported profiles, and XML business-rule failures may not change the visible page.

Does pdfRest submit invoices to a French approved platform?

No. pdfRest creates and validates the invoice document. Platform selection, transmission, recipient routing, e-reporting, and business approvals remain in your existing invoicing architecture.

Create with Canonical Data and Validate Before Delivery

Factur-X reduces friction by giving people a readable invoice and systems structured data in the same file. That advantage depends on the package being coherent. Build the document from canonical invoice data, preserve existing visuals when they agree, and validate the completed file before it enters a delivery or accounting workflow.

Try the workflow in API Lab or review the Create ZUGFeRD PDF API Tool for creation and validation options.