Rejetée ou refusée : lire le retour d'une facture électronique

Une facture électronique revient avec un statut. Les équipes comptables lisent souvent « Rejetée » et « Refusée » comme deux mots pour le même échec. Ce sont deux événements différents, posés par des acteurs différents, à des étapes différentes. Ce guide explique ce que chaque statut dit, ce qu’il ne dit pas, et ce que le code motif ajoute.

Rejetée, refusée : deux statuts, deux auteurs

Le cycle de vie d’une facture électronique compte des statuts obligatoires et des statuts facultatifs. Quatre sont obligatoires et transmis à l’administration : « Déposée » (200), « Refusée » (210), « Encaissée » (212) et « Rejetée » (213).

Le guide pratique de la DGFiP précise la différence. Le rejet correspond à une difficulté de transmission ou de contrôle : erreur de format, donnée obligatoire absente ou incohérente, identification incorrecte d’une partie, difficulté de routage. Le refus n’est pas une anomalie technique : c’est le client qui refuse. Il est obligatoirement motivé et réservé aux motifs prévus par la norme : non-conformité réglementaire que la plateforme de réception n’a pas détectée, facture mal adressée, ou conditions contractuelles non respectées qui empêchent le traitement. Il ne doit pas servir à un simple litige commercial ; le cycle de vie prévoit pour le désaccord un statut facultatif, « En litige » (207).

Ce que le statut dit, et ce qu’il ne dit pas

Le statut répond à deux questions : qui a arrêté la facture, et à quelle étape. Il ne répond pas aux deux questions qui comptent pour corriger : quelle donnée est en cause, et qui doit la modifier.

C’est le rôle du code motif. Les règles de gestion des spécifications imposent un code motif pour chaque rejet et chaque refus, et un commentaire qui motive le refus. La liste officielle des codes est publiée dans l’annexe 7 des spécifications externes.

Même le code motif ne suffit pas toujours. Prenons DEST_INC, « Destinataire inconnu » : à l’émission, le destinataire n’existe pas dans l’annuaire. Trois causes très différentes produisent ce même code : un SIREN faux dans la fiche client, un client qui a cessé son activité, ou un client actif qui n’a pas encore désigné de plateforme de réception. Dans les deux premiers cas, c’est l’émetteur qui corrige son fichier. Dans le troisième, c’est le client qui doit agir. Le guide facture rejetée pour SIREN inconnu détaille ce tri.

Les codes motifs officiels

Voici une partie des codes de la liste officielle, avec leur libellé.

Pour ROUTAGE_ERR, l’annexe précise qu’une fois l’annuaire corrigé par le destinataire, la facture peut être transmise à nouveau sans aucun changement sur ses données.

Un même code peut avoir des causes différentes, qui ne se corrigent pas toutes au même endroit. La DGFiP demande, pour une difficulté de transmission ou de routage, de se rapprocher de sa plateforme, de son prestataire ou de son client. Pour les causes qui viennent de la fiche client, voir SIREN, SIRET ou code de routage et facturer une société d’un groupe.

Que faire ensuite, statut par statut

Après un rejet, la DGFiP demande d’identifier d’abord la cause. Si l’erreur est imputable à l’émetteur, il corrige la facture et la transmet à nouveau par le circuit électronique. Si le rejet empêche le client de disposer de la facture et bloque un paiement, un double peut être envoyé par un autre canal, clairement rattaché à la facture d’origine, sans créer de doublon de paiement ni de comptabilisation.

Après un refus, le vendeur analyse le motif. Si le refus est fondé, il corrige et émet une nouvelle facture avec un nouveau numéro. S’il conteste le refus, il ne crée pas automatiquement de nouvelle facture ni d’avoir : il instruit le désaccord avec le client et documente la suite donnée. Le statut « Refusée » ne tranche pas le différend entre les parties.

Dans les deux cas, les spécifications prévoient une annulation comptable par avoir interne, sans transmission de données à l’administration pour cette opération. Et dans les deux cas, la DGFiP demande de conserver les éléments : facture, statut et motif, cause, démarches, facture corrigée, échanges.

Classer les retours pour ne pas corriger deux fois

Un retour traité isolément se corrige, puis revient. Suivre les rejets et les refus par code motif montre où se trouve le travail. Quand les mêmes causes se répètent dans le fichier clients, la correction se fait une fois dans le fichier clients, pas facture par facture. La DGFiP le demande aussi : l’entreprise doit prendre les actions correctives nécessaires pour éviter les rejets.

Sirenity propose une Découverte gratuite, à partir d’un export du fichier clients ou fournisseurs, pour mesurer sous 24 h ouvrées ce qui, dans le référentiel, peut produire ces retours.