EN16931 validé, France CTC à corriger : validation Factur-X et BR-FR

Quand un ERP voit “EN16931 validé” puis “France CTC à corriger”, la bonne question n’est pas “quel validateur a raison ?”. La bonne question est : quelle couche a été exécutée, avec quels artefacts, et quelle action faut-il déclencher avant la transmission officielle ?

Un validateur EN16931 générique répond à une question précise : le document respecte-t-il le socle européen attendu pour une facture électronique ? Un contrôle France CTC pose une autre question : le même document respecte-t-il aussi le contexte d’application français et les artefacts France publiés pour ce contexte ?

Ces deux questions se ressemblent, mais elles ne sont pas équivalentes. Un fichier peut passer le socle EN16931 et rester insuffisant pour un contrôle France CTC. Ce n’est pas une contradiction : ce sont deux couches de validation différentes.

En bref

• EN16931 est le socle sémantique européen : informations obligatoires, structure des données, calculs et valeurs codées.
• Les artefacts EN16931 publiés côté européen servent à tester le message facture, pas toute la chaîne de traitement.
• France CTC ajoute des artefacts d’application français, notamment BR-FR-CTC et EXTENDED-CTC-FR. L’exemple reproductible ci-dessous a été revérifié le 18 mai 2026 avec le pack FNFE-MPE v1.3.1.
• Un rapport fiable doit dire quels profils ont été appliqués, lesquels ont été ignorés, et quels artefacts ont produit les erreurs.
• Cette validation reste documentaire. La transmission officielle de la facture reste dans le périmètre de la Plateforme Agréée choisie dans l’architecture cible.

Ce que couvre EN16931 base

EN16931 définit le modèle sémantique européen de facture électronique. La page officielle de la Commission européenne sur la conformité EN16931 décrit le niveau document : une facture doit contenir les informations obligatoires, les structurer correctement, calculer les montants comme attendu et n’utiliser que des valeurs autorisées, par exemple des codes.

Dans une implémentation technique, ce socle se traduit généralement par plusieurs contrôles :

La Commission européenne rappelle aussi que les artefacts de validation expriment techniquement les contrôles du standard, notamment via Schematron. Ces artefacts testent le message facture. Ils ne prouvent pas à eux seuls le traitement complet d’un flux dans un écosystème national.

Pour le détail XSD vs Schematron, voir Valider EN16931 / Factur-X en pratique.

Ce que France CTC ajoute

Le contexte français ne s’arrête pas au socle EN16931 générique. La page impots.gouv.fr sur les spécifications externes et normes pour la facturation électronique pointe vers le socle AFNOR XP Z12-012, XP Z12-013 et XP Z12-014 pour les formats, profils, API d’interfaçage et cas d’usage B2B.

Côté artefacts, la page Ressources FNFE-MPE centralise les ressources France CTC. Dans l’inventaire utilisé pour cet exemple de test, le pack France CTC v1.3.1 contient notamment :

La différence commerciale et technique est là : un validateur qui exécute seulement EN16931 peut manquer une erreur qui n’existe que dans le profil France CTC appliqué.

Exemple reproductible : EN16931 validé, France CTC échoué

Cet exemple vient d’un XML CII synthétique utilisé dans les tests de non-régression : tests/fixtures/valid_invoice_en16931.xml. Il ne contient pas de données client réelles. Le même fichier passe le validateur EN16931 complet, puis échoue sur le profil France CTC lorsque les artefacts FNFE-MPE France CTC v1.3.1 sont exécutés. Dans le scanner, ce cas est restitué comme un XML CII fourni, EN16931 CEN/CII base validé, et France CTC / France 2026 à corriger avant transformation ou remise au flux officiel. Cet exemple ne couvre pas les contrôles PDF/A-3 ou conteneur Factur-X PDF, car l’entrée testée est un XML CII standalone.

Extrait minimal :

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

