Factur-X — Spécifications FNFE-MPE 1.0.07

Factur-X est le format pivot franco-allemand de facture hybride PDF/A-3 + XML CII : un fichier unique exploitable à la fois par un humain et par une chaîne EDI. La spécification est co-gouvernée par le FNFE-MPE en France et par le FeRD en Allemagne (côté ZUGFeRD), conforme EN 16931.

Histoire et gouvernance

Factur-X est né en 2017 d'un travail conjoint FNFE-MPE / FeRD visant à réconcilier le format allemand ZUGFeRD (Zentraler User Guide Elektronische Rechnung Deutschland) et les besoins français : un document unique humainement lisible et machine-exploitable, sans rupture par rapport aux processus PDF existants. ZUGFeRD 2.0 et Factur-X 1.0 sont publiés conjointement en mars 2018, partageant le même profil EN 16931 dès l'origine.

Les versions successives suivent la convergence européenne :

• 1.0 (mars 2018) — alignement initial sur le brouillon EN 16931, 5 profils définis.
• 1.0.05 (avril 2020) — corrections de codelists UNCL et alignement sur EN 16931:2017+A1:2019.
• 1.0.06 (juin 2022) — ajout du profil BASIC WL (Without Lines, version sans lignes de facture) requis pour les usages comptables minimaux.
• 1.0.07 (2024) — convergence avec ZUGFeRD 2.3, alignement BR-* sur EN 16931:2017+A2:2024 (rétro-erratum sur calcul TVA cas franco-français), publication co-signée des Schematron officiels.

Les cinq profils Factur-X

Les profils sont strictement ascendants : tout ce qu'accepte un profil inférieur est valide dans un profil supérieur. Cette monotonie permet à un récepteur d'annoncer le profil minimum qu'il sait traiter et de toujours pouvoir lire des factures de profil plus riche.

• MINIMUM — jeu réduit aux champs comptables stricts (BT-1 numéro de facture, BT-2 date d'émission, BT-3 type, BT-5 devise, BT-27/BT-44 noms vendeur/acheteur, totaux BT-109/BT-110/BT-112). Cible : pré-comptabilisation automatisée d'une PDF, sans détail ligne. Hors EN 16931.
• BASIC WL (Without Lines, ajouté 1.0.06) — identique à BASIC mais sans lignes de facture. Cible : transmission comptable d'un PDF de facture où seuls les totaux et la TVA détaillée par taux sont structurés. Hors EN 16931.
• BASIC — sous-ensemble strict d'EN 16931 limité aux cas les plus simples (1 vendeur, 1 acheteur, ventilation TVA simplifiée, lignes de facture minimales). Conforme EN 16931.
• EN 16931 — couverture complète de la norme européenne EN 16931:2017+A2:2024, soit ~150 BT structurés répartis sur ~30 BG. Profil par défaut pour la conformité française PPF et pour tout échange transfrontalier européen.
• EXTENDED — EN 16931 + extensions sectorielles autorisées par les annexes nationales : champs CHORUS Pro (engagement juridique, code service), références sectorielles (BAS Bâtiment, GS1 retail), informations logistiques avancées. Conforme EN 16931 (les extensions restent dans des espaces de noms RAM dédiés, non bloquantes).

Structure PDF/A-3 et XML embarqué

Une facture Factur-X est un PDF/A-3b conforme ISO 19005-3:2012 contenant exactement un XML CII attaché via le mécanisme standard EmbeddedFile du PDF.

Trois ancrages techniques garantissent l'interopérabilité :

1. AFRelationship du fichier attaché DOIT valoir Alternative (le XML est une représentation alternative du PDF) ou Data. Sans cette propriété, des lecteurs stricts (Adobe Reader DC en mode validation) refusent l'attachement.
2. Nom du fichier embarqué normé : factur-x.xml (en minuscules, avec trait d'union — la variante FACTUR-X.XML provoque des rejets côté PDP).
3. Métadonnées XMP du PDF avec l'extension Factur-X déclarée par l'URN urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# indiquant le profil exact (clé fx:ConformanceLevel).

Extrait du XMP du PDF/A-3 d'une Factur-X profil BASIC WL :

<?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"?>

Et un exemple minimal du XML CII embarqué pour le même profil, déclarant son URN de guideline et portant le bloc MonetarySummation requis :

<?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>

Champs obligatoires par profil

Le tableau ci-dessous récapitule les champs sémantiques EN 16931 (BT-*) et les groupes (BG-*) obligatoires par profil. Les champs optionnels conditionnels (par exemple BT-7 date de valeur TVA si différente de la date d'émission) ne sont pas listés.

Validation Schematron et CIUS France

La validation Factur-X repose sur trois couches successives, chacune bloquante :

1. XSD CII D16B — validation structurelle de l'arbre XML. Tout PDP refusera un fichier non conforme XSD.
2. Schematron EN 16931 BR-* / BR-CO-* — règles métier européennes (par exemple BR-CO-15 : somme des sous-totaux doit égaler le total HT à 2 décimales près).
3. Schematron CIUS France BR-FR-* — surcouche française imposant les 24 mentions complémentaires du Code général des impôts (article 242 nonies A annexe II) et du Code de commerce (articles L441-9 et suivants sur les conditions de règlement).

Exemple de règles BR-FR-* publiées par le FNFE-MPE :

<!-- Extrait Schematron FNFE-MPE / CIUS FR : SIREN obligatoire vendeur -->
<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] Le SellerTradeParty doit porter un identifiant SIREN (9 chiffres)
      ou SIRET (14 chiffres) avec 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] Conditions de reglement requises (art. L441-9 Code de commerce).
    </assert>
  </rule>
</pattern>

Cas spéciaux : avoir, acompte, rectificative

Trois cas métier appellent un traitement particulier du code BT-3 (type de document) et de la référence BT-25 (document de référence) :

• Avoir (note de crédit) — BT-3 = 381 (Credit note). Les montants restent positifs mais sont compris comme à déduire. La référence à la facture annulée est portée dans le BG-3 Preceding Invoice Reference (BT-25 numéro, BT-26 date).
• Facture d'acompte — BT-3 = 386 (Prepayment invoice). Une facture d'acompte est suivie d'une facture définitive qui doit imputer l'acompte via le bloc Invoice line à montant négatif et BT-152 référence à l'acompte. Le profil MINIMUM ne couvre pas l'imputation et requiert au minimum BASIC.
• Facture rectificative — BT-3 = 384 (Corrected invoice). Annule et remplace la facture précédente. Obligatoire en cas d'erreur fiscale (TVA, montant HT). La référence à la facture initiale est portée dans BG-3, le motif dans BT-22 Note est fortement recommandé pour la traçabilité fiscale.

Outillage et liens

• /tools/facturx-extractor/ — extraction du XML CII embarqué d'un PDF/A-3 et détection du profil.
• /tools/en16931-validator/ — validation des règles BR-* et BR-CO-* de la norme européenne.
• /tools/ubl-validator/ — validateur UBL 2.1 complémentaire (syntaxe alternative acceptée par la PPF).
• Standards — Factur-X / ZUGFeRD — page de référence du format.
• Pays — France (vue d'ensemble) — calendrier mandat 2026/2027 et architecture PPF/PDP.
• France — Modèle CTC 5-corner — comparaison avec PEPPOL 4-corner.
• France — Annuaire central PPF — résolution destinataire et API.
• France — Chorus Pro — plateforme B2G historique et bascule PPF.
• 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 et 242 nonies A annexe II.