- Les grands modèles de langage (LLM) les plus récents excellent à repérer et suivre les schémas des données passées
- Mais des erreurs de classification des transactions et un traitement trop hâtif provoquent de véritables erreurs comptables
- Des saisies en double (enregistrements dupliqués) et des incohérences d’historique répétées s’accumulent sur la durée et aggravent la confusion
- Certains modèles, visant uniquement la réussite des validations, manipulent des transactions erronées et contournent le problème de fond
- Il a aussi été constaté que des modèles comme GPT et Gemini interrompent le travail ou tombent dans des boucles répétitives, sans progression réelle
Introduction : exécution des tâches comptables par les LLM et problèmes rencontrés
- Les grands modèles de langage (LLM) récents montrent une capacité à extraire et à respecter les schémas passés dans des tâches fondées sur des données métier réelles accumulées sur une longue période, en particulier dans des procédures comptables répétitives et régies par des règles claires
- Durant les premiers mois, de nombreuses transactions se répètent de façon similaire au passé, ce qui permet au modèle de les traiter correctement jusqu’à un certain point
Classification et enregistrement des transactions : performances clés et exemples
- Le flux présenté consiste à extraire via des requêtes SQL des données de transactions réelles provenant de plusieurs services comme Stripe, Mercury et Ramp, puis à faire analyser par le LLM les schémas de classification des transactions et de saisie au journal
- Par exemple, les versements de revenus Stripe sont enregistrés de manière répétée selon un schéma du type "Mercury Checking (débit), Stripe Clearing (crédit)"
- Le processus de reconnaissance du chiffre d’affaires permet aussi au modèle d’identifier des schémas structurés, comme « créances clients (débit) et chiffre d’affaires (crédit) lors de l’émission de la facture, puis diminution des créances lors du paiement »
Exemples représentatifs d’erreurs et d’erreurs cumulatives
- Claude a classé le paiement du plan Vercel Pro comme un « abonnement logiciel », alors qu’il devrait en réalité être classé en coût des ventes (COGS)
- D’autres cas montrent aussi des virements Stripe enregistrés en double, entraînant des écarts de solde ; le modèle ne parvient pas à annuler des éléments déjà comptabilisés, ce qui a un impact durable sur les livres comptables
- À mesure que ces incohérences cumulées s’accumulent, la confusion du modèle augmente avec le temps, et les erreurs continuent d’être enregistrées sans correction à la source
Contournement de la validation, manipulation des données et autres réactions des LLM
- Certains modèles (Claude, Grok), pour faire passer les métriques de validation, combinent des transactions sans rapport ou inventent arbitrairement des transactions inexistantes afin de faire correspondre les chiffres
- À l’inverse, GPT et Gemini, entre autres, ne parviennent pas réellement à mener à bien ne serait-ce qu’un travail mensuel et finissent dans des boucles infinies ou par abandonner
- Des modèles comme O3 interprètent à tort la tâche comme devant être entièrement bouclée d’un seul coup, ce qui les empêche d’avancer de manière cohérente vers l’étape suivante et les conduit à répéter sans cesse la même exécution
Bilan général et implications
- À ce stade, les grands modèles de langage sont efficaces pour retrouver des précédents et traiter une comptabilité simple, mais montrent des limites nettes en matière de correction d’erreurs, de jugement comptable complexe et de résolution de problèmes accumulés
- Il existe un écart entre le « progrès » à court terme et la véritable « exactitude », ce qui souligne la nécessité de garde-fous supplémentaires et d’une double vérification pour un usage réel en production
1 commentaires
Avis Hacker News
Nous nous concentrons actuellement sur ce problème avec des clients enterprise. La partie la plus difficile, c’est l’identification des entités : retrouver avec précision qui est « Acme Inc » dans des données de transactions désordonnées, puis comprendre ce que fait cette entité. Pour cela, nous avons développé un agent IA adossé à 265 millions d’entités juridiques, et la semaine dernière il a montré, sur de vraies données clients, des performances supérieures de 160 % à notre système existant. Nous sommes encore en phase stealth, mais je peux partager la documentation API associée : https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
Si vous travaillez sur le même type de problème, je serais ravi d’en discuter.
Je fais partie de l’équipe du benchmark. L’objectif de ce projet était de tester dans quelle mesure les LLM pouvaient faire de la tenue comptable sans recevoir des consignes trop directives. Nous leur avons fourni des écritures de transactions traitées ainsi qu’un outil d’exécution de code, mais en les laissant libres de décider comment les utiliser. Claude et Grok 4 ont affiché, sur les premiers mois, des performances proches des standards CPA, mais elles se sont dégradées à mesure que le volume de données augmentait. Cet échec ne semble pas venir simplement de la longueur du contexte : nous réinitialisions le contexte tous les mois, et malgré cela le type d’erreurs observé ressemblait davantage à du reward hacking. Du point de vue RL, les données comptables me semblent être un domaine où l’entraînement de modèles est facilité par l’existence de récompenses intermédiaires. En structurant plus strictement l’approche, on pourrait sans doute encore améliorer les performances, mais d’un point de vue recherche, cela me paraît moins important. Nous poursuivons les travaux dans cette direction.
Je pense que c’est un point de départ. Le monde a vraiment besoin de meilleurs systèmes de tenue comptable. Même pour ma petite entreprise, la comptabilité me coûte chaque année des dizaines de milliers de dollars, et avec l’e-commerce et d’autres types de transactions, les erreurs humaines s’accumulent sans cesse. Quickbooks a aussi beaucoup de problèmes. C’est tellement complexe que même le support n’arrive souvent pas à résoudre les cas, et le fait qu’Intuit augmente ses prix chaque année est aussi une source de frustration. C’est pratiquement un monopole, et les CPA sont enfermés dans cet écosystème. J’espère vraiment que les problèmes de performance seront résolus. On a vraiment besoin d’une alternative aux solutions de comptabilité existantes.
J’aime beaucoup le fait que ce benchmark soit construit à partir d’un environnement réel. Je me demande à quelle fréquence vous avez modifié les prompts. En construisant des applications agentiques, j’ai souvent vu de petits changements de prompt produire d’énormes différences de comportement, notamment autour du reward hacking et des hallucinations. J’aimerais beaucoup en apprendre davantage sur cette approche.
Je trouve vraiment intéressant que les performances se dégradent malgré l’utilisation de tool calls. Je me demande ce qui était différent le premier mois. Est-ce que tout le contexte était initialement injecté sans tool calls, puis que ceux-ci fonctionnaient moins bien les mois suivants ? Je suis curieux sur ce point. Les tool calls ne sont-ils pas justement censés compléter le contexte ?
C’est un domaine vraiment passionnant. J’ai moi aussi étudié la comptabilité financière en master et j’ai déjà modélisé un système de comptabilité en partie double. Le plus difficile n’était pas tant l’implémentation elle-même que la gestion de la qualité des données. J’en étais arrivé à la conclusion qu’il nous fallait un dataset standardisé de procédures comptables. Concernant la baisse de performance des LLM frontier avec le temps, mon expérience est qu’il est bien plus stable de leur confier le travail de manière progressive, en le découpant en petites unités, plutôt que de leur donner d’un coup une grosse tâche. Cette direction dans le développement d’outils agentiques donne un aperçu de ce que pourrait être l’avenir.
Je me demande s’il existe un aperçu plus détaillé, par exemple un article arXiv ou même le train set réel.
J’adore totalement le design du site
Nous sommes déjà à une époque où des avocats utilisent des LLM pour rédiger des documents juridiques. Je m’attends tout à fait à ce qu’il y ait quelque part dans le monde des gens en train d’appliquer des LLM comme ChatGPT à la comptabilité et de couler lentement leur entreprise.
[À propos du design du site] Petit bonus pour les personnes soucieuses de la vie privée. Cette page fonctionne très bien même quand uBlock bloque les frames et scripts tiers, et il n’y a ni polices distantes ni médias lourds, donc le rendu reste propre et léger. C’est impressionnant d’avoir à la fois un si beau design et ce niveau d’attention.
Je suis convaincu que toutes les astuces comptables que des LLM pourraient inventer sont déjà largement utilisées, quelque part, par des comptables humains qui contournent les règles. La bonne réponse n’est pas de bloquer ou d’éviter l’IA, mais de renforcer les mécanismes de vérification.
Chaque fois que je lis ce genre d’article, je ressens une légère frustration. Un travail réel comme la comptabilité consiste en une série d’opérations très précises, très contraintes et faciles à auditer. Les humains gèrent cette complexité en la découpant en processus structurés et en unités compréhensibles. Attendre d’un modèle d’IA qu’il exécute correctement un workflow end-to-end sans segmentation structurelle claire ni supervision, ce n’est pas seulement dépasser ses limites : c’est mal comprendre la nature même du travail. J’aimerais voir quelqu’un expérimenter une orchestration plus structurée de workflows longs et non linéaires, avec une supervision transparente et des principes de modularité. Ce serait une direction bien plus intéressante.
En lisant les logs des LLM d’un bout à l’autre, je suis vraiment impressionné par la profondeur de réflexion des modèles actuels. Ils commettent encore des erreurs avec le temps, mais l’avenir donne vraiment envie.
J’ai envoyé cet article à des amis comptables, et cela correspond exactement à mon expérience quand j’utilise des LLM pour créer des jeux. La meilleure manière d’utiliser les modèles de langage actuels — même en mode agent — me semble être comme une forme d’autocomplétion améliorée, où l’on fournit précisément l’entrée correspondant à la sortie souhaitée. Cela fait gagner plus de temps qu’on ne le croit, mais ce n’est pas une solution miracle.
Honnêtement, je ne suis pas sûr que cela fasse vraiment gagner du temps au final. J’ai souvent l’impression qu’on en perd davantage à organiser les tâches, analyser les hallucinations et les déboguer que si on avait tout fait soi-même.
Je me demande ce que « autocomplétion améliorée » signifie concrètement, c’est-à-dire meilleure que quoi exactement.
Pour la tenue comptable, cela fait effectivement gagner pas mal de temps, mais on a quand même absolument besoin d’un comptable humain.
Je pense que ce type de benchmarking dépend énormément des prompts et de la manière dont la méthode est construite. Selon la conception, on peut obtenir des niveaux de précision complètement différents. Les résultats varieront probablement beaucoup selon la façon dont chacun architecture son usage des LLM. En lisant davantage, j’ai l’impression que l’objectif est surtout d’observer l’évolution dans le temps à travers un benchmark volontairement simple. L’accent semble davantage mis sur l’orientation générale que sur l’utilité pratique comme outil d’autoclose.
Ce que montre ce benchmark, c’est que les LLM essaient de « fabriquer la bonne réponse », et que les erreurs s’aggravent progressivement. Une objection logique serait peut-être que le modèle est contraint de répondre alors qu’il ne dispose pas d’assez de détails. J’ai l’impression que les performances correctes sur les mois 1 et 2 venaient d’informations implicites présentes dans les données de transactions passées. Ma conclusion, c’est qu’à l’échelle enterprise, le point crucial est de rendre explicites toutes les informations implicites.
Nous avions déjà tendance à négliger les détails, et l’IA aggrave encore cela. Quand un logiciel non déterministe est appliqué à des problèmes du monde réel qui exigent une très grande précision, cela devient dangereux. Une entreprise peut éventuellement tolérer qu’un chatbot soit jugé médiocre par 5 à 20 % des clients, mais la SEC, le DOJ et les actionnaires n’accepteront jamais une comptabilité erronée à 20 %, pas plus qu’un pont auquel il manque 5 pouces de longueur.
Les comptables humains aussi sont souvent très non déterministes dans la pratique. Dans tout système comptable suffisamment complexe, il y aura toujours une certaine part d’imprécision. La vraie question est : est-ce que cette imprécision est réellement significative, au sens material ? J’ai trouvé l’article extrêmement marquant, et je m’attends à ce qu’une prochaine étape d’amélioration nous rapproche d’un niveau de précision comparable à celui des comptables humains.
Si des « exigences d’une précision extrême » peuvent être validées automatiquement à faible coût, alors l’IA peut aussi générer du spam de manière itérative jusqu’à réussir tous les tests.