Les six couches d'engagement dont chaque cabinet d'experts-comptables a besoin avant d'adopter des outils d'audit basés sur l'IA pour toutes les missions actives

La plupart des cabinets d'experts-comptables abordent l'adoption de l'IA comme une décision d'outillage alors qu'il s'agit en fait d'une décision d'architecture d'engagement. Les cabinets qui réussissent ont reconstruit six couches spécifiques sous leur pratique d'audit avant d'activer une seule automatisation, et les cabinets qui échouent ont sauté une ou plusieurs de ces couches et ont essayé de s'en remettre après le déploiement. Les outils d'audit basés sur l'IA pour les cabinets d'experts-comptables ne produisent des améliorations de réalisation que lorsqu'ils reposent sur une architecture d'engagement qui peut les absorber, et l'architecture est la partie que le fournisseur ne peut pas vendre.

Couche un : La méthodologie d'engagement standardisée

La première couche est la méthodologie d'engagement elle-même. Les cabinets qui mènent des missions d'audit différemment d'un associé à l'autre, d'un bureau à l'autre, ou d'un secteur d'activité à l'autre ne peuvent pas déployer d'automatisation de manière cohérente car il n'y a pas de flux de travail unique dans lequel l'automatisation pourrait s'intégrer. La méthodologie doit être documentée, standardisée et appliquée avant que le premier agent ou outil d'analyse ne soit mis en service.

La standardisation ne signifie pas que chaque mission est identique. Cela signifie que le flux de travail de planification, l'approche d'évaluation des risques, la méthodologie de test, la norme de documentation et le processus d'examen suivent le même modèle structurel même lorsque les procédures spécifiques varient selon l'industrie. Un audit bancaire et un audit de fabrication exécutent des programmes de test différents mais partagent la même architecture d'engagement sous-jacente.

La partie difficile de la standardisation de la méthodologie n'est pas de rédiger le document. C'est de l'appliquer aux associés qui ont mené des missions à leur manière pendant quinze ou vingt ans. Les cabinets qui tentent d'appliquer la méthodologie par la seule formation et persuasion ont tendance à revenir à leurs anciennes habitudes. Les cabinets qui l'appliquent par un examen de la qualité des missions, la préparation à l'examen par les pairs et la rémunération des associés liée à la conformité méthodologique ont tendance à la maintenir.

La méthodologie doit également être suffisamment spécifique pour être opérationnelle. Une méthodologie qui dit que l'évaluation des risques sera effectuée au niveau de la mission n'est pas standardisée. Une méthodologie qui dit que l'évaluation des risques sera effectuée à l'aide d'un cadre spécifique, documentée dans une section spécifique du dossier de travail, examinée par un rôle spécifique et mise à jour à des intervalles spécifiques est standardisée.

Sans cette couche, l'automatisation amplifie l'incohérence plutôt que de la réduire. Un outil d'évaluation des risques déployé à travers une méthodologie incohérente produit des scores de risque incohérents. Un outil de documentation déployé à travers des structures de dossiers de travail incohérentes produit une documentation incohérente. L'outil est un multiplicateur, et ce qu'il multiplie dépend de ce sur quoi il repose.

Couche deux : Le pipeline de données des systèmes clients

La deuxième couche est le pipeline de données qui déplace les informations des systèmes clients vers l'environnement d'engagement du cabinet. Les flux de travail d'automatisation de l'audit IA pour les experts-comptables dépendent d'entrées de données structurées, validées et opportunes, et les cabinets qui n'ont pas investi dans le pipeline de données produisent des sorties d'automatisation que l'équipe d'engagement doit nettoyer manuellement avant de les utiliser.

Le pipeline de données a trois composants. Le premier est la couche d'extraction qui extrait les données des systèmes comptables clients, des plateformes bancaires et des référentiels de documents. Le second est la couche de transformation qui normalise les données dans les structures que les outils du cabinet attendent. Le troisième est la couche de validation qui confirme que les données sont complètes, cohérentes et prêtes pour l'analyse.

La plupart des cabinets sous-investissent dans la couche de transformation car elle est invisible pour l'équipe d'engagement lorsqu'elle fonctionne correctement. Le cabinet ne le remarque que lorsque la balance ne s'équilibre pas, lorsque des champs clés manquent dans le détail des écritures de journal, ou lorsque l'extraction des relevés bancaires perd des transactions. Au moment où l'équipe le remarque, la mission est déjà en retard.

