Pourquoi les avoirs cassent la classification automatisée

Data QualityRae Thomas3 September 20268 min read

Réponse rapide : Les avoirs et régularisations se rattachent à un bon de commande mais corrigent, annulent ou remboursent généralement une autre ligne, antérieure : un retour, une correction de prix, une remise fournisseur. Un classificateur qui ne lit que la ligne devant lui n'a aucun moyen de voir cette ligne antérieure, il n'a donc aucune base fiable pour une catégorie. La solution pragmatique n'est pas un modèle plus intelligent. C'est d'acheminer ces lignes vers une file de révision humaine plutôt que de leur attribuer une catégorie assurée mais non vérifiée.

Sur cette page : Pourquoi les avoirs déroutent les classificateurs · Le contexte caché que la classification ne peut pas voir · Pourquoi deviner est pire que signaler · Comment fonctionne réellement la file de révision · FAQ

Pourquoi les avoirs déroutent les classificateurs

La plupart des problèmes de classification dans les données achats sont des problèmes de motif. Une description de ligne est désordonnée, abrégée ou incohérente entre sites et fournisseurs, mais la catégorie sous-jacente reste identifiable à partir du texte lui-même : un boulon M8 est un boulon M8 quelle que soit son orthographe. Les avoirs sont un problème d'une tout autre nature, et c'est venu directement sur la table lors d'une démonstration client cette semaine.

Un avoir ou une régularisation se rattache à un bon de commande de la même façon qu'une ligne de facture normale. Il a un numéro de bon de commande, un fournisseur, une valeur, parfois une description de ligne. Tout dans sa forme semble classifiable. Mais la valeur de cette ligne décrit rarement un achat. Elle décrit une correction à un achat survenu ailleurs, à un moment antérieur, souvent sur un bon de commande ou une ligne entièrement différents.

Un avoir de retour corrige la catégorie de l'achat d'origine. Une correction de prix reformule la valeur de marchandises déjà classifiées sous une autre ligne. Une remise n'est pas du tout un achat, c'est de l'argent qui revient contre toute une catégorie de dépenses passées, pas une transaction unique. Dans chacun de ces cas, la « vraie » catégorie à laquelle appartient l'avoir vit dans un enregistrement que le classificateur ne regarde pas.

Ce n'est pas une occurrence rare en marge d'un jeu de données. Partout où des factures sont contestées, retournées ou renégociées, ce qui est routinier dans les achats du hard FM, de la construction et de l'industrie, les avoirs et régularisations sont une caractéristique récurrente et structurelle des données, pas une exception ponctuelle.

Le contexte caché que la classification ne peut pas voir

La classification automatisée, à tous les niveaux de sophistication, des moteurs de règles au machine learning en passant par le rapprochement assisté par LLM, fonctionne à partir de ce qu'elle a sous les yeux : la description de la ligne, le fournisseur, le bon de commande, le code comptable, parfois une classification antérieure sur le même matériel. Tout cela est l'instantané d'une seule transaction.

