Cycle de vie11 septembre 2026 · 12 min

Votre facture électronique a été refusée : ce que ça veut dire et quoi faire

Une facture électronique ne se contente pas de partir. Elle porte un statut, qui change au fil de son traitement, et deux de ces statuts sont des échecs. Ils n'ont ni la même cause, ni le même remède — et dans un cas, la bonne réaction est exactement l'inverse de l'intuition.

Si vous êtes pressé

  • Rejetée (213) : une plateforme a trouvé une anomalie sur le document. Corrigez la facture, émettez-en une nouvelle.
  • Refusée (210) : votre client refuse. Appelez-le avant de toucher à quoi que ce soit — le motif vous dit quoi, pas pourquoi.
  • Dans les deux cas : avoir d'annulation, puis nouvelle facture. Et cet avoir ne se transmet pas — voir pourquoi plus bas, c'est le point le moins intuitif du dispositif.

Refusée, rejetée : deux mots, deux responsables

Les deux termes se ressemblent, et la presse les utilise indifféremment. Ils désignent pourtant des choses opposées, et confondre les deux fait perdre du temps au mauvais endroit : on appelle le client alors qu'il s'agit d'un arrondi, ou on relit ses totaux alors que le client contestait la livraison.

Refusée · statut 210

Ça vient de votre client

Il refuse la facture dans son intégralité. La cause est commerciale ou comptable : un montant qu'il conteste, une prestation qu'il ne reconnaît pas, une référence qui manque à son process.

Ce que vous faites : vous lisez le motif, vous comprenez, et vous parlez à votre client. Le motif est un code, pas une explication.

Rejetée · statut 213

Ça vient d'une plateforme

Celle qui émet ou celle qui reçoit. Ses contrôles fonctionnels ont détecté une anomalie sur la facture elle-même : format, cohérence, données réglementaires, habilitations.

Ce que vous faites : vous corrigez le document. Votre client n'est pas en cause et, le plus souvent, ne l'a même pas vue.

Ces deux statuts sont obligatoires dans le cycle de vie d'une facture, avec « Déposée » (200) et « Encaissée » (212). Autrement dit, toute plateforme agréée doit les émettre : vous serez informé d'un échec, quelle que soit la plateforme de votre client.

Les statuts que vous verrez passer

Voici la liste publiée par la DGFiP. Deux remarques avant de la lire. D'abord, elle n'est pas exhaustive : le document renvoie explicitement, pour la suite, à une norme AFNOR payante — donc un code au-delà de 213 existe peut-être, et personne d'honnête ne peut vous dire ce qu'il signifie. Ensuite, seuls quatre statuts sont obligatoires ; les autres sont facultatifs, et toutes les plateformes ne les émettent pas. Ne vous inquiétez pas de ne pas voir défiler les quatorze.

CodeLibelléCe que ça veut dire pour vous
200DéposéeobligatoireVotre plateforme a contrôlé la facture et la juge conforme. C'est le point de départ : à partir de là, la facture existe officiellement.
201Émise par la plateformeVotre plateforme l'a transmise à celle de votre client.
202Reçue par la plateformeLa plateforme de votre client l'a reçue.
203Mise à dispositionLa plateforme de votre client la lui a mise à disposition. Elle est dans ses mains.
204Prise en chargeVotre client accuse réception.
205ApprouvéeVotre client accepte la facture dans son intégralité.
206Approuvée partiellementIl n'accepte qu'une partie de la facture.
207En litigeIl est en désaccord sur tout ou partie de la facture.
208SuspendueIl attend des pièces justificatives et met le traitement en pause. Ce n'est pas un refus.
209ComplétéeVous avez fourni les pièces attendues. Le traitement reprend.
210RefuséeobligatoireVotre client refuse la facture dans son intégralité. Terminal : il faudra un avoir.
211Paiement transmisVotre client déclare avoir payé — ou vous, avoir remboursé.
212EncaisséeobligatoireVous déclarez avoir perçu un paiement, partiel ou total. C'est une obligation au titre de l'article 290 A du CGI.
213RejetéeobligatoireUne plateforme a détecté une anomalie sur la facture elle-même. Terminal aussi.

Le statut 208 « Suspendue » mérite une mention : ce n'est pas un refus. Quand votre client demande des pièces justificatives, la facture passe en suspens, vous renvoyez un cycle de vie « Complétée » (209) avec les pièces, et le traitement reprend là où il s'était arrêté. Aucun avoir, aucune refacturation.

Les treize motifs de refus possibles

Un refus porte toujours un motif, et ce motif est un code normé — pas un texte libre. C'est une bonne nouvelle pour vous : la liste des codes acceptés pour un refus est fermée, et il n'y a pas de code « Autre ». Votre client ne peut pas refuser « parce que ». Il doit ranger son refus dans l'une de ces treize cases.

Le nombre exact peut varier d'une plateforme à l'autre — c'est elle qui décide quels codes elle accepte pour un statut donné. Treize est le nombre sur la plateforme agréée à laquelle Deviso est adossé.

MONTANTTOTAL_ERRMontant total erroné

