Pourquoi les avoirs cassent la classification automatisée

Data Quality3 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.

Frequently asked questions

Why do credit notes get misclassified by automated classification systems?

A credit note usually corrects, reverses, or rebates a different, earlier transaction rather than describing a purchase in its own right. Automated classifiers read the line description and PO context in front of them, and that context describes the correction, not the original purchase category. Without a reliable link to the earlier line, the system has no sound basis for assigning a category, so guessing produces an unverified result.

What is the difference between a credit note and an adjustment in procurement data?

A credit note formally reduces or reverses the value of an earlier invoice, typically for a return, an overcharge, or a contractual rebate. An adjustment is the broader term, covering any correction to a previously recorded transaction, including price corrections, quantity corrections, and reclassifications. Both share the same underlying problem: neither can be classified correctly without the record it refers back to.

Why is a confidently wrong classification worse than a flagged one?

A confidently wrong classification enters spend reports and category totals looking verified, and nobody questions numbers that already appear complete. A flagged line stays visible until a person resolves it, so the error cannot silently compound into a wrong category total or a misleading rebate calculation. Being visibly uncertain costs a few minutes of review. Being invisibly wrong costs far more once decisions are built on it.

How does Pearstop handle credit notes and other ambiguous lines during classification?

Pearstop scores every line for classification confidence and routes anything below the threshold, including credit notes and adjustments that reference a different transaction, to a human review queue rather than assigning a guessed category. Typically under 10 percent of lines need this step. Every review decision feeds back into the model, so the same supplier's recurring credit notes get resolved faster on the next run.

Can automated classification ever fully resolve credit notes without a person involved?

Not reliably, because the information needed sits in a different transaction than the one being classified, and text pattern matching cannot bridge that gap on its own. Recovering it automatically would require a clean, explicit link between every credit note and the invoice it corrects, which most procurement and ERP systems do not maintain. Until that link exists, routing to review is the sounder approach.

Do credit notes and adjustments affect reported classification accuracy figures?

Yes, and that is exactly why they should be counted rather than excluded. A classification accuracy figure that quietly leaves out contested, reversed, or rebated lines overstates how reliable the categorisation actually is. Counting credit notes and adjustments within the same accuracy measure, and routing the genuinely ambiguous ones to review, keeps a reported accuracy figure honest instead of inflated by 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 →