Tous les articles

Business Central

Les quatre statuts AFNOR : ce que votre équipe compta fait vraiment à chacun

Chaque facture électronique reçue traverse quatre statuts obligatoires avant d'être soldée. La plupart des explications s'arrêtent au nom du statut. Voici ce que chacun signifie pour la personne qui travaille vraiment le brouillon d'achat, et où se situent les vraies échéances.

Quatre icônes de document arrondies alignées et reliées par une ligne turquoise lumineuse, s'illuminant progressivement de la plus terne à la plus lumineuse avec une coche finale, illustrant un document qui traverse quatre statuts successifs.

Les quatre statuts AFNOR : ce que votre équipe compta fait vraiment à chacun

Chaque facture qu’une entité française reçoit via une Plateforme Agréée porte l’un des quatre statuts AFNOR obligatoires : Déposée, Rejetée, Refusée, Encaissée. La plupart des articles sur la réforme listent les quatre noms et passent à autre chose. Ce qui compte opérationnellement est plus étroit : lesquels des quatre demandent une action de votre équipe compta, et lesquels ne sont qu’un enregistrement de ce qui s’est déjà passé.

Que signifie Déposée, et faut-il agir dessus ?

Déposée est posé au moment où votre fournisseur dépose la facture sur sa propre Plateforme Agréée, avant même qu’elle n’atteigne la vôtre. Ce n’est pas une action à faire — c’est le coup de départ. Si un fournisseur vous dit avoir envoyé une facture il y a des semaines et que rien n’est arrivé dans Business Central, vérifier si elle a seulement atteint Déposée de son côté est le premier réflexe de diagnostic, pas un problème Business Central.

Que signifie Rejetée, et en quoi diffère-t-elle d’un refus ?

Rejetée intervient avant qu’un document ne devienne quelque chose que vous traitez dans Business Central — typiquement un problème technique ou de format attrapé au niveau de la plateforme, pas une décision métier de votre équipe. C’est le statut le plus souvent confondu avec Refusée, et la distinction compte : un document Rejetée signifie en général que votre fournisseur a un problème de données à corriger et à renvoyer, pas quelque chose que votre équipe compta doit examiner ligne par ligne.

Que signifie Refusée, et qu’exige vraiment Business Central ici ?

Refusée est le seul statut que votre équipe pose délibérément. Si un brouillon d’achat ne correspond pas — mauvais montant, mauvaise référence de commande, une ligne qui n’aurait jamais dû être facturée à votre entité — FacturaLink fait apparaître une action Refuser directement dans le brouillon. Refuser sans motif n’est pas conforme : la réforme impose un code motif AFNOR, et Business Central renvoie ce code, plus une note optionnelle, à la plateforme comme statut sortant. Votre fournisseur voit une raison précise et codée, pas un « litigieux » vague.

C’est aussi là qu’un groupe se trompe le plus souvent dans l’interaction : le personnel au niveau entité refuse un document sans vérifier si l’écart est un problème de données (corrigeable, à renvoyer) ou un vrai litige commercial (pas corrigeable en renvoyant la même facture sous un autre format). Le code motif devrait vous dire lequel des deux vous avez sous les yeux avant de comptabiliser quoi que ce soit.

À quoi ça ressemble de bout en bout pour une facture ?

Prenez un cas courant : une filiale reçoit une facture d’achat via la plateforme connectée. Elle apparaît dans Business Central en Déposée dès que le fournisseur la dépose — rien à faire pour l’instant. La plateforme valide le format et la laisse passer ; si elle avait échoué à ce contrôle, elle afficherait Rejetée à la place, et la correction reviendrait au fournisseur, pas à votre équipe compta.

Supposons qu’elle passe. Le brouillon d’achat s’ouvre avec le fournisseur, le montant et les lignes déjà renseignés depuis le document électronique. Quelqu’un le rapproche du bon de commande. Deux issues à partir de là : si ça correspond, le document est comptabilisé, et la plateforme reçoit un statut d’approbation automatiquement — aucun signal manuel au-delà de la comptabilisation, parce que Business Central l’envoie pour vous. Si une ligne ne correspond pas — par exemple des frais de livraison facturés qui n’étaient pas sur la commande — le brouillon passe en Refusée, avec un code motif choisi dans le même écran et, idéalement, une courte note. Le fournisseur voit exactement pourquoi, et peut corriger et renvoyer plutôt que de deviner.

