Suivi des factures et des impayés : de l’encours à la relance

La situation

Prenons Nordica, une entreprise fictive de distribution B2B. Ses clients vont du grand compte à la TPE, ses factures partent à 30 ou 45 jours, et sa direction financière suit l’encours dans un tableur reconstitué chaque fin de mois à partir de deux extractions : l’une de la base de facturation, l’autre du CRM, où vivent les comptes et les commerciaux qui les portent.

Ce tableur répond à la question qu’on lui a posée le jour où on l’a construit. Il dit combien est dû. Il dit rarement pourquoi un client paie en retard, qui doit l’appeler, ni si ce retard est nouveau. Et il arrive une fois par mois, quand un retard de trois semaines est déjà devenu un retard de sept.

Les questions qu’on se pose vraiment

Dans une direction financière, les questions sur les impayés ne sont jamais abstraites. Elles ressemblent à celles-ci :

• Quel est notre encours clients aujourd’hui, et quelle part est échue ?
• Comment évolue notre DSO depuis le début de l’année ?
• Quels clients ont des factures échues depuis plus de 60 jours, et qui est leur commercial ?
• Ce retard est-il un oubli, ou le signe d’un litige ?

Chacune croise au moins deux sources. La dernière, en particulier, ne se lit dans aucune table : elle demande de rapprocher une facture d’un échange avec le client.

Poser la question, en français

La contrôleuse de gestion de Nordica ouvre une conversation et écrit sa question comme elle la poserait à un collègue, sans connaître le nom des tables.

Avant de répondre, l’agent dit ce qu’il calcule : la période, le périmètre, le découpage retenu. Il s’appuie sur le contexte métier recueilli lors de la connexion de la base : ce que Nordica appelle une facture échue, la façon dont elle traite les avoirs, les conditions de paiement de chaque segment. Ce contexte n’est pas à réexpliquer à chaque question. Il a été construit une fois, avec l’équipe, et il sert à tout le monde.

Ce qu’il ne peut pas deviner, il le demande

En explorant la table des factures, l’agent remarque qu’une partie des factures échues porte le statut « litige ». Rien dans les données ne dit si elles doivent entrer dans l’échu à relancer. Plutôt que de trancher seul, il pose la question.

La réponse, les suivre à part, entre dans la mémoire partagée de l’espace de travail. La prochaine personne qui posera une question sur les impayés obtiendra le même périmètre, donc le même chiffre.

Un chiffre d’encours n’a de valeur que si toute l’équipe le calcule de la même façon. Le contexte métier sert d’abord à cela.

Lire l’échu par ancienneté

La réponse arrive avec les chiffres et le graphique. Sur un encours de 1,12 M€, 318 k€ sont échus. La moitié de ce retard a moins de trente jours et relève du suivi courant ; les 72 k€ qui dépassent soixante jours, en revanche, demandent qu’on s’en occupe.

Les chiffres ne viennent pas du modèle d’IA : ils sont calculés par la base de facturation elle-même, à partir de la requête que l’agent a écrite et qu’Azul a vérifiée avant de l’exécuter. Un analyste peut relire cette requête d’un clic. La question suivante vient alors naturellement : qui se cache derrière les retards les plus anciens ?

Croiser avec le CRM

C’est là que la base de facturation ne suffit plus. Les comptes, leurs commerciaux et l’historique des échanges vivent dans le CRM, que Nordica a branché à Azul par son API. L’agent interroge les deux sources dans la même conversation et rapproche leurs réponses.

La lecture change de nature. Atelier Brisson a déjà été relancé ; il faut attendre, ou escalader. Maison Castel et Tessier et Fils, en revanche, n’ont fait l’objet d’aucun échange récent, alors que leurs factures vieillissent. Quant à Norvia, son retard n’est pas un oubli : c’est un litige, et le relancer comme un mauvais payeur serait une erreur.

Agir dans le CRM

La contrôleuse de gestion demande la suite logique : une tâche de relance pour les deux comptes, assignée à leur commerciale, avec le détail des factures. L’agent la crée directement dans le CRM.

Cette action n’est possible que parce que Nordica a connecté son CRM et autorisé la création de tâches. Les outils que vous branchez et les actions que vous y permettez restent votre décision, et chaque action est inscrite au journal d’audit, avec la conversation dont elle vient. La base de facturation, elle, n’est jamais modifiée : Azul y lit les factures, il n’y écrit rien.

Ne plus avoir à vérifier

Une analyse ponctuelle ne fait pas un suivi. Les graphiques utiles, l’encours, l’échu par ancienneté, le DSO, sont épinglés sur un tableau de bord « Encours clients », rafraîchi chaque jour à 7 h. Chacun le lit avec les chiffres du matin, sans attendre la fin du mois.

Sur l’indicateur qui compte le plus, la direction financière va plus loin et pose une alerte : quand l’échu de plus de 60 jours d’un client dépasse 25 000 €, Azul prévient par e-mail la direction financière et le commercial du compte. L’alerte part au rafraîchissement qui constate le franchissement.

Le point figé pour le comité

Reste le comité de direction, qui n’a pas besoin d’un tableau qui bouge mais d’un état à une date. À partir de la même conversation, l’agent rédige un rapport dont les chiffres sont figés sur les exécutions à partir desquelles il a été écrit. C’est le document qu’on partage, et qu’on retrouvera tel quel au trimestre suivant pour comparer.

Ce qui change pour l’équipe

• Le suivi devient quotidien. L’encours se lit chaque matin, et plus seulement à la clôture.
• Le retard a un contexte. Le montant échu arrive avec le commercial, le dernier échange, l’éventuel litige : la relance part vers la bonne personne, avec le bon argument.
• Les mêmes règles pour tous. Litiges, avoirs, conditions de paiement : définis une fois, appliqués à chaque question.
• Une nouvelle question n’est plus un ticket. Elle se pose en français, sur les données du jour, par la personne qui en a besoin.

Par où commencer

Le plus simple est de partir d’une question qui compte aujourd’hui et qui n’a pas de réponse rapide : l’échu de plus de 60 jours par commercial, par exemple. Il suffit d’un accès en lecture seule à la base de facturation, ou d’un export si vous préférez commencer par un fichier. Le CRM se branche ensuite, avec les seules actions que vous choisissez d’autoriser.