Vous avez généré une facture Factur-X, votre XML passe la validation XSD sans erreur, et pourtant votre partenaire EDI ou votre opérateur de dématérialisation vous retourne un rejet. La raison est presque toujours la même : le fichier respecte la structure attendue, mais viole une règle métier que seul Schematron peut détecter. Cet article explique pourquoi, et comment fonctionne concrètement ce deuxième niveau de validation.

Pourquoi le XSD ne suffit pas

Un schéma XSD (XML Schema Definition) est un contrat sur la forme du document :

  • quelles balises sont autorisées, dans quel ordre, avec quelle cardinalité ;
  • quels types de données (date, montant, code ISO…) sont attendus ;
  • quels éléments sont obligatoires ou optionnels.

C'est nécessaire, mais largement insuffisant pour une facture électronique. Les règles comptables et fiscales de la norme EN 16931 imposent des contraintes que XSD ne peut pas exprimer nativement :

Ce que XSD vérifie Ce que XSD ne peut pas vérifier
<ram:TaxTotalAmount> est bien un décimal TaxTotalAmount = somme de tous les TaxAmount
<ram:ExemptionReasonCode> est présent Ce code est obligatoire si et seulement si le taux de TVA est 0 %
La date a le format YYYYMMDD La date d'échéance est postérieure ou égale à la date de facture
Un <ram:LineID> existe par ligne Tous les LineID sont uniques au sein de la facture

Ces règles inter-champs, conditionnelles et arithmétiques sont précisément le domaine de Schematron.

Qu'est-ce que Schematron

Schematron est une norme ISO/IEC 19757-3 (publiée initialement en 2003, révisée en 2016). Contrairement à XSD ou RelaxNG, Schematron ne décrit pas une grammaire : il exprime des assertions logiques portant sur un document XML, rédigées en XPath.

Son modèle est minimaliste :

  • un ensemble de <pattern> regroupe des règles thématiques ;
  • chaque <rule context="..."> sélectionne des nœuds via un XPath (ex. chaque ligne de facture) ;
  • à l'intérieur d'une règle, des <assert test="..."> définissent des conditions qui doivent être vraies — l'assertion échoue si le test est faux ;
  • des <report test="..."> inversent la logique : ils signalent quand une condition est vraie (utile pour les avertissements).

Structure d'un fichier Schematron

<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron"
            queryBinding="xslt2">

  <sch:ns prefix="rsm" uri="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"/>
  <sch:ns prefix="ram" uri="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"/>
  <sch:ns prefix="udt" uri="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"/>

  <sch:pattern id="EN16931-amounts">

    <!-- Règle appliquée à chaque ligne de facture -->
    <sch:rule context="//ram:IncludedSupplyChainTradeLineItem">

      <!-- Le montant net de ligne doit être égal à quantité × prix unitaire net -->
      <sch:assert test="
        ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount
        = round(
            ram:SpecifiedLineTradeDelivery/ram:BilledQuantity
            * ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:ChargeAmount
          * 100) div 100"
        id="BR-CO-LINE-01"
        flag="fatal">
        Le montant net de la ligne doit être égal à la quantité facturée multipliée par le prix net unitaire.
      </sch:assert>

    </sch:rule>

  </sch:pattern>

  <sch:pattern id="EN16931-tax-exemption">

    <!-- Règle appliquée à chaque sous-total de taxe -->
    <sch:rule context="//ram:ApplicableTradeTax">

      <!-- Si le taux de TVA est nul (exonération), un motif doit être renseigné -->
      <sch:assert test="
        not(ram:RateApplicablePercent = 0)
        or (ram:ExemptionReasonCode or normalize-space(ram:ExemptionReason) != '')"
        id="BR-E-10"
        flag="fatal">
        Lorsque le taux de TVA est 0 %, un code ou un libellé de motif d'exonération est obligatoire.
      </sch:assert>

    </sch:rule>

  </sch:pattern>

</sch:schema>

Note : les identifiants BR-CO-LINE-01 et BR-E-10 sont illustratifs. Les identifiants officiels sont définis dans les artefacts publiés par la Commission européenne (CEF) et le FNFE-MPE — voir la section « Pour aller plus loin ».

Les phases (<phase>)

Schematron permet de regrouper des patterns en phases. Pour EN 16931, on distingue généralement :

  • une phase syntax : vérifications structurelles légères non couvertes par XSD ;
  • une phase codelists : conformité des codes (unités UNECE, codes pays ISO 3166…) ;
  • une phase en16931 : règles métier BR-xx proprement dites.

Un validateur peut n'activer que certaines phases selon le contexte (ex. validation partielle pour un diagnostic rapide).

Le pipeline d'exécution : Schematron → XSLT

