Comprendre un résultat de validation et les erreurs courantes

Vous avez déposé une facture et le résultat affiche « invalide », « avertissement », ou peut-être « fichier rejeté ». Que faut-il en conclure, et surtout, que faut-il corriger ? Cet article explique comment lire un résultat de validation, ce que sont ces identifiants de règles un peu austères (BR-CO-16, BR-FR-08…), et les erreurs que nous voyons le plus souvent.

Statut de traitement et verdict : deux choses différentes

La première chose à regarder n’est pas le verdict, mais le statut de traitement. Il répond à la question : « l’analyse a-t-elle pu être menée au bout ? »

• Analyse terminée : le fichier a été reconnu et toutes les règles applicables ont été exécutées. Un verdict existe.
• Fichier rejeté : le fichier n’est pas quelque chose que ce validateur peut analyser : un type de fichier non pris en charge, un profil Factur-X hors périmètre, un fichier vide ou trop volumineux. Aucun verdict n’existe.
• Échec de l’analyse : le fichier était peut-être parfaitement correct, mais le service n’a pas pu conclure (délai dépassé, incident interne). Aucun verdict n’existe non plus.

Ce point est essentiel : un fichier rejeté n’est pas une facture invalide. Un PDF ordinaire sans XML intégré, par exemple, n’est pas une « mauvaise facture électronique » ; ce n’est pas une facture électronique du tout au sens du socle. À l’inverse, un verdict n’est prononcé que lorsque l’analyse est réellement allée au bout.

Quand l’analyse est terminée, le verdict prend l’une de ces trois valeurs :

• Valide : tous les contrôles obligatoires applicables sont passés, sans avertissement.
• Avertissement : les contrôles obligatoires passent, mais au moins une règle non bloquante signale un point à vérifier.
• Invalide : au moins une règle obligatoire échoue.

Anatomie d’une anomalie : règles et termes métier

Chaque anomalie affichée provient d’une règle officielle, identifiée de façon stable :

• BR-* (« business rule ») : les règles du socle européen EN 16931, par exemple BR-25, « chaque ligne de facture doit avoir un nom d’article ».
• BR-CO-* : les règles de cohérence calculatoire du même socle, celles qui vérifient que les totaux s’additionnent correctement.
• BR-FR-* : les règles françaises, publiées dans le paquet de validation FNFE « France RFE » (version utilisée ici : 1.4.0.03), qui complètent le socle européen : identification des parties, mentions nationales, cas d’usage français.

Les règles s’expriment à l’aide des termes métier : BT-1 est le numéro de facture, BT-112 le total TTC, BT-115 le montant à payer… Ces identifiants sont les mêmes dans les trois syntaxes (Factur-X, UBL, CII), ce qui permet de parler de la même donnée quel que soit le format du fichier.

Un exemple concret : BR-CO-16

La règle BR-CO-16 illustre bien le mécanisme. Elle impose l’égalité suivante :

Montant à payer (BT-115) = total TTC (BT-112) − montant déjà payé (BT-113) + arrondi (BT-114)

Si votre facture affiche un total TTC de 1 200 €, aucun acompte et aucun arrondi, mais un montant à payer de 1 199 €, la règle échoue : verdict invalide, avec BR-CO-16 en anomalie fatale et BT-115 comme terme concerné. La correction ne consiste pas à « faire disparaître l’erreur », mais à comprendre lequel des montants est faux dans votre logiciel de facturation, souvent un arrondi de ligne ou un acompte mal reporté.

Les erreurs les plus courantes

• Erreur de schéma (XSD) : le fichier XML ne respecte pas la structure de sa syntaxe : élément manquant, mal ordonné ou mal nommé. C’est presque toujours un problème du logiciel émetteur, pas de la saisie.
• Totaux et TVA incohérents (BR-CO-*) : sommes de lignes, assiettes et montants de TVA qui ne se recoupent pas, généralement à cause d’arrondis calculés ligne à ligne puis totalisés différemment.
• Identification française manquante (BR-FR-*) : SIREN/SIRET absent ou mal placé pour le vendeur ou l’acheteur, mentions exigées par les règles françaises non renseignées.
• Profil Factur-X inattendu : un fichier au profil MINIMUM ou BASIC là où l’échange exige un profil riche (EN 16931 ou EXTENDED). Le fichier peut être conforme à son profil et néanmoins inutilisable pour votre cas d’usage.
• PDF sans XML intégré : un PDF « scanné » ou bureautique classique, sans fichier factur-x.xml embarqué. Ce n’est pas une facture électronique au sens du socle : le fichier est rejeté, pas invalidé.

Comment corriger

La règle d’or : corrigez dans le logiciel qui a produit la facture, jamais à la main dans le fichier XML final. Une facture électronique est un document de bout en bout : la version corrigée doit être régénérée, revalidée puis retransmise par votre circuit habituel. Modifier le XML manuellement produit des documents incohérents (visuel PDF différent des données, signatures et empreintes invalidées) et masque la cause réelle du problème, qui se reproduira à la facture suivante.

Concrètement : notez l’identifiant de la règle et le terme métier concerné, retrouvez le champ correspondant dans votre outil (le montant, le taux, l’identifiant d’entreprise…), corrigez à la source, puis régénérez le fichier et revalidez-le. Si la même règle échoue sur toutes vos factures, transmettez l’identifiant de règle à votre éditeur : c’est le vocabulaire commun prévu pour cela, documenté dans les spécifications externes B2B et les ressources du FNFE.

Limites du service

MaFactureOK contrôle la conformité technique de la facture et, lorsque les identifiants sont présents, vérifie le fournisseur auprès des sources officielles disponibles. Le site n’est pas une plateforme agréée : il ne transmet aucune facture et ne garantit ni la validité juridique absolue d’un document, ni son acceptation finale par votre plateforme agréée. Un résultat porte uniquement sur les contrôles affichés et la version indiquée du référentiel.