Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Vendredi 9 octobre 2026
Facturation

Cycle de vie : suivre les statuts de vos factures

Dépôt, rejet, refus, encaissement : responsabilités, suivi des incidents et rapprochement des paiements dans la facturation électronique.

Le cycle de vie d’une facture permet de suivre son traitement, mais chaque statut répond à une question différente. L’acceptation par la plateforme ne signifie pas que le client approuve la prestation. Une annonce de virement ne signifie pas que le fournisseur a encaissé la somme.

Ce qu’il faut retenir

  • Le socle réglementaire prévoit les statuts dépôt, rejet, refus et encaissée, lorsqu’ils ont lieu d’être.
  • Les plateformes mettent à jour dépôt et rejet ; le destinataire renseigne le refus et l’émetteur l’encaissement concerné.
  • Un rejet peut venir de la plateforme d’émission ou de réception.
  • Le statut constate une étape : il ne crée pas à lui seul l’exigibilité de la TVA ni l’extinction d’une dette.

Lire les quatre statuts du socle

L’article 41 septies G de l’annexe IV du CGI fixe les statuts et les responsabilités suivantes. Article 41 septies G, version du 29 juillet 2026.

Statut Ce qu’il indique Action interne
Dépôt Acceptation de la facture par la plateforme de l’émetteur Vérifier ensuite la transmission et les retours
Rejet Échec de format ou de contrôles, côté émission ou réception Identifier le motif et traiter la correction
Refus Décision du destinataire Examiner la contestation avec le service concerné
Encaissée Données de paiement pour les opérations concernées Rapprocher la somme et la date avec la comptabilité

La plateforme transmet les informations réglementaires à l’administration et à celle de l’autre partie. Elle permet aux acteurs compétents de mettre à jour les statuts. Organisez donc les habilitations : un technicien peut résoudre une erreur de format sans être autorisé à accepter une contestation commerciale.

Faire correspondre les libellés de votre logiciel

Votre interface peut afficher d’autres étapes : mise à disposition, prise en charge, approbation ou litige. Demandez la correspondance entre ces libellés, les messages réellement échangés et les statuts du socle. Un voyant « envoyé » dans le logiciel ne doit pas être interprété sans savoir ce qu’il mesure.

Les normes XP Z12-012 et XP Z12-014 encadrent respectivement les messages et les cas d’usage. La DGFiP les distingue dans ses spécifications externes. Consignez la version utilisée par votre prestataire et les statuts effectivement restitués dans votre comptabilité.

Organiser le traitement des rejets et refus

Prévoyez deux files de travail. La première réunit les incidents de format, de données ou d’acheminement ; elle relève du gestionnaire de facturation et, si nécessaire, de l’éditeur. La seconde réunit les contestations ; elle nécessite la commande, les éléments de livraison ou de service fait et la décision commerciale.

Ne déclenchez pas automatiquement un avoir à chaque refus. Un client peut contester à tort ou demander un justificatif sans qu’une réduction du prix soit due. Qualifiez le motif avant de décider du document correctif. La méthode détaillée figure dans le guide rejet ou refus de facture.

À l’inverse, un fichier accepté techniquement ne dispense pas de vérifier les mentions et le régime fiscal.

Rapprocher l’encaissement de la réalité

Le reporting de paiement concerne les opérations entrant dans son champ, notamment certaines prestations dont la TVA est exigible à l’encaissement. La DGFiP distingue ce flux de la transmission des factures et de celle des données de transaction ; l’option pour les débits ou l’autoliquidation doivent être prises en compte. Présentation des obligations par la DGFiP.

Pour une prestation payée en plusieurs fois, ne traitez pas le premier versement comme un règlement intégral. Votre procédure doit rattacher les montants reçus à la bonne facture et conserver les données nécessaires à chaque transmission. Une date d’échéance ou une promesse de paiement ne remplace pas l’encaissement réel.

Les échéances de transmission varient selon le régime. Paramétrez-les avec votre comptable à partir du guide sur l’e-reporting, plutôt que d’attendre la clôture annuelle.

Tenir un tableau de supervision exploitable

Prévoyez pour chaque anomalie le numéro de facture, le statut, la date, le motif, le responsable, la prochaine action et sa limite interne. Définissez qui reprend le dossier pendant les absences. Une alerte sans personne chargée de la traiter ne sécurise pas les recettes.

Vérifiez périodiquement trois écarts : factures générées mais sans dépôt confirmé, factures rejetées sans résolution, paiements reçus sans rapprochement. Ce sont des contrôles de gestion à adapter à votre volume, sans leur attribuer une fréquence réglementaire universelle.

Conservez l’historique utile et vérifiez son export. Le statut seul ne remplace ni le fichier ni les justificatifs : reportez-vous aux règles de conservation des factures.

Garder les événements, pas seulement le dernier voyant

Un tableau qui remplace chaque statut par le suivant fait perdre des informations utiles. Pour comprendre un incident, conservez une suite d’événements rattachée à la facture : message reçu, acteur à l’origine, date de l’événement, date de réception dans votre outil et référence permettant de retrouver la pièce. Cette organisation est une méthode de gestion proposée, pas un format de journal imposé à toutes les entreprises.