Un avoir casse cette hypothèse d'instantané. Pour le classifier correctement, un système devrait identifier la facture ou la ligne de bon de commande d'origine à laquelle il se rapporte, confirmer que les deux sont effectivement liées (ce qui n'est pas toujours enregistré explicitement, en particulier sur des données ERP anciennes ou des exports partiels), puis hériter de la catégorie de cette ligne antérieure plutôt que d'en dériver une à partir du texte de l'avoir lui-même. C'est un problème de raisonnement inter-enregistrements, pas un problème de classification de texte, et la plupart des systèmes achats ne portent pas de lien propre et fiable entre un avoir et la facture qu'il corrige. La piste papier existe quelque part. Elle est rarement structurée d'une façon qu'un classificateur peut suivre automatiquement.

Même là où un lien existe dans les données, une remise complique encore les choses. Une remise sur volume ou un règlement de fin de trimestre d'un fournisseur ne corrige pas une ligne, elle se compense contre toute une catégorie de dépenses sur une période. Il n'y a même pas de « ligne d'origine » unique dont hériter une catégorie. La seule réponse honnête, en l'absence de contexte supplémentaire, est que la catégorie est réellement non résolue à partir des données disponibles.

Pourquoi deviner est pire que signaler

C'est là que la tentation de « simplement choisir la catégorie la plus proche » cause de véritables dégâts. Un classificateur sous pression pour atteindre un objectif de couverture peut attribuer un avoir à quelle que soit la catégorie vers laquelle son fournisseur ou son code comptable pointe le plus souvent. Cela produit un jeu de données assuré, d'apparence complète. Cela produit aussi un total de catégorie discrètement erroné, et personne en aval n'a de raison de le remettre en question, parce qu'une réponse assurée n'annonce pas sa propre incertitude.

C'est le problème central de traiter la classification par IA comme une boîte noire censée simplement fonctionner : une réponse assurée mais fausse coûte plus cher qu'une réponse visiblement incertaine, parce que la réponse fausse est adoptée avec confiance et sert de base à d'autres décisions. Un directeur financier réconciliant les dépenses par catégorie, un category manager rendant compte d'une relation fournisseur riche en remises, ou une équipe achats comparant les dépenses à l'année précédente, héritent tous de ce que le classificateur a décidé, silencieusement, sans aucun signalement attaché.

Signaler a aussi un coût : une personne doit passer une minute ou deux à résoudre la ligne. Mais ce coût est visible, borné, et ponctuel. Une classification silencieusement fausse se compose à chaque fois que quelqu'un exécute un rapport dessus, et elle est bien plus coûteuse à détecter et à défaire après coup qu'elle ne l'aurait été à réviser en amont.

Comment fonctionne réellement la file de révision

En pratique, la solution n'est pas une modélisation plus ingénieuse, c'est une file de révision qui capte précisément ce type de cas et l'achemine vers une personne avant qu'il n'atteigne un rapport. Chaque ligne reçoit un score de confiance fondé sur la mesure dans laquelle le contexte disponible étaye une catégorie. Les lignes ordinaires avec des descriptions claires et cohérentes obtiennent un score élevé et passent directement. Les avoirs, régularisations et remises obtiennent presque toujours un score bas, parce que le texte décrit une correction plutôt qu'un achat, et c'est le bon résultat, pas un échec du modèle.

Moins de 10 % des lignes atterrissent généralement dans la file de révision pour un travail de classification sur des données achats et actifs, pour des équipes qui ont besoin que chaque total de catégorie soit traçable jusqu'à une décision réelle plutôt qu'une supposition. Une personne ayant une visibilité sur le compte, pas seulement sur la ligne, résout l'avoir par rapport à la transaction d'origine à laquelle il appartient, et cette décision est réinjectée pour que les futurs avoirs du même fournisseur soient traités plus vite la prochaine fois.

La file n'est pas un contournement pour un modèle pas encore assez bon. À l'échelle du secteur, les taux d'exception de facture nécessitant un traitement manuel se situent dans une fourchette de 10 à 25 % même dans les systèmes de comptes fournisseurs automatisés, et les opérations les plus performantes acheminent encore une part significative des exceptions vers une personne plutôt que de forcer un rapprochement automatique. Une file de révision construite autour des cas réellement ambigus, les avoirs en tête, est la réponse pragmatique qu'exigent réellement la vitesse et la fiabilité. Un modèle élégant qui devine est pire qu'un modèle simple qui sait ce qu'il ne sait pas.

Questions fréquentes

Pourquoi les credit notes sont-elles mal classifiées par les systèmes de classification automatisés ?

Une credit note corrige, annule ou accorde généralement une remise sur une transaction antérieure distincte, plutôt que de décrire un achat en tant que tel. Les classificateurs automatisés lisent la description de la ligne et le contexte du PO qui leur est présenté, et ce contexte décrit la correction, pas la catégorie d'achat d'origine. Sans lien fiable vers la ligne antérieure, le système n'a aucune base solide pour attribuer une catégorie, et deviner produit alors un résultat non vérifié.

Quelle est la différence entre une credit note et un adjustment dans les données de procurement ?

Une credit note réduit ou annule formellement la valeur d'une invoice antérieure, généralement pour un retour, une surfacturation, ou une remise contractuelle. Un adjustment est un terme plus large, couvrant toute correction apportée à une transaction précédemment enregistrée, y compris les corrections de prix, les corrections de quantité et les reclassifications. Les deux partagent le même problème de fond : aucun des deux ne peut être classifié correctement sans l'enregistrement auquel il se rapporte.

Pourquoi une classification erronée mais présentée avec confiance est-elle pire qu'une classification signalée ?

Une classification erronée mais présentée avec confiance s'intègre dans les rapports de spend et les totaux par catégorie en paraissant vérifiée, et personne ne remet en question des chiffres qui semblent déjà complets. Une ligne signalée reste visible jusqu'à ce qu'une personne la résolve, ce qui empêche l'erreur de s'accumuler silencieusement dans un total de catégorie erroné ou un calcul de remise trompeur. Être visiblement incertain coûte quelques minutes de revue. Être invisiblement faux coûte bien plus cher une fois que des décisions s'appuient dessus.

Comment Pearstop gère-t-il les credit notes et les autres lignes ambiguës lors de la classification ?

Pearstop attribue à chaque ligne un score de confiance de classification et achemine tout ce qui se situe en dessous du seuil, y compris les credit notes et les adjustments faisant référence à une autre transaction, vers une file de revue humaine plutôt que de leur attribuer une catégorie devinée. Généralement, moins de 10 % des lignes nécessitent cette étape. Chaque décision de revue alimente en retour le modèle, de sorte que les credit notes récurrentes d'un même fournisseur soient résolues plus rapidement lors de l'exécution suivante.

La classification automatisée peut-elle un jour résoudre entièrement les credit notes sans intervention humaine ?

Pas de manière fiable, car l'information nécessaire se trouve dans une transaction différente de celle en cours de classification, et la reconnaissance de motifs textuels ne peut combler cet écart à elle seule. La récupérer automatiquement nécessiterait un lien propre et explicite entre chaque credit note et l'invoice qu'elle corrige, ce que la plupart des systèmes de procurement et ERP ne maintiennent pas. Tant que ce lien n'existe pas, l'acheminement vers une revue reste l'approche la plus sûre.

Les credit notes et les adjustments affectent-ils les chiffres de précision de classification communiqués ?

Oui, et c'est précisément pour cela qu'ils doivent être comptabilisés plutôt qu'exclus. Un chiffre de précision de classification qui exclut discrètement les lignes contestées, annulées ou faisant l'objet d'une remise surestime la fiabilité réelle de la catégorisation. Comptabiliser les credit notes et les adjustments dans la même mesure de précision, et acheminer les cas réellement ambigus vers une revue, permet de conserver un chiffre de précision honnête plutôt que gonflé par omission.

Rae Thomas

Director of Operations, Pearstop

Rae heads up operations at Pearstop, in both the traditional and non-traditional sense. She's as committed to the internal success of the business as she is to the value clients get out of it, which is why she leads delivery on most projects and is the main point of contact for clients throughout.

LinkedIn →