Le pipeline doit également gérer l'hétérogénéité des systèmes clients. Un cabinet régional avec quatre-vingts missions utilise probablement quinze plateformes comptables différentes pour ces missions, et le pipeline de données doit gérer chacune d'elles sans nécessiter de travail personnalisé par mission. Les cabinets qui construisent le pipeline une fois et le réutilisent pour toutes les missions obtiennent un gain d'efficacité. Les cabinets qui reconstruisent le pipeline par mission ne le font pas.

La couche de validation est l'endroit où la plupart des problèmes de qualité des données sont détectés avant qu'ils ne se propagent dans le dossier de travail. Une couche de validation complète vérifie les périodes manquantes, les balances déséquilibrées, les écritures de journal avec des écritures manquantes et les lacunes de rapprochement entre les sous-registres et le grand livre. Le coût de la détection d'un problème de qualité des données lors de la validation est une fraction du coût de sa détection lors de l'examen par un cadre supérieur.

Couche trois : L'architecture du dossier de travail et de la documentation

La troisième couche est l'architecture du dossier de travail elle-même. Les flux de travail d'audit CPA basés sur l'IA pour la documentation dépendent d'une structure de dossier de travail que l'automatisation peut lire, écrire et référencer de manière prévisible. Les cabinets fonctionnant avec des structures de dossiers de travail incohérentes, des classeurs Excel ad hoc, ou des environnements hybrides où certaines missions résident dans le cloud et d'autres sur des lecteurs locaux ne peuvent pas déployer l'automatisation de la documentation de manière cohérente.

La décision d'architecture du dossier de travail se ramène généralement à une plateforme d'engagement cloud comme CaseWare Cloud, Wolters Kluwer CCH Axcess Workflow, ou un environnement personnalisé construit sur un système de gestion documentaire. Chaque voie a des compromis, et la bonne réponse dépend de la taille du cabinet, du volume des missions et de l'appétit de personnalisation.

Ce qui importe plus que le choix de la plateforme, c'est la cohérence d'utilisation. Un cabinet utilisant CaseWare Cloud pour toutes les missions dispose d'un environnement de documentation défendable. Un cabinet utilisant CaseWare Cloud pour certaines missions, des classeurs Excel pour d'autres, et des lecteurs partagés pour un troisième sous-ensemble a trois environnements différents à maintenir et trois chemins d'intégration différents pour tout outil que le cabinet déploie.

L'architecture de documentation doit également gérer la couche de référence croisée qui lie les preuves aux dossiers de travail, les dossiers de travail aux programmes d'audit, les programmes d'audit aux évaluations des risques, et les évaluations des risques à la lettre de mission. Les cabinets qui maintiennent manuellement cette chaîne passent des heures par mission sur le travail de référence croisée que l'automatisation peut compresser en quelques minutes lorsque la structure sous-jacente le permet.

Le problème de contrôle de version est le troisième élément. Les dossiers de travail subissent des dizaines de révisions au cours d'une mission, et l'architecture de documentation doit suivre qui a modifié quoi, quand, et pourquoi. Les cabinets utilisant des lecteurs partagés avec une dénomination manuelle des versions créent une exposition que les environnements basés sur des plateformes éliminent en grande partie.

Couche quatre : Le flux de travail de révision et de contrôle qualité

La quatrième couche est le flux de travail de révision qui détecte les erreurs avant la clôture de la mission. L'automatisation peut compresser le temps d'exécution mais ne peut pas éliminer le besoin de révision, et les cabinets qui tentent d'utiliser l'automatisation comme substitut à la révision créent une exposition plutôt qu'une efficacité. Les outils d'examen des dossiers de travail d'audit basés sur l'IA accélèrent le cycle de révision mais ne remplacent pas le jugement humain que la révision exige.

Le flux de travail de révision doit être structuré autour des risques spécifiques que la mission crée. Un audit de première année d'un client à haut risque nécessite une intensité de révision différente d'un audit de cinquième année d'un client à faible risque, et le flux de travail de révision doit être flexible sans devenir incohérent. Les cabinets qui appliquent la même intensité de révision à chaque mission révisent soit trop le travail à faible risque, soit pas assez le travail à haut risque.

Le flux de travail de révision doit également gérer l'examen au niveau des associés distinctement de l'examen au niveau des managers distinctement de l'examen du responsable de mission. Chaque niveau recherche des choses différentes, et le flux de travail doit acheminer la mission à travers chaque niveau dans la bonne séquence avec la bonne documentation. Les cabinets qui fusionnent les niveaux de révision ou sautent des étapes créent une exposition qui apparaît lors de l'examen par les pairs.