La distinction des dates évite une erreur fréquente dans les intégrations : présenter comme nouvelle décision un ancien message arrivé tardivement. Demandez à l’éditeur comment son connecteur traite les retards, les doublons et les reprises après une interruption. Deux réceptions du même message ne doivent pas être interprétées sans contrôle comme deux factures ou deux encaissements. Le rapprochement doit s’appuyer sur les identifiants documentés par le prestataire.

Conservez également le motif détaillé lorsqu’il existe. « Rejetée » est insuffisant pour décider : une donnée obligatoire absente, une incohérence de calcul et une contestation du prix appellent des interlocuteurs différents. Si le libellé local ne permet pas de retrouver le message d’origine, inscrivez cette lacune dans le dossier d’incident et demandez sa clarification avant toute correction comptable.

Répartir les décisions et les escalades

Le gestionnaire de facturation doit pouvoir savoir qui décide, même quand la personne habituelle est absente. Une répartition possible distingue trois responsabilités : l’exploitation de la plateforme établit ce qui a été transmis ; le service commercial instruit le désaccord sur l’opération ; la comptabilité détermine les conséquences sur les pièces et les écritures. Dans une petite entreprise, une même personne peut cumuler ces fonctions, mais elle doit conserver les raisons de sa décision.

Fixez une limite interne de traitement selon l’enjeu du dossier. Une facture bloquée avant transmission peut nécessiter une intervention immédiate ; une contestation documentée peut demander plusieurs échanges. Cette limite de gestion ne remplace aucune échéance fiscale ou contractuelle. Si le délai choisi expire, l’alerte doit désigner une personne capable d’arbitrer, et non simplement répéter une notification dans le logiciel.

Avant de clôturer l’incident, vérifiez le résultat attendu. La correction d’un champ n’établit pas que le nouveau fichier a été accepté. L’acceptation technique n’établit pas que le désaccord commercial a disparu. Une clôture utile indique donc le problème résolu, la preuve correspondante et les questions encore ouvertes.

Décrire précisément le paiement à transmettre

L’article 242 nonies P de l’annexe II du CGI détaille les données de paiement concernées : notamment la date d’encaissement effectif, le montant encaissé ventilé par taux de TVA et, pour les opérations donnant lieu à une facture, son numéro. Ce sont ces données qu’il faut pouvoir retrouver, au-delà d’une simple case « payée ». Le champ de l’obligation reste celui de l’article 290 A du CGI.

Un virement peut couvrir plusieurs factures, tandis qu’une facture peut recevoir plusieurs règlements. Prévoyez donc une étape d’affectation. Tant que le rapprochement reste incertain, conservez cette incertitude dans la file de travail et recherchez les justificatifs nécessaires ; ne distribuez pas arbitrairement une somme pour faire disparaître l’alerte. L’objectif est d’établir les données exactes dans les délais applicables, pas de différer leur transmission sans limite.

Prenons un exemple entièrement fictif. Une prestation relevant du reporting de paiement est facturée 900 euros et réglée par deux versements de 300 puis 600 euros. Le premier versement appelle l’enregistrement de son montant et de sa date réelle, avec la ventilation fiscale pertinente. Il ne permet pas de déclarer que les 900 euros ont été reçus. Si le second virement couvre aussi une autre facture, la banque seule ne fournit pas nécessairement l’affectation complète : il faut la résoudre avec la comptabilité et, au besoin, le client.

Examiner une période complète avant de conclure

Pour vérifier votre organisation, choisissez une période délimitée et rapprochez trois ensembles : les factures produites, les événements restitués par la plateforme et les paiements enregistrés. Examinez les absences autant que les erreurs affichées. Une facture sans aucun retour peut rester invisible dans une liste réservée aux seuls rejets.

Documentez les écarts sans annoncer une réussite globale prématurée : fichier accepté mais retour non importé, refus connu seulement du commercial, paiement enregistré sans affectation. Chaque écart doit déboucher sur une action et une preuve de résolution. Répétez ce contrôle après une évolution importante du connecteur ou de l’organisation, selon votre appréciation des risques et du volume.

Vérifiez enfin que l’export permet de comprendre les événements sans accès permanent à l’interface du fournisseur. Gardez les références nécessaires pour relier le statut, le document et la décision. L’export d’une liste de voyants, dépourvue de dates ou de motifs exploitables, ne suffira pas à expliquer plusieurs mois plus tard pourquoi une facture a été corrigée ou un paiement imputé.

Questions fréquentes

Le statut dépôt prouve-t-il que le client a approuvé la facture ?

Non. Il correspond à son acceptation par la plateforme de l’émetteur. La réception, le traitement par le client et le paiement sont d’autres étapes.

Qui renseigne l’encaissement ?

L’article 41 septies G prévoit que la plateforme permet à l’émetteur de mettre à jour ce statut pour les opérations visées à l’article 290 A. Le processus doit s’appuyer sur les données de paiement pertinentes.

Un refus oblige-t-il toujours à annuler la facture ?

Non. Il faut examiner le motif et la réalité de l’opération. Une correction fiscale ou commerciale se décide après cette analyse ; le statut du client ne règle pas, à lui seul, le litige.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →