Factur-X — FNFE-MPE 1.0.07 specification

Factur-X is the Franco-German hybrid invoice format: a single PDF/A-3 file with an embedded CII XML, readable both by humans and by EDI pipelines. The specification is co-governed by FNFE-MPE in France and FeRD in Germany (on the ZUGFeRD side), EN 16931 conformant.

History and governance

Factur-X originated in 2017 from a joint FNFE-MPE / FeRD effort aimed at reconciling the German ZUGFeRD format (Zentraler User Guide Elektronische Rechnung Deutschland) with French requirements: a single document that is both human-readable and machine-processable, without disrupting existing PDF workflows. ZUGFeRD 2.0 and Factur-X 1.0 were jointly released in March 2018, sharing the same EN 16931 profile from day one.

Successive versions track European convergence:

• 1.0 (March 2018) — initial alignment with EN 16931 draft, 5 profiles defined.
• 1.0.05 (April 2020) — UNCL codelist fixes and alignment with EN 16931:2017+A1:2019.
• 1.0.06 (June 2022) — addition of the BASIC WL profile (Without Lines) for minimal accounting use cases.
• 1.0.07 (2024) — convergence with ZUGFeRD 2.3, BR-* alignment with EN 16931:2017+A2:2024 (retro-erratum on a French-domestic VAT calculation case), co-published official Schematrons.

The five Factur-X profiles

Profiles are strictly ascending: anything a lower profile accepts is valid in a higher profile. This monotonicity lets a receiver announce the minimum profile it can process while still being able to read invoices of richer profiles.

• MINIMUM — reduced set limited to strict accounting fields (BT-1 invoice number, BT-2 issue date, BT-3 type, BT-5 currency, BT-27/BT-44 seller/buyer names, BT-109/BT-110/BT-112 totals). Target: automated pre-bookkeeping of a PDF, no line-level detail. Outside EN 16931.
• BASIC WL (Without Lines, added in 1.0.06) — identical to BASIC but without invoice lines. Target: accounting transmission of a PDF invoice where only totals and VAT breakdown by rate are structured. Outside EN 16931.
• BASIC — strict EN 16931 subset restricted to the simplest cases (1 seller, 1 buyer, simplified VAT breakdown, minimal invoice lines). EN 16931 conformant.
• EN 16931 — full coverage of the European norm EN 16931:2017+A2:2024, i.e. ~150 structured BTs across ~30 BGs. Default profile for French PPF conformance and any European cross-border exchange.
• EXTENDED — EN 16931 + sectoral extensions authorised by national annexes: Chorus Pro fields (legal engagement, service code), sectoral references (BAS construction, GS1 retail), advanced logistics info. EN 16931 conformant (extensions live in dedicated RAM namespaces, non-blocking).

PDF/A-3 structure and embedded XML

A Factur-X invoice is a PDF/A-3b conforming to ISO 19005-3:2012, containing exactly one CII XML attached via the standard PDF EmbeddedFile mechanism.

Three technical anchors guarantee interoperability:

1. AFRelationship of the attached file MUST be Alternative (the XML is an alternative representation of the PDF) or Data. Without it, strict readers (Adobe Reader DC in validation mode) reject the attachment.
2. Embedded filename is normalised: factur-x.xml (lowercase with a hyphen — the variant FACTUR-X.XML causes rejection at the PDP side).
3. PDF XMP metadata with the Factur-X extension declared by URN urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# stating the exact profile (fx:ConformanceLevel key).

Extract from the XMP of a Factur-X BASIC WL profile PDF/A-3:

<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
        xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/"
        xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#">
      <pdfaid:part>3</pdfaid:part>
      <pdfaid:conformance>B</pdfaid:conformance>
      <fx:DocumentType>INVOICE</fx:DocumentType>
      <fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
      <fx:Version>1.0</fx:Version>
      <fx:ConformanceLevel>BASIC WL</fx:ConformanceLevel>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>

