France E-Invoice Validator API - Factur-X, UBL & CII

Technical validation only. ACCEPTED means the submitted invoice passed the pinned offline checks described below. It does not establish legal or tax validity, issuer authenticity, approved-platform acceptance, successful transmission, or recipient acceptance.

Validate French electronic invoices in UBL 2.1, UN/CEFACT CII D22B, and Factur-X 1.09 through one batch API. Every evaluated document receives a deterministic result, structured findings, the input SHA-256, and the exact rule versions used.

Run the live Actor

Supported routes

Input	Profiles	Required checks
UBL 2.1 Invoice	EN 16931, EXTENDED-CTC-FR	UBL XSD, EN 16931 or EXTENDED-CTC-FR profile rules, French BR-FR rules
UBL 2.1 CreditNote	EN 16931, EXTENDED-CTC-FR	UBL XSD, EN 16931 or EXTENDED-CTC-FR profile rules, French BR-FR rules
CII D22B XML	EN 16931, EXTENDED-CTC-FR	UN/CEFACT CII XSD, profile rules, French BR-FR rules
Factur-X XML	EN16931, EXTENDED	CII or Factur-X profile XSD, profile rules, French BR-FR rules
Factur-X PDF/A-3	EN16931, EXTENDED	veraPDF PDF/A-3, safe embedded XML extraction, attachment and XMP consistency, Factur-X checks, then France_RFE checks

The active business-rule package is the FNFE-MPE France_RFE v1.4.0.02 release for the French reform effective 1 September 2026. The production image does not download rules at runtime.

For Factur-X PDF only, the attachment relationship accepts Data, Alternative, and the Source value used by the official France_RFE examples. Source is enabled only for the Factur-X XMP namespace, the canonical factur-x.xml filename, and supported EN16931 or EXTENDED profiles. Other relationship values remain rejected.

Quick start

The default input uses a public fixture pinned to an immutable commit:

{
  "documents": [
    {
      "documentId": "france-en16931-ubl-sample",
      "fileName": "ubl-21-en16931.xml",
      "url": "https://raw.githubusercontent.com/akretion/factur-x/5edb9af9186e5f06f446372688e6fdbbd0b790d3/tests/fixtures/xml/ubl-21-en16931.xml"
    }
  ],
  "resultDetail": "FINDINGS",
  "maxFindingsPerDocument": 100,
  "storeXmlReport": false,
  "storeHtmlReport": false,
  "storePdfaReport": false,
  "storeExtractedInvoiceXml": false
}

Send each document through exactly one source field:

• url: public or signed HTTPS URL
• xml: inline XML
• base64: base64 XML or PDF
• console file upload
• a record in a customer-selected Apify key-value store

The input and output schemas are agent-readable and work with the Apify API, MCP clients, Make, n8n, webhooks, and standard SDKs.

Result contract

One dataset item is returned for every submitted entry. A technically rejected invoice is a completed evaluation, not a processing failure.

Processing	Conformance	Meaning	invoice-validated event
SUCCEEDED	ACCEPTED	Every required pinned technical layer passed	Charged
SUCCEEDED	REJECTED	The invoice was evaluated and one or more required rules failed	Charged
FAILED	NOT_EVALUATED	A source, format, engine, timeout, or safety failure prevented a decision	Not charged

The common family schema includes:

• processingStatus
• conformanceStatus
• validationScope
• externalStateStatus
• rulesetEffectiveAt
• validationFamily
• syntax
• profile
• scenario
• versions
• counts
• findings
• sha256
• error

Each finding includes a severity, validation stage, rule ID, message, and location when the upstream report provides one. previewConformanceStatus remains NOT_EVALUATED until a future France_RFE package is deliberately added as a separate preview ruleset.

externalStateStatus is always NOT_EVALUATED_EXTERNAL_STATE because approved-platform, transmission, registry, delivery, and recipient state are outside offline preflight.

Real run examples

These compact examples are taken from a real three-document Actor run.

Pricing

The invoice-validated event costs $0.004.

• ACCEPTED: billed once
• REJECTED: billed once
• NOT_EVALUATED: free
• Dataset delivery does not add a second charge
• The Actor stops before processing unless the event price is exactly $0.004