Les moteurs Schematron ne s'exécutent généralement pas directement. Le flux standard est le suivant :

Fichier .sch
     │
     ▼  (compilation via iso_schematron_skeleton ou xslt2)
Feuille XSLT générée (.xsl)
     │
     ▼  (application sur le document XML cible)
SVRL — Schematron Validation Report Language (XML)
     │
     ▼  (parsing du rapport)
Liste d'erreurs / avertissements

Le SVRL (lui aussi normalisé dans ISO/IEC 19757-3) est le format de sortie : chaque <svrl:failed-assert> contient l'identifiant de la règle, la localisation XPath du nœud fautif, et le message humain. C'est ce rapport qu'un validateur comme celui de SynapxLab ou du FNFE-MPE vous présente.

La chaîne de validation complète d'une Factur-X

Une Factur-X est un PDF/A-3 embarquant un fichier XML CII (Cross Industry Invoice). La validation se déroule en trois couches indépendantes et séquentielles :

┌─────────────────────────────────────────────────────────┐
│  1. Vérification de l'enveloppe PDF                     │
│     • Conformité PDF/A-3 (profil icc, métadonnées XMP)  │
│     • Présence de la pièce jointe XML (nom normalisé)   │
│     • Métadonnées XMP Factur-X (profil, version)        │
├─────────────────────────────────────────────────────────┤
│  2. Validation XSD                                      │
│     • Schéma CII D16B (UN/CEFACT)                       │
│     • Vérifie : balises, types, cardinalité             │
│     • Un fichier peut passer XSD et échouer à l'étape 3 │
├─────────────────────────────────────────────────────────┤
│  3. Validation Schematron EN 16931                      │
│     • Artefacts officiels CEF / FNFE-MPE                │
│     • Règles BR-xx (obligatoires), BR-CO-xx             │
│       (cohérence de calcul), BR-E-xx (TVA 0 %), etc.   │
│     • C'est ici que la majorité des rejets se produisent│
└─────────────────────────────────────────────────────────┘

Un fichier peut passer XSD et échouer au Schematron. C'est le cas le plus fréquent en production : la structure est correcte, mais un montant ne se recoupe pas, un code TVA est absent, ou une date d'échéance est antérieure à la date d'émission.

🔎 Le testeur Factur-X de SynapxLab applique les trois couches de validation. Déposez votre fichier sur /sdk/FactureX/ — aucune donnée conservée.

Les artefacts officiels EN 16931

La Commission européenne (programme CEF — Connecting Europe Facility) publie et maintient les fichiers Schematron de référence pour EN 16931 sur le dépôt GitHub ConnectingEurope/eInvoicing-EN16931. En France, le FNFE-MPE (Forum National de la Facture Électronique) distribue des versions adaptées et maintient un service de validation en ligne.

Ces artefacts couvrent plusieurs syntaxes : UBL 2.1 (Invoice + CreditNote) et CII D16B (utilisé par Factur-X). Ils sont versionnés et mis à jour à chaque évolution de la norme.

Outils pour valider vos factures

Outil Ce qu'il valide Accès
Testeur Factur-X SynapxLab PDF/A-3 + XSD + Schematron EN 16931 /sdk/FactureX/
Validateur FNFE-MPE XSD + Schematron EN 16931 (UBL & CII) services.fnfe-mpe.org
Artefacts CEF GitHub Source Schematron brute ConnectingEurope/eInvoicing-EN16931

FAQ

Dois-je implémenter Schematron moi-même dans mon application ? Non, en général. Des bibliothèques existent pour Java (Saxon + Schematron Skeleton), Python (lxml + compilation XSLT), PHP et Node.js. Mais le plus simple reste d'utiliser un validateur qui embarque déjà les artefacts CEF à jour et les met à jour à chaque révision de la norme.

Quelle est la différence entre une erreur fatal et un warning dans les résultats ? Dans les artefacts EN 16931, les assertions estampillées flag="fatal" correspondent aux règles BR-xx obligatoires : leur violation rend la facture non conforme et elle sera rejetée. Les flags warning signalent des anomalies tolérées mais à corriger pour une interopérabilité optimale.

Schematron s'applique-t-il aussi à la e-facture française (PPF/PA) ? Oui. Le socle technique s'appuie sur EN 16931 ; les mêmes règles Schematron s'appliquent, avec potentiellement des extensions spécifiques au contexte français publiées par la DGFiP.

Mon XML est valide XSD mais rejeté par une plateforme. Que faire ? Lancez systématiquement la validation Schematron avant envoi. Consultez l'article Pourquoi ma facture Factur-X est-elle invalide ? pour un guide de diagnostic.

Pour aller plus loin