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’archive ci-dessous décrit un exemple du 18 mai 2026 avec le pack FNFE-MPE v1.3.1 ; elle ne décrit pas le contrat actuel.
• 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é.

Archive du 18 mai 2026 : exemple avec le pack France CTC v1.3.1

Cet exemple historique vient d’un XML CII synthétique : tests/fixtures/valid_invoice_en16931.xml. Il ne contient pas de données client réelles. Le compte rendu de mai indiquait un passage du socle EN16931 et six avertissements France CTC, alors présentés comme bloquants par l’API.

Archive, pas contrat actuel : le JSON est conservé tel que publié pour documenter cette ancienne interprétation. Ses statuts invalid / blocked et son compteur de cinq compléments obligatoires ne doivent pas être repris pour implémenter un client aujourd’hui. Aucun nouveau test de cette fixture n’est revendiqué ici. L’entrée étant un XML CII seul, cet exemple ne couvre pas le PDF/A-3 ni le conteneur Factur-X PDF.

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 historique simplifiée du 18 mai 2026, avec validation_profile=auto et jurisdiction=FR ; ancienne interprétation produit, non représentative du contrat actuel :

{
  "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."
    }
  ]
}

Lire les avertissements avec le contrat actuel

La sévérité vient du pack et du variant réellement exécutés. Dans un rollback explicite vers le pack 1.3.1, les règles ici émises en warning sont des avertissements consultatifs : elles ne deviennent pas automatiquement des erreurs fatales ni cinq compléments obligatoires. Des avertissements seuls ne prouvent toutefois pas un passage France CTC sans réserve.

Distinguez le verdict de la cible (target), les contrôles exécutés, la sévérité de chaque règle, blocksTransmission et blocksGeneration. Un écart bloquant pour la transmission du document soumis peut laisser possible la génération d’un candidat corrigé. Cette possibilité dépend des données disponibles et des signaux explicites du diagnostic ; elle ne se déduit ni du seul warning ni de l’absence d’une valeur.

Lisez ces champs dans le rapport de votre document. Au 20 septembre 2026, les métadonnées de l’API déclarent le pack France CTC 1.4.0.02 chargé. Cela n’est ni une revalidation de l’archive ni une preuve d’acceptation par une PA.

L’exemple illustre donc la différence de périmètre : le socle européen peut passer alors que des contrôles français signalent des écarts supplémentaires. Pour décider sur une facture actuelle, utilisez son propre rapport avec ses artefacts et ses sévérités, sans transposer les statuts de cette archive.

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é. Un contrôle unknown ou not_evaluated reste non évalué ; il ne devient jamais passed.

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
  -> Logiciel de transmission de l'architecture client, si applicable
  -> 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