And a minimal CII XML embedded in the same profile, declaring its guideline URN and carrying the required MonetarySummation block:

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"
    xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:factur-x.eu:1p0:basicwl</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>FX-2026-00742</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20260915</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>Atelier Numerique SAS</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">80214579500024</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Cooperative Aquitaine</ram:Name>
        <ram:SpecifiedLegalOrganization>
          <ram:ID schemeID="0002">52145201400018</ram:ID>
        </ram:SpecifiedLegalOrganization>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1200.00</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Mandatory fields per profile

The table below summarises the EN 16931 semantic fields (BT-*) and groups (BG-*) that are mandatory per profile. Optional conditional fields (e.g. BT-7 VAT value date if different from issue date) are not listed.

Schematron validation and France CIUS

Factur-X validation relies on three successive blocking layers:

1. XSD CII D16B — structural validation of the XML tree. Any PDP will reject a non-XSD-conformant file.
2. EN 16931 Schematron BR-* / BR-CO-* — European business rules (e.g. BR-CO-15: the sum of line subtotals must equal the document net total within 2 decimals).
3. CIUS France Schematron BR-FR-* — French overlay enforcing the 24 additional mandatory mentions of the French Tax Code (CGI article 242 nonies A annex II) and the French Commercial Code (articles L441-9 et seq. on payment terms).

Example BR-FR-* rules published by FNFE-MPE:

<!-- Extract from FNFE-MPE CIUS FR Schematron: mandatory seller SIREN -->
<pattern id="BR-FR-01">
  <rule context="//ram:SellerTradeParty/ram:SpecifiedLegalOrganization">
    <assert test="ram:ID[@schemeID='0002'] and string-length(ram:ID) = 14 or string-length(ram:ID) = 9"
            flag="fatal">
      [BR-FR-01] SellerTradeParty must carry a SIREN (9 digits) or SIRET
      (14 digits) identifier with schemeID '0002'.
    </assert>
  </rule>
</pattern>

<pattern id="BR-FR-04">
  <rule context="//ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms">
    <assert test="ram:Description or ram:DueDateDateTime" flag="warning">
      [BR-FR-04] Payment terms required (Code de commerce art. L441-9).
    </assert>
  </rule>
</pattern>

Special cases: credit note, prepayment, corrected invoice

Three business cases require special handling of the BT-3 (document type) code and the BT-25 (referenced document) field:

• Credit note — BT-3 = 381 (Credit note). Amounts remain positive but are understood as deductions. The reference to the cancelled invoice is carried in BG-3 Preceding Invoice Reference (BT-25 number, BT-26 date).
• Prepayment invoice — BT-3 = 386 (Prepayment invoice). A prepayment invoice is followed by a final invoice that must impute the prepayment via an Invoice line with a negative amount and a BT-152 reference to the prepayment. The MINIMUM profile does not cover imputation and requires at least BASIC.
• Corrected invoice — BT-3 = 384 (Corrected invoice). Cancels and replaces the preceding invoice. Mandatory in case of a tax error (VAT, net amount). The reference to the initial invoice is in BG-3, the reason in BT-22 Note is strongly recommended for tax traceability.

Tooling and links

• /en/tools/facturx-extractor/ — extract the embedded CII XML from a PDF/A-3 and detect the profile.
• /en/tools/en16931-validator/ — validate the EN 16931 BR-* and BR-CO-* rules.
• /en/tools/ubl-validator/ — complementary UBL 2.1 validator (alternative syntax accepted by PPF).
• Standards — Factur-X / ZUGFeRD — reference page for the format.
• Countries — France (overview) — 2026/2027 mandate timeline and PPF/PDP architecture.
• France — CTC 5-corner model — comparison with PEPPOL 4-corner.
• France — Central directory (PPF) — recipient resolution and API.
• France — Chorus Pro — historical B2G platform and PPF transition.
• Sources: FNFE-MPE Factur-X 1.0.07, FeRD ZUGFeRD 2.3, ISO 19005-3:2012 PDF/A-3, CEN EN 16931 family, CGI art. 289 and 242 nonies A annex II.