Des semaines plus tard, une fois que la comptabilité du fournisseur confirme avoir été payée, Encaissée revient sur le même document. Personne dans votre équipe ne déclenche rien pour ça ; ça boucle le dossier pour qui l’auditera plus tard. Le cycle entier — quatre statuts, une seule décision manuelle — se déroule sans que personne ne quitte Business Central ni ne rapproche un second système à la main.

Que signifie Encaissée si je suis l’acheteur, pas le vendeur ?

Encaissée vous est renvoyé une fois que la plateforme de votre fournisseur confirme qu’il a été payé — par vous ou, en cas d’affacturage, par qui il a cédé la créance. Pour un acheteur, ce n’est pas non plus une action à faire ; c’est la confirmation que le cycle s’est bouclé proprement sur l’enregistrement partagé par les deux parties. Sa valeur est dans le creux : si une facture que vous savez avoir payée n’atteint jamais Encaissée, ça vaut le coup d’investiguer avant que le service recouvrement de votre fournisseur n’appelle.

Où se situent vraiment les échéances dans ce cycle ?

Pas sur Déposée ni sur Encaissée — ces deux-là vous arrivent dessus. La pression de délai est entièrement sur Refusée : la réforme attend d’un acheteur qu’il réagisse à un document entrant dans une fenêtre définie, et un brouillon d’achat qui dort dans Business Central n’est pas un état neutre, c’est une horloge qui tourne. Un groupe avec plusieurs entités et aucun responsable unique pour « qui vérifie les brouillons » est le groupe qui découvre qu’un document a dépassé sa fenêtre de réponse pendant une clôture mensuelle, pas avant.

Que se passe-t-il si personne dans l’entité ne vérifie les brouillons ?

L’échec n’est en général pas une facture perdue — Business Central garde l’enregistrement. C’est un brouillon qui stagne : non refusé, non comptabilisé, parce que la responsabilité de « qui travaille les brouillons pour cette entité » n’a jamais été assignée au démarrage de la réforme. On détaille cette question de responsabilité — stratégie de plateforme au niveau groupe contre responsabilité des données et des tests au niveau entité — comme l’une des décisions à trancher une fois, pas à redécouvrir à chaque fois qu’un document stagne.

L’approche Asio Services

On a construit l’action Refuser et le suivi des statuts AFNOR directement dans le brouillon d’achat, à l’intérieur de FacturaLink, parce qu’un statut que votre équipe doit aller chercher dans un outil à part est un statut vérifié moins souvent qu’il ne le devrait. Si vos entités n’ont pas encore de réponse claire à « qui vérifie les brouillons », commencez par notre formulaire clarté et on vous aide à la trouver avant que la réforme ne s’en charge.

FAQ

Les quatre statuts AFNOR s’appliquent-ils à toutes les factures ?

Déposée et, à terme, soit Refusée soit une approbation implicite s’appliquent toujours. Rejetée n’apparaît que si la plateforme attrape un problème technique avant que le document ne vous atteigne. Encaissée dépend du reporting de votre fournisseur une fois le paiement réglé.

Un document peut-il repasser de Rejetée à un état exploitable ?

Pas le même document. Rejetée signifie que la plateforme ne l’a pas accepté comme valide ; votre fournisseur corrige la donnée en cause et renvoie, ce qui arrive comme un nouveau document, pas comme une version corrigée de l’ancien.

Refuser un document avec un code motif AFNOR annule-t-il la facture ?

Non. Ça renvoie un statut codé à la plateforme de votre fournisseur, expliquant pourquoi vous ne l’avez pas accepté tel quel. Ce qui se passe ensuite — un renvoi corrigé, un avoir, une discussion commerciale — se joue entre vous et le fournisseur ; Business Central et la plateforme ne portent que le statut.

Qui doit être responsable de la vérification des brouillons d’achat dans un groupe multi-entités ?

La responsabilité de la stratégie et du contrat de plateforme au niveau groupe, celle des brouillons eux-mêmes au niveau entité — parce que les échecs qui comptent se produisent au niveau de l’enregistrement, entité par entité, pas au niveau du tableau de bord groupe.

Votre Business Central est-il le problème, ou le symptôme ?

On audite ce que vous faites tourner réellement, on nomme ce qui vaut le coup d’être gardé, et on tue le reste. Une conversation suffit en général à savoir dans quel cas vous êtes.

Commence par la clarté