One malformed or unavailable source does not kill the remaining batch.

Optional reports

All optional records are off by default:

• storeXmlReport: normalized active-rule report
• storeHtmlReport: script-free human-readable report
• storePdfaReport: sanitized veraPDF report for a Factur-X PDF
• storeExtractedInvoiceXml: complete XML extracted from a Factur-X PDF

Reports can contain invoice values and follow the retention settings of the customer's Apify account.

Security and limits

• Validation runs locally inside the Actor container.
• No invoice is sent to a third-party validation service.
• HTTPS downloads block private, local, reserved, and cloud metadata targets.
• DTDs, entities, and external XML resources are blocked.
• XML Schema parsing disables network resolution.
• Java validation stages use bounded heap, timeouts, and bounded reports.
• PDF parsing runs in an isolated process with CPU, memory, file, and descriptor limits.
• Raw invoice content is not copied to the output dataset or application logs.
• Each XML is limited to 5 MiB.
• Each PDF is limited to 20 MiB and 100 pages.
• A run can evaluate up to 100 documents, including at most 20 PDFs and 100 MiB total input.
• Finding fields and the total returned findings payload are bounded.

Validation findings can quote an offending invoice value. Treat results and optional reports as sensitive accounting data.

Pinned stack

Component	Version or identity
France_RFE	v1.4.0.02
France_RFE commit	e9520ce398cc99bed4bab493773a494af8ca5aff
France_RFE tag archive SHA-256	5d30054c99d970457ca50c89ce895770cae695f5fe8d73750433079f9f1ec3a1
XP Z12-012 profile generation	1.4
EN 16931 Schematron	1.3.16
UBL	2.1
UN/CEFACT CII	D22B
Factur-X	1.09
Factur-X EXTENDED schema patch	1.09.2
Mustangproject	2.24.0
SaxonJ-HE in Mustangproject	12.8
veraPDF	1.30.2

Docker builds verify every downloaded archive or executable against a fixed SHA-256. Every executed XSD and XSLT also has its own SHA-256 in the manifest and is verified again before use. A mismatch stops validation.

Release gates

The release fixture runner downloads the immutable France_RFE tag archive, verifies its SHA-256, and extracts official FNFE examples only inside a temporary test directory. It checks:

• official EN 16931 UBL invoice: ACCEPTED
• official EN 16931 UBL credit note: ACCEPTED
• official EN 16931 CII invoice: ACCEPTED
• official EXTENDED-CTC-FR UBL invoice: ACCEPTED
• official EXTENDED-CTC-FR CII invoice: ACCEPTED
• official Factur-X EXTENDED XML: ACCEPTED
• official Factur-X EXTENDED PDF/A-3 using AFRelationship Source: ACCEPTED
• deliberately corrupted official UBL invoice: REJECTED
• unsupported Factur-X attachment relationships: REJECTED

The unit suite also verifies root syntax routing, exact specification identifiers, unsupported-profile rejection, source safety, independent batch errors, bounded findings, non-root runtime, and pay-per-event guards.

Official example files are downloaded only for release testing and are not included in the production image.

Current scope

This Actor does not:

• transmit an invoice through an approved platform
• call the French public invoicing portal or prove platform acceptance
• verify tax treatment, legal validity, fraud, duplicates, or payment approval
• verify digital signatures or issuer identity
• prove that visible PDF text equals embedded XML values
• validate invoice lifecycle CDAR messages
• accept Factur-X MINIMUM, BASIC WL, or BASIC as France reform invoice profiles

Official references

• FNFE-MPE France_RFE rules
• France_RFE v1.4.0.02 release
• French external B2B specifications
• Factur-X 1.09
• veraPDF validation documentation
• THIRD_PARTY_NOTICES.md

This Actor is also exposed to AI agents through Apify's MCP server (mcp.apify.com): an agent can discover it by search and run it with the same pay-per-event billing, with no separate integration.

E-invoice validator family

Same engine, same output contract, one validator per market: XRechnung & ZUGFeRD (Germany) | Peppol BIS Billing | Poland KSeF FA(3) | Italy FatturaPA