Dossier de consultation / DAF et DSI
Statuts de facture : suivre le cycle dans l’ERP
Organisez corrélation, événements, rejets et décisions métier pour suivre le cycle de vie des factures électroniques dans votre ERP.
Mis à jour le .
Les quatre statuts obligatoires
Chaque facture échangée suit un cycle de vie que la plateforme agréée matérialise par des statuts. La DGFiP précise que quatre d’entre eux sont obligatoirement proposés et transmis à l’administration. Déposée : la facture est acceptée par la plateforme de l’émetteur et horodatée. Rejetée : la plateforme de l’émetteur ou celle du destinataire n’accepte pas la facture (format non conforme, incohérence entre montants hors taxe, TVA et TTC, identification incorrecte) ; si le rejet vient de la plateforme de l’émetteur, la facture n’est pas transmise à celle du client. Refusée : la facture a bien été transmise, mais le destinataire la refuse, avec un motif. Encaissée : le paiement est indiqué, avec sa date et son montant, par le fournisseur qui l’a reçu.
Une dizaine d’autres statuts sont facultatifs ou recommandés, par exemple la mise à disposition, la prise en charge, l’approbation, le litige ou le paiement transmis. La liste et les codes figurent dans la norme XP Z12-012 et dans les spécifications externes, dont la version 3.2 date du 30 avril 2026.
Ce que l’ERP doit en faire
Un statut sans action correspondante est une information perdue. Pour chacun des quatre, décidez ce que l’ERP affiche, qui est alerté et ce qui est autorisé. Sur Déposée, l’ERP conserve la date d’horodatage de la plateforme. Sur Rejetée, il ouvre une tâche de correction et bloque la réémission d’une seconde facture non contrôlée. Sur Refusée, il route le motif vers le service concerné. Sur Encaissée, il doit pouvoir alimenter le statut à partir du règlement réconcilié en comptabilité, puisque c’est le fournisseur qui l’indique ; ces mêmes données servent au e-reporting de paiement.
Ne créez pas une équivalence entre deux libellés parce qu’ils se ressemblent : « approuvée » côté plateforme n’est pas « validée pour paiement » côté achats, tant que le dictionnaire de correspondance ne l’a pas établi.
Rejet et refus : deux traitements
Selon le guide de démarrage de la DGFiP, un rejet est un incident à corriger. L’entreprise identifie la cause, corrige la facture et la retransmet par le circuit électronique ; si la difficulté vient du routage ou des données de réception, elle se rapproche de sa plateforme, de son prestataire ou de son client. Elle conserve la facture concernée, le message de rejet, la cause et les démarches.
Le refus est un statut distinct, posé par l’acheteur et obligatoirement motivé. Il ne doit pas servir à trancher un simple litige commercial. Si le refus révèle une erreur, le vendeur la corrige et émet, si nécessaire, une nouvelle facture portant un nouveau numéro, pour éviter toute confusion avec la facture refusée. S’il accepte un refus fondé, il traite les conséquences dans ses propres systèmes (avoir interne, remboursement, régularisation ultérieure). S’il le conteste, il ne crée pas automatiquement une nouvelle facture ni un avoir : il instruit le désaccord avec l’acheteur.
Conserver une identité commune au document
L’ERP, le connecteur et la plateforme peuvent utiliser des identifiants différents. Conservez une table de correspondance entre ces références et le numéro de facture, avec l’émetteur et l’entité, pour que deux sociétés d’un groupe ayant une numérotation proche ne se confondent pas. Le journal distingue le document du message : une facture produit plusieurs notifications, parfois en retard ou reçues deux fois après une reprise, et un deuxième message ne signifie pas une deuxième facture.
Décrire les transitions sans perdre l’historique
Un schéma relie état source, événement et état cible. Une réponse tardive ne doit pas ramener silencieusement une facture à un état moins avancé. Un événement inconnu ou incompatible avec l’état enregistré déclenche une alerte adressée à un responsable et conserve le message d’origine, plutôt que d’être supprimé pour garder une liste sans anomalie.
Scénarios de recette à jouer
Notification en double, événement tardif, interruption entre deux composants, événement jamais reçu : pour chacun, indiquez l’état attendu, la preuve et le validateur. Un rapprochement périodique entre les factures de l’ERP et celles de la plateforme permet de repérer un document resté sans réponse et de déterminer si le problème vient du transport, du traitement ou d’une attente métier.
Grille à joindre à la consultation
| Point | Preuve à demander |
|---|---|
| Message | Code, version et signification reliés à une référence technique datée et à un libellé utilisateur. |
| Corrélation | Identifiants ERP et plateforme associés au document et à son entité, distincts des notifications. |
| Transition | État avant, événement reçu, état après et comportement en cas d’incohérence décrits. |
| Correction | Décision métier séparée du diagnostic technique, avec utilisateur autorisé et trace de l’action. |
| Preuve | Historique conservé et scénario de doublon ou de réponse tardive rejoué en recette. |
Livrable attendu
Le livrable demandé est un dictionnaire des événements accompagné d’un schéma de transitions et d’un jeu de tests. La DAF valide les actions comptables associées, tandis que la DSI valide la corrélation et les reprises. Conservez les messages inconnus dans une file suivie plutôt que de les ignorer. La procédure de support doit permettre de répondre à une question concrète : où se trouve cette facture et quelle action peut être autorisée maintenant ?