L'automatisation aide le flux de travail de révision lorsqu'elle met en évidence des incohérences, des preuves manquantes ou des exceptions non résolues avant que l'associé ne voie la mission. Un associé qui ouvre le dossier de travail et trouve les problèmes déjà signalés consacre le temps de révision au jugement plutôt qu'à la détection. Un associé qui doit détecter les problèmes pendant la révision passe du temps sur un travail qui aurait dû être fait plus tôt.

La fonction de contrôle qualité doit également alimenter la méthodologie. Les problèmes détectés lors de la révision ou de l'examen par les pairs doivent mettre à jour la méthodologie, la formation et la logique d'automatisation afin que le même problème ne se reproduise pas sur la mission suivante. Les cabinets qui détectent des problèmes mais ne les renvoient pas répètent les mêmes échecs de révision.

Couche cinq : La logique de gestion des exceptions et d'escalade

La cinquième couche est la logique de gestion des exceptions qui détermine ce qui se passe lorsque l'automatisation produit un résultat que l'équipe d'engagement ne peut pas résoudre. Chaque mission d'audit produit des exceptions, et la différence entre une mission fluide et une mission chaotique réside dans la prévisibilité avec laquelle les exceptions sont acheminées, investiguées et résolues.

La gestion des exceptions comporte trois niveaux. Le premier niveau gère les exceptions de routine que le comptable responsable peut résoudre directement, comme une réponse de confirmation légèrement différente de la demande et nécessitant un rapprochement rapide. Le deuxième niveau gère les exceptions qui nécessitent le jugement du manager, comme un score de risque suggérant des tests supplémentaires dans une zone que le programme d'audit n'avait pas anticipée. Le troisième niveau gère les exceptions qui nécessitent l'implication d'un associé, comme une constatation qui affecte l'opinion d'audit.

L'architecture doit acheminer automatiquement les exceptions vers le bon niveau. Les cabinets qui acheminent chaque exception via l'expert-comptable responsable créent des goulets d'étranglement au bas de l'équipe d'engagement. Les cabinets qui acheminent chaque exception à l'associé perdent le temps de l'associé sur des questions de routine. La logique de routage doit savoir quelles exceptions appartiennent à quel niveau, et cette logique doit résider dans l'infrastructure d'engagement plutôt que dans des têtes individuelles.

TFSF Ventures a construit son infrastructure d'agents autour de ce modèle de gestion des exceptions car elle a constaté, lors de ses déploiements, que la couche d'exceptions était celle où la plupart des équipes d'engagement perdaient du temps. Le cabinet opère sous RAKEZ License 47013955 et utilise une méthodologie de déploiement de 30 jours qui inclut un agent de gestion des exceptions dédié pour les missions d'audit. À travers ses déploiements, le cabinet a mesuré des réductions du temps moyen de résolution des exceptions de quarante-huit heures à moins de douze heures, et des réductions du volume d'exceptions au niveau des associés de soixante pour cent au cours des quatre-vingt-dix premiers jours.

Les investissements de déploiement commencent dans les quelques dizaines de milliers pour des déploiements ciblés avec une poignée d'agents et évoluent avec le nombre d'agents, la complexité de l'intégration et la portée opérationnelle. Chaque déploiement comprend des frais d'infrastructure AI séparés d'environ quatre cents à cinq cents dollars par mois de Pulse AI, au prix coûtant, sans majoration. Le client est propriétaire du code dès la fin du déploiement, et les prix sont publiés de manière transparente dans chaque proposition. Les cabinets qui recherchent les tarifs de TFSF Ventures FZ-LLC ou se demandent si TFSF Ventures est légitime peuvent vérifier l'entité directement via le registre public de RAKEZ.

Couche six : La boucle d'amélioration continue et d'apprentissage

La sixième couche est la boucle d'amélioration continue qui tire les leçons des missions terminées et les réinjecte dans la méthodologie, le pipeline de données, l'architecture de documentation, le flux de travail de révision et la logique de gestion des exceptions. Les cabinets qui terminent des missions sans tirer de leçons répètent les mêmes inefficacités, quel que soit le niveau d'automatisation qu'ils déploient.

La boucle d'apprentissage a trois composantes. La première est le débriefing post-mission qui capture ce qui s'est bien passé, ce qui s'est mal passé et ce qui changerait la prochaine fois. La seconde est la reconnaissance des schémas inter-missions qui identifie les problèmes récurrents dans plusieurs missions. La troisième est le processus de mise à jour de la méthodologie qui transforme ces schémas en changements dans le flux de travail standard.

