Pourquoi un avertissement devient-il un rejet chez une autre plateforme ?
Deux résultats ne sont comparables que si le même fichier a été contrôlé avec le même profil, la même version et le même mode de sévérité. Les contrôles français consultés prévoient notamment une transition datée entre avertissement et erreur bloquante ; il faut donc examiner le contexte du contrôle.
Écarter d’abord une différence de fichier
Un nom de fichier identique ne prouve pas que deux contrôles ont lu le même contenu. Une conversion, une régénération ou l’extraction du XML embarqué peut changer ce qui est vérifié.
Conservez le fichier soumis à chaque contrôle, son format et son profil déclaré. Si les fichiers diffèrent, comparez leurs valeurs avant d’attribuer l’écart à la sévérité.
Demandez ensuite le rapport complet. Un écran peut regrouper plusieurs constats sous un même libellé, alors qu’un autre expose chaque assertion séparément. Le nombre de messages affichés ne mesure pas directement le nombre de défauts indépendants.
Lire la version et le sens du contrôle
Les en-têtes des fichiers français vérifiés datent le correctif au 4 septembre 2026. Ils distinguent un mode d’avertissement applicable uniquement en réception et un mode d’erreur bloquante dont les échéances sont précisées.
Le mode d’avertissement est indiqué applicable en réception dès la publication et jusqu’au 30 septembre 2026 au plus tard. Le mode bloquant est indiqué applicable en réception au plus tard le 1er octobre 2026 et en émission à compter du 1er octobre 2026.
Ces mentions portent sur les fichiers de contrôle cités. Elles ne prouvent pas la configuration effectivement utilisée par une plateforme donnée le jour de votre incident. Demandez cette information dans le ticket de support.
| Mode | Période et sens indiqués |
|---|---|
| Avertissement | Réception uniquement, de la publication jusqu’au 30 septembre 2026 au plus tard. |
| Bloquant | Réception au plus tard le 1er octobre 2026 ; émission à compter du 1er octobre 2026. |
Comparer une assertion précise
Une fois le fichier et le contexte établis, comparez l’identifiant de la règle, le champ testé, la condition et sa sévérité dans les deux rapports. Une différence de profil peut ajouter ou retirer une couche de contrôle ; une différence de version peut modifier une condition.
Documentez les différences constatées avant d’adapter l’export. Désactiver une règle parce qu’un autre outil ne la signale pas ne démontre pas la conformité de la facture.
Pour confirmer un décalage de version, rejouez le même exemple avec les deux jeux de règles identifiés. Le compte rendu doit indiquer les versions réellement exécutées, pas seulement celle du logiciel qui affiche le résultat.
Pour vérifier
Sources et repères techniques
FNFE-MPE · Modes de contrôle France Flux 2 UBL
1.4.0.04 · 4 septembre 2026
En-têtes de BR-FR-Flux2-Schematron-UBL.sch et BR-FR-Flux2-Schematron-UBL_WARNING.sch.
L’en-tête du mode FATAL indique une application en réception au plus tard le 1er octobre 2026 et en émission à compter du 1er octobre 2026.
Fichiers UBL consultés : BR-FR-Flux2-Schematron-UBL.sch et BR-FR-Flux2-Schematron-UBL_WARNING.sch, FNFE 1.4.0.04, last fix04 du 04/09/2026. La date du commit d’import du 05/09/2026 ne remplace pas la date de version.
Conserver la sévérité brute de l’assertion, le scénario, le sens émission/réception et le rapport de validation. La configuration d’une PA particulière reste à établir à partir de ses propres retours.
Ce qu’il faut faire
- Vérifier que les deux contrôles portent sur le même fichier.
- Relever les profils, versions, sens et modes réellement exécutés.
- Comparer une règle précise et sa condition, puis demander une explication au support si l’écart demeure.
- Conserver les deux rapports et vérifier le résultat après toute correction ou mise à jour.
Diag Invoice automatise le contrôle des factures et la lecture des écarts techniques décrits dans ces réponses.