Un total ne tombe pas juste — souvent le net à payer. Vérifiez d'abord vos arrondis ligne par ligne.

CALCUL_ERRErreur de calcul de la facture

Détectée au contrôle automatique ou après : une ligne, un arrondi non accepté. C'est un problème de chiffres, pas de fond.

TX_TVA_ERRTaux de TVA erroné

Le taux appliqué n'est pas celui attendu. Fréquent dans le BTP, où 5,5 %, 10 % et 20 % coexistent selon la nature des travaux.

NON_CONFORMEMention légale manquante

Une mention obligatoire est absente. Si vous êtes en franchise de TVA, c'est souvent la mention de l'article 293 B du CGI qui manque.

DOUBLONFacture en doublon

Même numéro, même émetteur, même année. C'est le motif pour une facture reçue deux fois.

DOUBLE_FACTDonnées réglementaires F1 en doublon

Attention, ce n'est PAS « double facturation ». Il s'agit du doublon des données transmises à l'administration, pas de la facture.

DEST_ERRErreur de destinataire

La facture est partie à la mauvaise entité. Arrive avec les groupes à plusieurs établissements.

ADR_ERRAdresse de facturation électronique erronée

L'adresse électronique du destinataire est absente ou fausse. C'est un problème d'annuaire, pas de contenu.

TRANSAC_INCTransaction inconnue

La facture ne correspond à aucune livraison ou prestation que le client identifie. À clarifier avant de refacturer.

EMMET_INCÉmetteur inconnu

Votre client ne vous identifie pas. C'est un garde-fou anti-spam : il faut se faire référencer chez lui.

CONTRAT_TERMContrat terminé

Plus de facturation possible sur ce contrat. Vérifiez la date de fin avant d'émettre.

CMD_ERRN° de commande incorrect ou manquant

Numéro erroné, inexistant ou déjà facturé. Ne justifie un refus que si l'acheteur vous avait fourni ce numéro AVANT la facturation.

REF_CT_ABSENTRéférence contractuelle manquante

Une référence exigée par le contrat manque : numéro de contrat, de bon de livraison, référence acheteur ou projet.

Le piège de DOUBLE_FACT

Ce code ne veut pas dire « double facturation ». Il désigne le doublon des données réglementaires transmises à l'administration. Si vous avez réellement été facturé deux fois — ou si votre client le croit — le motif est DOUBLON. C'est exactement le genre d'erreur de lecture qui fait annuler une facture pour la mauvaise raison, et Deviso l'a faite avant de lire la table normative.

L'avoir : pourquoi il ne faut pas le transmettre

Un refus et un rejet sont tous deux terminaux. On ne modifie pas une facture déjà déposée : la numérotation est continue, le document est archivé, et c'est précisément ce qui fait sa valeur probante. La marche à suivre est donc toujours la même : un avoir qui annule la facture, puis une nouvelle facture corrigée.

Et voilà le point que presque aucun contenu n'explique. Les spécifications externes de la DGFiP sont explicites :

« Dans les cas des statuts “Refusée” ou “Rejetée”, le fournisseur doit procéder à une annulation comptable (avoir interne). Cette opération ne doit pas générer de flux de données réglementaires au portail public de facturation. »

Autrement dit : l'avoir reste chez vous. Il existe dans votre comptabilité, il annule bien la facture, mais il ne part pas dans le circuit réglementaire.

La logique est cohérente quand on y regarde : l'administration a déjà reçu le statut d'échec. Elle sait que cette facture n'a pas abouti. Lui transmettre en plus un avoir reviendrait à déclarer deux fois la même annulation — un doublon de données, exactement ce que le dispositif cherche à éviter.

Avoir interne — ne se transmet pas

Quand il annule une facture refusée ou rejetée. Écriture comptable, point.

Avoir ordinaire — se transmet

Quand il annule une facture qui a, elle, abouti : remise accordée après coup, geste commercial, retour de marchandise. Là, l'administration n'a aucune raison de le savoir autrement.

C'est une distinction qu'un logiciel doit faire à votre place, parce qu'elle dépend du statut de la facture annulée et que personne ne devrait avoir à s'en souvenir. Dans Deviso, elle est codée et couverte par un test automatisé — c'est le genre de règle qui ne se voit pas quand elle est juste, et qui se paie quand elle est fausse.

Quoi faire, dans l'ordre

  1. 1

    Lisez le statut avant le motif

    Rejetée ou refusée ? Ça détermine à qui vous parlez. Un rejet se règle seul, un refus se règle à deux.

  2. 2

    Ne refacturez pas tout de suite

    Le motif dit ce qui est reproché, pas pourquoi. Un « montant total erroné » peut être un arrondi de votre côté comme un désaccord sur le périmètre. Un appel de trois minutes évite un deuxième refus.

  3. 3

    Passez l'avoir d'annulation

    Interne, non transmis. Il annule la facture dans votre comptabilité et dans votre numérotation.

  4. 4

    Corrigez, puis émettez une nouvelle facture

    Nouveau numéro, à la suite. Ne réutilisez jamais le numéro de la facture annulée : la continuité de la numérotation est une obligation (article 242 nonies A du CGI).

  5. 5

    Notez le motif quelque part

    Si le même motif revient avec le même client, ce n'est plus un incident, c'est un réglage à faire : une référence à ajouter systématiquement, un taux à revoir, un interlocuteur à changer.