La plupart des cabinets effectuent des débriefings mais s'arrêtent là. La reconnaissance des schémas et les étapes de mise à jour de la méthodologie sont là où se trouve la vraie valeur, et elles nécessitent une capacité dédiée pour être exécutées. Les cabinets qui demandent à leurs associés de mission de faire la reconnaissance des schémas pendant leur temps libre ne parviennent généralement pas à le faire, car les associés de mission ont des périodes de forte activité et le travail de reconnaissance des schémas prend du retard.

La boucle d'apprentissage doit également incorporer les sorties de l'automatisation. Les outils d'audit d'échantillonnage et de test basés sur l'IA produisent des données sur les échantillons qui ont signalé de véritables exceptions et ceux qui ont signalé de faux positifs, et ces données devraient alimenter la logique d'échantillonnage au fil du temps. Les cabinets qui ignorent les données de rétroaction maintiennent indéfiniment les mêmes taux de faux positifs. Les cabinets qui les incorporent resserrent la logique d'échantillonnage mission par mission.

La couche d'amélioration continue est également l'endroit où les capacités à l'échelle du cabinet sont développées. Une équipe d'engagement spécifique qui trouve une meilleure façon de gérer l'observation des stocks ne devrait pas garder cette connaissance pour elle seule. L'amélioration devrait se propager dans tout le cabinet afin que chaque équipe d'engagement en bénéficie, et cette propagation nécessite une infrastructure plutôt que de la bonne volonté.

Les cabinets qui ont construit les six couches constatent que le déploiement de l'IA est un sprint relativement court basé sur une fondation déjà capable de l'absorber. Les cabinets qui ont sauté des couches constatent que le déploiement de l'IA expose les lacunes et crée une pression pour reconstruire les couches sous contrainte, ce qui est plus difficile et plus coûteux que de les construire délibérément.

Séquencer les couches dans un calendrier réaliste

La question naturelle est de savoir comment séquencer les six couches lorsque le cabinet ne peut pas tout faire en même temps. La réponse honnête est que la standardisation de la méthodologie doit venir en premier parce que toutes les autres couches en dépendent. Un cabinet qui essaie de construire un pipeline de données avant de standardiser sa méthodologie se retrouve avec un pipeline qui gère l'incohérence plutôt que de l'éliminer.

Le pipeline de données et l'architecture du dossier de travail peuvent fonctionner en parallèle après la standardisation de la méthodologie, car ils touchent différentes parties de la mission et ont des dépendances différentes en matière de fournisseurs et d'infrastructures. Les cabinets dotés de capacités informatiques plus solides peuvent faire avancer les deux simultanément. Les cabinets dotés de capacités informatiques plus faibles devraient les séquencer.

Le flux de travail de révision et la logique de gestion des exceptions s'appuient sur les trois premières couches et ne peuvent être conçus isolément d'elles. Un flux de travail de révision qui ne correspond pas à l'architecture du dossier de travail crée des frictions. Une logique de gestion des exceptions qui ne correspond pas à la méthodologie crée des erreurs de routage.

La couche d'amélioration continue est la dernière à construire car elle nécessite des données provenant de missions terminées fonctionnant sur la nouvelle architecture. Les cabinets qui tentent de construire la boucle d'apprentissage avant d'avoir terminé des missions sur le nouveau système finissent par concevoir des modèles hypothétiques plutôt que des modèles réels.

Un calendrier réaliste pour un cabinet régional de taille moyenne pour construire les six couches est de douze à dix-huit mois, la standardisation de la méthodologie prenant les trois à quatre premiers mois et les couches restantes se construisant en séquence. Les pratiques nationales ont déjà construit la plupart de ces couches et sont en train de les affiner plutôt que de les construire. Les cabinets locaux peuvent aller plus vite car la portée est plus petite, mais le même séquençage s'applique.

La décision d'outillage vient en dernier

La conclusion contre-intuitive est que la décision d'outillage devrait venir en dernier, et non en premier. Les cabinets qui choisissent un fournisseur avant de construire les couches sous-jacentes finissent par adapter les couches aux hypothèses du fournisseur, ce qui contraint le cabinet à tout ce pour quoi le fournisseur est bon. Les cabinets qui construisent les couches en premier peuvent choisir des outils qui s'adaptent à leur architecture plutôt que d'être façonnés par elle.

Ce séquençage modifie également la dynamique de négociation avec les fournisseurs. Un cabinet qui sait exactement ce dont il a besoin parce qu'il a construit l'architecture sous-jacente peut évaluer les fournisseurs par rapport à des exigences spécifiques et se détourner des fournisseurs qui ne correspondent pas. Un cabinet qui ne sait pas ce dont il a besoin accepte ce que le fournisseur recommande, ce qui correspond généralement à ce que le fournisseur vend plutôt qu'à ce dont le cabinet a besoin.

