« Ma facture est conforme EN 16931. » Cette phrase peut vouloir dire cinq choses différentes — et une facture peut réussir quatre de ces contrôles tout en étant rejetée par la plateforme au cinquième. C'est la première chose que nous expliquons aux éditeurs qui nous intègrent, alors autant l'écrire.
Une norme, plusieurs artefacts
La norme EN 16931 définit un modèle sémantique : environ 160 termes
métier (BT-1, le numéro de facture ; BT-27, le nom du vendeur…) et des
règles métier (BR-01 à BR-CO-26 et au-delà). Mais une facture réelle est un
fichier : un XML CII (UN/CEFACT Cross Industry Invoice), un XML UBL
2.1 (OASIS), ou un PDF Factur-X — un PDF/A-3 qui embarque un
factur-x.xml en CII.
Chaque niveau a son artefact officiel de validation :
| Couche | Ce qu'elle vérifie | L'artefact qui fait foi |
|---|---|---|
| 1. Conteneur | PDF/A-3 valide, pièce jointe présente et déclarée | Spécification PDF/A-3, veraPDF |
| 2. Syntaxe | XML bien formé, conforme au schéma | XSD CII D16B (UN/CEFACT), XSD UBL 2.1 (OASIS) |
| 3. Sémantique EN 16931 | Les règles BR-* de la norme | Schematron du CEN (dépôt ConnectingEurope/eInvoicing-EN16931) |
| 4. Règles françaises | Mentions obligatoires, SIREN/SIRET, TVA FR | CIUS française, règles Factur-X (FNFE) |
| 5. Contexte de dépôt | Exigences de la Plateforme Agréée visée | Spécifications PPF/PA |
Un validateur qui mélange ces couches — ou qui n'en couvre qu'une en laissant croire qu'il couvre tout — produit le pire des résultats : un faux sentiment de sécurité, suivi d'un rejet en production.
Pourquoi « épinglé » compte autant qu'« officiel »
Les artefacts évoluent. Le Schematron du CEN en est à la série de versions
validation-1.3.x ; chaque montée de version ajoute, corrige ou durcit des
règles. Deux conséquences pratiques :
D'abord, un contrôle n'a de sens que daté : dire « valide » sans dire contre quelle version des règles n'engage à rien. Ensuite, la mise à jour doit être un acte délibéré, pas un effet de bord : si votre validateur suit silencieusement « la dernière version », une facture validée lundi peut échouer mardi sans qu'aucun octet du document n'ait changé.
Notre choix d'ingénierie : les artefacts sont vendorés, version et
empreinte SHA-256 notées dans un manifeste, et l'API expose la liste dans
/health et dans chaque réponse
via ruleset_version. La provenance est vérifiable, la mise à jour est un
commit.
Ce que ça change dans une réponse d'API
Concrètement, un contrôle chez nous renvoie les anomalies par couche :
"findings_by_layer": {
"container": [],
"syntax": [{ "code": "IG-XSD-01", "message": "…ligne 42…" }],
"semantic_en16931": [{ "code": "BR-CO-15", "message": "…" }],
"french": [{ "code": "FR-07", "message": "…" }],
"pa_context": []
}
Ce découpage n'est pas cosmétique. Une erreur de couche 2 (le XML ne respecte pas le XSD) rend souvent les couches suivantes non significatives ; une erreur de couche 4 seule signifie que votre document est europpéennement irréprochable mais localement incomplet. Le diagnostic — et la correction — ne sont pas au même endroit.
Essayez sur vos propres fichiers
Le scanner d'essai accepte vos documents sans clé API, et la documentation interactive montre l'appel complet — y compris l'envoi direct d'un XML CII, UBL ou d'un PDF Factur-X en corps de requête. Pour la référence règle par règle, le site publie une fiche par code : par exemple BR-CO-15, la règle de cohérence des totaux qui cause à elle seule une part remarquable des rejets.