<rsm:ExchangedDocument>
  <ram:ID>INV-001</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20251020</udt:DateTimeString>
  </ram:IssueDateTime>
  <!-- Pas de notes BG-1 avec les sujets PMT, PMD ou AAB dans cet exemple. -->
</rsm:ExchangedDocument>

<ram:ApplicableHeaderTradeAgreement>
  <ram:SellerTradeParty>
    <ram:ID>SELLER123</ram:ID>
    <ram:Name>Test Seller Inc.</ram:Name>
    <ram:PostalTradeAddress>
      <ram:CountryID>FR</ram:CountryID>
    </ram:PostalTradeAddress>
    <ram:SpecifiedTaxRegistration>
      <ram:ID schemeID="VA">FR12345678901</ram:ID>
    </ram:SpecifiedTaxRegistration>
  </ram:SellerTradeParty>
  <ram:BuyerTradeParty>
    <ram:Name>Test Buyer Corp.</ram:Name>
    <ram:PostalTradeAddress>
      <ram:CountryID>FR</ram:CountryID>
    </ram:PostalTradeAddress>
  </ram:BuyerTradeParty>
</ram:ApplicableHeaderTradeAgreement>

Réponse API simplifiée issue d’un dry-run de validation documentaire sur XML CII, avec validation_profile=auto et jurisdiction=FR :

{
  "testFile": "tests/fixtures/valid_invoice_en16931.xml",
  "testFileSha256": "a3241155dd0039bc90c0ebc5d174300c921fc9cb57f40f2448e381d26488ac01",
  "request": {
    "input": "CII XML",
    "validation_profile": "auto",
    "jurisdiction": "FR",
    "dry_run": true
  },
  "validationStatus": "invalid",
  "validationReadiness": {
    "en16931": {
      "status": "passed",
      "blockers": []
    },
    "frCtc": {
      "status": "blocked",
      "blockerCount": 6,
      "blockers": [
        "BR-FR-05_BT-22_PMT",
        "BR-FR-05_BT-22_PMD",
        "BR-FR-05_BT-22_AAB",
        "BR-FR-10_BT-30",
        "BR-FR-12_BT-49",
        "BR-FR-13_BT-34"
      ]
    },
    "paAcceptance": {
      "status": "not_submitted"
    }
  },
  "appliedValidationProfiles": [
    "facturx_en16931_base",
    "fr_ctc"
  ],
  "skippedValidationProfiles": [],
  "unsupportedValidationProfiles": [],
  "validationArtifacts": [
    {
      "id": "facturx-1.08-en16931-cii",
      "profile": "facturx_en16931_base",
      "version": "1.08",
      "status": "available"
    },
    {
      "id": "fnfe-fr-ctc-flux2-cii-xsl-1.3.1",
      "profile": "fr_ctc",
      "version": "1.3.1",
      "sha256": "ad68ea19171e5b6a166ffcb433b49441ed3e075ee9051cacf0abccc108a9ad9d",
      "status": "available"
    }
  ],
  "issueCountsByProfile": {
    "fr_ctc": 6
  },
  "actionSummary": {
    "erpMustComplete": 5,
    "automaticConvertFixes": 1
  },
  "franceCtcIssues": [
    {
      "ruleId": "BR-FR-05_BT-22_PMT",
      "severity": "warning",
      "summary": "Mention PMT absente dans les notes BG-1."
    },
    {
      "ruleId": "BR-FR-05_BT-22_PMD",
      "severity": "warning",
      "summary": "Mention PMD absente dans les notes BG-1."
    },
    {
      "ruleId": "BR-FR-05_BT-22_AAB",
      "severity": "warning",
      "summary": "Mention AAB absente dans les notes BG-1."
    },
    {
      "ruleId": "BR-FR-10_BT-30",
      "severity": "warning",
      "scanAction": "automatic_convert_fix",
      "summary": "Un SIREN vendeur est détecté, mais BT-30 reste à corriger dans le XML source."
    },
    {
      "ruleId": "BR-FR-12_BT-49",
      "severity": "warning",
      "summary": "BT-49 attendu par le contrôle France CTC."
    },
    {
      "ruleId": "BR-FR-13_BT-34",
      "severity": "warning",
      "summary": "BT-34 attendu par le contrôle France CTC."
    }
  ]
}

Point important : les six issues France CTC remontent avec une sévérité technique warning côté validation, car ce flag vient des assertions FNFE-MPE exécutées. Dans le contrat FacturX API, la sévérité d’une ligne, le verdict du profil et l’action produit ne sont pas la même information : dès qu’un profil France CTC appliqué produit des failed-asserts, le verdict documentaire du profil est invalid / “échoué”. Dans le scan produit actuel, ce même résultat devient des actions concrètes : cinq compléments métier à fournir et une correction déterministe proposée pour BT-30. Ce statut ne vaut pas erreur fiscale finale ni verdict de Plateforme Agréée ; il dit seulement que le profil France CTC demandé n’a pas passé ce test documentaire.

Ce que ce contrôle prouve :

• le document peut passer une validation EN16931 de base ;
• le même document peut échouer sur des failed-asserts France CTC additionnels, même lorsque leur sévérité de ligne est warning ;
• un validateur générique EN16931 ne suffit donc pas à expliquer tous les écarts attendus sur un flux France.

Ce que ce contrôle ne prouve pas : une transmission officielle, un verdict fiscal final, ou la prise en charge par une Plateforme Agréée. Il prouve seulement que les deux couches documentaires listées ont été exécutées sur cet exemple synthétique.

Comment lire un rapport multi-profils

Le rapport doit séparer trois informations :

Cette séparation évite le piège classique : afficher “valide” parce que le socle EN16931 passe, alors que France CTC n’a pas été exécuté.

Comment décider ensuite

Le point important n’est pas seulement “valide” ou “invalide”. Le point important est la conséquence produit :

Ce que ce contrôle prouve

Un contrôle EN16931 + France CTC correctement tracé prouve :

• que le document a été parsé dans la syntaxe annoncée ;
• que le socle EN16931 a été exécuté ;
• que les artefacts France CTC listés dans le rapport ont été exécutés, si le profil est dans appliedValidationProfiles ;
• que les erreurs remontées sont rattachées à une couche et à une version d’artefact ;
• que le résultat est reproductible dans un exemple de test, si le rapport est intégré aux tests de non-régression.

Ce que ce contrôle ne prouve pas

Le même contrôle ne prouve pas :

• une transmission officielle de la facture ;
• une réception par le client ;
• une extraction ou transmission des données à l’administration ;
• un statut de cycle de vie CDAR ;
• un verdict final du flux officiel ;
• une validation fiscale globale de l’opération.

La page officielle impots.gouv.fr sur les Plateformes Agréées décrit le rôle des PA dans l’émission, la transmission, la réception et la transmission de données à l’administration. FacturX API intervient en amont, sur la qualité technique du document.

Où placer FacturX API dans une architecture ERP

Pour un éditeur ERP vertical ou un logiciel métier cloud-native, le bon usage est un preflight documentaire :

ERP / logiciel métier
  -> FacturX API : scan, conversion, réparation, validation documentaire
  -> Solution Compatible de l'architecture client, si elle existe
  -> Plateforme Agréée choisie pour la transmission officielle
  -> Portail public / administration selon le circuit applicable

FacturX API ne devient pas la Plateforme Agréée. Il aide l’ERP à produire un document mieux contrôlé avant remise au maillon chargé de la transmission officielle.

Pour l’architecture complète, lire Preflight Factur-X en amont d’une Plateforme Agréée.

Quelle action choisir ?

Articles liés

• Valider EN16931 / Factur-X en pratique
• Profils Factur-X : MINIMUM -> EXTENDED
• Moteur de réparation EN16931 vs validateur Factur-X
• Lire un rapport de scan Factur-X