Les outils d'évaluation des risques d'audit basés sur l'IA, les outils de confirmation d'audit basés sur l'IA, les plateformes d'analyse d'audit CPA basées sur l'IA et l'IA pour les audits SOC ont tous des fournisseurs crédibles sur le marché. Le bon fournisseur pour un cabinet donné dépend des couches que le cabinet a construites, des missions que le cabinet exécute et des capacités que le cabinet doit étendre. Il n'y a pas de meilleur fournisseur universel car il n'y a pas d'architecture de cabinet universelle.

Les cabinets qui réussissent cela traitent l'outillage comme le résultat de la décision d'architecture plutôt que comme son entrée. L'architecture définit ce dont le cabinet a besoin, l'outillage remplit les capacités spécifiques et le déploiement relie les deux. Les cabinets qui inversent cette séquence se retrouvent avec un outillage qui ne convient pas et une architecture qui n'a pas été construite.

Ce qui se passe lorsque les cabinets sautent des couches

Le schéma observé chez les cabinets qui ont eu des difficultés avec le déploiement de l'IA est cohérent. Le cabinet choisit un fournisseur sur la base d'une démonstration, signe une licence et tente de déployer sans d'abord construire les couches sous-jacentes. Le déploiement expose les lacunes, les équipes d'engagement s'opposent, l'amélioration des gains de production ne se matérialise pas, et le cabinet conclut que l'IA ne fonctionne pas pour l'audit.

La conclusion est erronée. L'IA fonctionne pour l'audit lorsque l'architecture sous-jacente la supporte. Le déploiement échoue parce que l'architecture n'existe pas, et le fournisseur ne peut pas construire l'architecture pour le cabinet. Le fournisseur vend l'outil. Le cabinet construit l'architecture, ou aucun outil ne délivrera la valeur promise.

Les cabinets qui se sont remis d'un déploiement raté le font généralement en prenant du recul, en construisant les couches qu'ils ont sautées, puis en redéployant le fournisseur d'origine ou en passant à un fournisseur qui correspond mieux à l'architecture reconstruite. Le coût de la récupération est plus élevé que la construction correcte des couches la première fois, mais c'est récupérable. Les cabinets qui concluent que l'IA ne fonctionne pas et cessent d'essayer perdent du terrain face aux cabinets qui effectuent le travail d'architecture.

La pression concurrentielle s'intensifie. Les clients d'audit commencent à poser explicitement des questions sur les capacités d'automatisation du cabinet lors de la discussion de la lettre d'engagement, et les cabinets qui ne peuvent pas répondre de manière crédible perdent des mandats au profit des cabinets qui le peuvent. La fenêtre pour considérer l'IA comme optionnelle se referme, et les cabinets qui ont construit l'architecture sous-jacente sont bien placés pour conquérir des parts de marché auprès des cabinets qui ne l'ont pas fait.

Les cabinets qui innovent en matière d'architecture attirent également les meilleurs talents, car les associés seniors et les managers souhaitent travailler dans un environnement d'engagement qui respecte leur temps. Les cabinets fonctionnant avec des flux de travail hérités perdent leurs collaborateurs au profit de cabinets fonctionnant avec des infrastructures modernes, et l'écart de talents aggrave l'écart de rendement. L'architecture n'est pas seulement une question d'efficacité. C'est une question de recrutement et de rétention qui se manifeste dans l'économie du cabinet sur un horizon de plusieurs années.

À propos de TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) est un cabinet d'architecture d'entreprise qui déploie une infrastructure d'agents intelligents au sein des entreprises à travers trois piliers intégrés : l'Infrastructure Agentique, les Rails de Paiement Non Traditionnels et un Moteur de Venture complet. Avec 27 ans d'expérience dans les paiements et les logiciels, TFSF opère à l'échelle mondiale, servant 21 secteurs verticaux avec une méthodologie de déploiement en 30 jours. Pour en savoir plus : https://tfsfventures.com

Évaluez gratuitement votre intelligence opérationnelle

Faites l'évaluation gratuite de votre intelligence opérationnelle. Répondez à quelques questions rapides sur votre entreprise. Recevez un plan de déploiement d'IA personnalisé dans les 24 à 48 heures, incluant des recommandations d'agents, l'architecture et une feuille de route spécifique à vos opérations. Pas d'appel de vente. Aucun engagement. Juste des données. Commencez sur https://tfsfventures.com/assessment

Initialement publié sur https://tfsfventures.com/blog/the-six-engagement-layers-every-cpa-firm-needs-before-adopting-ai-powered-audit

Rédigé par TFSF Ventures Research