Les trois causes de refus les plus évitables

La référence que le client exige et que vous ne mettez pas

Numéro de commande, référence de contrat, code de projet. Beaucoup de refus n'ont rien à voir avec votre travail : votre facture n'entre pas dans le process comptable du client. Demandez une fois quelles références sont obligatoires, et mettez-les à chaque fois.

La mention légale manquante en franchise de TVA

Si vous êtes en franchise en base, la mention « TVA non applicable, art. 293 B du CGI » doit figurer sur la facture. Et surtout : ne créez pas une ligne de TVA à 0 %, c'est l'erreur classique. Ce n'est pas la même chose qu'une exonération, et un contrôle automatique peut la rejeter.

L'arrondi qui ne tombe pas juste

Une facture dont les lignes ne s'additionnent pas exactement au total est refusable, et c'est d'autant plus rageant que ça ne vient jamais de vous mais de l'outil. Vérifiez une fois, sur une vraie facture, que vos lignes arrondies font bien le total affiché.

Questions fréquentes

Quelle est la différence entre une facture refusée et une facture rejetée ?

Un refus (statut 210) vient de votre client : il refuse la facture dans son intégralité, pour un motif commercial ou comptable. Un rejet (statut 213) vient d'une plateforme — celle qui émet ou celle qui reçoit : ses contrôles fonctionnels ont détecté une anomalie sur la facture elle-même. Le premier se règle avec votre client, le second en corrigeant le document. Ce sont les deux seuls statuts d'échec, et ils sont tous deux obligatoires dans le cycle de vie.

Peut-on corriger une facture refusée et la renvoyer ?

Non, pas directement. Un refus est terminal : les spécifications de la DGFiP prévoient que le fournisseur procède à une annulation comptable, c'est-à-dire un avoir, puis émette une nouvelle facture corrigée. On ne modifie pas une facture déjà déposée — c'est tout l'intérêt de la numérotation continue et de l'archivage.

Faut-il transmettre l'avoir qui annule une facture refusée ?

Non, et c'est le point le plus contre-intuitif de tout le dispositif. Les spécifications externes de la DGFiP précisent que dans le cas des statuts « Refusée » ou « Rejetée », l'annulation comptable ne doit pas générer de flux de données réglementaires. L'administration sait déjà que la facture n'a pas abouti : elle a reçu le statut d'échec. Transmettre l'avoir créerait un doublon de données. L'avoir reste donc interne à votre comptabilité.

Mon client peut-il refuser une facture pour n'importe quel motif ?

Non. Le motif de refus est un code normé, et la liste des codes acceptés pour le statut « Refusée » est fermée. Sur la plateforme agréée à laquelle Deviso est adossé, treize codes seulement sont acceptés pour ce statut — et il n'y a pas de code « Autre ». Un refus doit donc entrer dans l'une de ces treize cases, ce qui est une protection : votre client ne peut pas refuser « parce que ».

Que se passe-t-il si mon client demande seulement des justificatifs ?

Ce n'est pas un refus. Le motif « Justificatif absent ou insuffisant » fait passer la facture au statut « Suspendue » (208) et non « Refusée ». Vous renvoyez alors un cycle de vie « Complétée » (209) avec les pièces manquantes, et le traitement reprend. La facture n'est pas annulée, et vous n'avez pas d'avoir à passer.

Combien de statuts existe-t-il, et doit-on les connaître tous ?

Non. La liste publiée par la DGFiP va de 200 à 213 et n'est explicitement pas exhaustive — elle renvoie, pour le reste, à une norme AFNOR payante. Mais quatre statuts seulement sont obligatoires pour une facture : Déposée (200), Refusée (210), Encaissée (212) et Rejetée (213). Les autres sont facultatifs, et toutes les plateformes ne les émettent pas.

Sources

Tout ce qui est écrit ici vient du dossier de spécifications externes de la facturation électronique, version 3.2, publié par la DGFiP le 30 avril 2026 :

  • le dossier général, pour le tableau des statuts du cycle de vie et la règle de l'avoir interne ;
  • l'annexe 2 (format sémantique du cycle de vie), pour les statuts obligatoires et le champ de code motif ;
  • l'annexe 7 (règles de gestion), pour le tableau des motifs de refus.

Le paquet se télécharge sur impots.gouv.fr. La liste des statuts au-delà de 213 relève de la norme AFNOR XP Z12-012, qui est payante : c'est pour ça que vous ne trouverez nulle part de traduction fiable de ces codes, y compris ici.

À lire ensuite

SA

S. Albert · Fondateur de Deviso

Développeur indépendant en Gironde, fondateur de Deviso. J'ai lu les spécifications externes de la DGFiP pour écrire le code qui s'y conforme — c'est de là que vient tout ce que vous lisez ici.

Comment je travaille, et comment me signaler une erreur →