Un seul ERP peut-il gérer plusieurs entités juridiques ? Une grille d’évaluation pratique

Commencez par vos besoins, pas par l’expression « multi-entités »

La comptabilité multi-entités concerne généralement la gestion de plusieurs entités juridiques dans un même système. Cette définition ne précise pas comment un produit donné gère les livres comptables, les transactions, les règles d’accès ou les rapports : ces processus varient selon le produit et sa configuration. (Rillet, « Multi-Entity, Multi-Currency ERP for Scale-Ups » : https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Considérez la consolidation, la simplification des clôtures et la réduction des risques comme des résultats à vérifier, et non comme des avantages automatiques. Oracle NetSuite présente ces éléments comme des objectifs potentiels de la comptabilité multi-entités, mais cela ne permet pas de savoir ce qu’une mise en œuvre donnée permettra réellement d’accomplir. La gestion de plusieurs entités dans un même système peut également complexifier les processus à mesure que l’organisation se développe. (Oracle NetSuite : https://www.netsuite.com/portal/resource/articles/accounting/multi-entity-accounting.shtml ; Citrin Cooperman : https://www.citrincooperman.com/In-Focus-Resource-Center/Multi-Entity-Accounting-in-QuickBooks-When-Does-It-Make-Sense-to-Take-the-Next-Step)

Comparez un environnement partagé à votre approche actuelle ou envisagée reposant sur des systèmes distincts, en utilisant les mêmes processus réels. Une plateforme partagée est une façon de gérer plusieurs entités juridiques, mais rien ne garantit qu’elle convienne à toutes les organisations. (Rand Group : https://www.randgroup.com/insights/services/evaluation-selection/best-multi-entity-accounting-software-and-erp-systems-for-growing-businesses/)

• Dressez la liste de toutes les entités juridiques concernées, de leur rôle dans l’organisation et des équipes qui utilisent leurs données.
• Identifiez les processus comptables et opérationnels qui doivent fonctionner entre les entités, et pas seulement au sein de chacune d’elles.
• Recensez les résultats attendus : livres et rapports par entité, vues consolidées, justificatifs d’audit et éventuels rapports externes.
• Classez chaque besoin comme essentiel, souhaitable ou à clarifier. Distinguez les interprétations juridiques et comptables des questions de configuration logicielle.

Distinguez les entités juridiques des sites, services et devises

Une entité juridique n’est pas interchangeable avec un service, une succursale, un projet, un entrepôt ou une devise. Ces dimensions peuvent toutes être importantes dans un ERP, mais les utiliser les unes à la place des autres peut rendre floues l’organisation à laquelle appartient une transaction et les écritures comptables dans lesquelles elle doit figurer.

Préparez une courte cartographie des entités avant les démonstrations. Pour chacune, indiquez les activités exercées, les données à tenir et ses liens avec les autres entités. Dressez ensuite la liste des dimensions autres que les entités selon lesquelles vous devez établir des rapports, comme le service ou le site.

Demandez au fournisseur de montrer comment le système représente chaque notion et ce qui se passe lorsqu’un utilisateur saisit une transaction. Ne déduisez pas le traitement juridique ou comptable à partir du libellé affiché à l’écran. Demandez à des conseillers qualifiés de confirmer les entités et les traitements de reporting dont votre organisation a besoin.

• Une transaction peut-elle être affectée à la bonne entité juridique indépendamment de son service, de son site ou de son projet ?
• Un même site ou service peut-il être associé à plusieurs entités si cela correspond à votre structure ?
• Comment le système distingue-t-il la devise de transaction de la devise de reporting de l’entité et du groupe, le cas échéant ?
• Quels champs sont obligatoires pour éviter que les utilisateurs enregistrent une activité dans la mauvaise entité ?

Vérifiez ce qui doit être séparé : livres, périodes, numérotation et accès

Ne partez pas du principe qu’un système partagé implique des contrôles comptables entièrement communs ou entièrement distincts. Pour chaque besoin, demandez au fournisseur d’indiquer le paramètre ou le processus qui le prend en charge, de le démontrer dans un environnement de test et d’expliquer les éventuelles limites ou dépendances.

Confirmez le comportement attendu avec votre équipe comptable. La nécessité de différencier les périodes, les séquences de numérotation, les grands livres ou d’autres contrôles peut dépendre de vos politiques comptables, des juridictions concernées et de vos obligations de reporting.

• Livres : pouvez-vous identifier les données qui appartiennent à chaque entité et produire les vues comptables requises pour celle-ci ?
• Périodes : chaque entité peut-elle suivre les contrôles de période et le processus de clôture exigés par votre équipe financière ? Que se passe-t-il lorsqu’une entité est prête à clôturer avant une autre ?
• Numérotation : les identifiants des transactions peuvent-ils suivre les règles dont vous avez besoin selon l’entité ou le type de transaction ? Demandez ce qui se passe lorsqu’un numéro est annulé ou qu’un enregistrement est corrigé.
• Autorisations : les utilisateurs peuvent-ils être limités aux entités et aux données correspondant à leur rôle ? Testez ce qu’ils peuvent consulter, créer, modifier, approuver ou exporter.
• Piste d’audit : demandez quelles preuves sont conservées en cas de modification de l’affectation d’une entité, des écritures comptables ou des accès utilisateurs, et comment les personnes autorisées peuvent les retrouver.

Testez les données de référence partagées : clients, fournisseurs, produits et autres

Un dossier client ou fournisseur partagé peut réduire les tâches de maintenance en double, mais peut aussi soulever des questions concernant la propriété des données, leur visibilité, les conditions propres à chaque entité et leur qualité. Ne supposez pas que l’ERP partage automatiquement les données de référence ni que le partage convient à tous les dossiers.

Utilisez des dossiers représentatifs de votre activité. Demandez au fournisseur de montrer si un client, un fournisseur, un produit ou un service peut être utilisé par plusieurs entités, si les informations propres à chaque entité peuvent différer et ce qu’un utilisateur d’une entité peut consulter ou modifier. Confirmez le comportement dans un environnement de test.

• Une même contrepartie peut-elle avoir des activités avec plusieurs entités, et comment ces activités sont-elles différenciées dans le dossier et les rapports ?
• Quels champs des données de référence sont partagés, et lesquels peuvent différer selon l’entité ?
• Comment les doublons ou les dossiers contradictoires sont-ils repérés et résolus ?
• L’accès peut-il être limité lorsqu’un dossier est partagé entre plusieurs entités ?
• Quel est l’effet de la modification d’un dossier partagé sur les transactions existantes et à venir ?

Suivez les transactions intersociétés de l’initiation au règlement

Le rapprochement intersociétés est un aspect pertinent à évaluer dans le cadre de la comptabilité multi-entités, mais une description générale des capacités d’un produit ne permet pas de savoir comment il gère vos types de transactions. (Rillet, « Multi-Entity, Multi-Currency ERP for Scale-Ups » : https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Évaluez l’ensemble du processus, et pas seulement une case à cocher ou un écran de transaction. Incluez la transaction initiale, l’écriture ou le document correspondant dans l’autre entité, la vérification et l’approbation, le rapprochement, le règlement ainsi que les rapports utilisés par l’équipe financière pour confirmer que l’opération est terminée. Demandez au fournisseur de distinguer le fonctionnement standard des éléments qui nécessitent une configuration, des étapes manuelles, des intégrations ou des produits supplémentaires.

• Testez une vente ou une prestation de services d’une entité à une autre : qui l’initie, quelles données sont créées et comment les deux côtés sont-ils vérifiés ?
• Testez une dépense payée par une entité pour le compte d’une autre : comment l’imputation est-elle enregistrée, approuvée et rapprochée ?
• Testez le transfert de stocks, d’actifs ou d’autres éléments si ce type d’opération existe dans votre organisation.
• Le cas échéant, demandez comment sont gérés les taux de change, les décalages de calendrier, les montants divergents et les écritures correspondantes rejetées.
• Suivez le solde jusqu’au règlement. Déterminez qui est responsable de chaque étape et comment les écarts non résolus sont signalés.
• Demandez si le processus est automatisé, partiellement automatisé ou manuel, et quels contrôles restent à la charge du client.

Vérifiez les rapports par entité et les vues de groupe, y compris les éliminations

Demandez au fournisseur de générer un même rapport représentatif par entité puis pour le groupe. Vérifiez le périmètre, les filtres, la présentation des devises, les données sources et le calendrier de chaque vue, plutôt que de vous fier à un écran récapitulatif soigné.

Si vous avez besoin de rapports consolidés, demandez comment le système traite les soldes et les transactions intersociétés, notamment si et comment les éliminations sont représentées. Ne supposez pas qu’une vue consolidée équivaut à un processus de consolidation complet. Demandez à vos conseillers comptables de confirmer le traitement comptable requis, les contrôles de vérification et les résultats de reporting.

• Les utilisateurs autorisés peuvent-ils produire les rapports requis pour une seule entité sans y mélanger l’activité d’une autre ?
• La vue de groupe peut-elle être reliée aux entités contributrices et aux écritures sous-jacentes ?
• Comment les soldes intersociétés sont-ils identifiés, vérifiés et rapprochés pour les besoins du reporting ?
• Si des éliminations sont nécessaires, où sont-elles enregistrées, vérifiées et prises en compte dans les résultats ?
• Les utilisateurs peuvent-ils voir la période de reporting, le périmètre des entités et les autres filtres qui ont déterminé un rapport ?
• Quels éléments le produit ne consolide-t-il pas ou ne calcule-t-il pas sans configuration supplémentaire ou intervention manuelle ?

Testez les exceptions, pas seulement le parcours idéal

Les démonstrations habituelles s’appuient souvent sur des données propres et un processus simple. Votre évaluation doit aussi montrer ce qui se passe lorsqu’un dossier est erroné, en retard, soumis à des restrictions ou déjà intégré à un processus clôturé. Ces cas peuvent révéler des dépendances opérationnelles qu’une liste de fonctionnalités n’explique pas forcément.

Définissez les résultats attendus en fonction de vos propres règles. Les questions ci-dessous sont des pistes de test, et non des affirmations sur la manière dont tous les ERP les gèrent.

• Correction : quelles étapes sont possibles lorsqu’une transaction a été affectée à la mauvaise entité ? La correction conserve-t-elle un historique compréhensible ?
• Saisie tardive : comment le système gère-t-il une transaction tardive concernant une période clôturée ou en cours de clôture ?
• Changement d’entité : une affectation d’entité peut-elle être modifiée après la saisie ou l’approbation ? Qui peut le faire, et quelles données ou quels rapports sont concernés ?
• Accès restreint : que se passe-t-il lorsqu’un utilisateur tente de consulter, modifier, approuver ou exporter un dossier hors de son périmètre autorisé ?
• Écart : comment les paires intersociétés incomplètes ou les soldes non rapprochés sont-ils repérés, attribués et suivis ?
• Échec ou exception : quelles preuves sont disponibles lorsqu’un processus ne peut pas se terminer comme prévu ?

Utilisez un protocole d’évaluation reproductible et conservez les preuves

Exécutez le même protocole pour chaque système candidat. Utilisez des scénarios représentatifs, des rôles réalistes et des données d’exemple correspondant à votre structure d’entités. Demandez au fournisseur de faire une démonstration du processus, puis, dans la mesure du possible, faites-le reproduire par votre équipe dans un environnement de test.

Pour chaque besoin, consignez le résultat, les preuves et les questions en suspens. Les preuves peuvent prendre la forme d’un document produit daté, d’un écran de configuration, d’un résultat de test ou d’une clarification écrite du fournisseur. Considérez les déclarations orales comme non vérifiées tant qu’elles n’ont pas été confirmées.

• Créez un scénario pour chaque processus prioritaire : saisie propre à une entité, données de référence partagées, activité intersociétés, reporting et au moins une exception.
• Pour chaque scénario, consignez les données de départ, le rôle utilisateur, le résultat attendu, le résultat obtenu et les éventuelles solutions de contournement manuelles.
• Indiquez si le comportement est standard, configuré, dépendant d’un autre produit ou processus, ou encore non confirmé.
• Notez les limites, les décisions à prendre par le client, les dépendances de mise en œuvre et la personne responsable de chaque suivi.
• Évaluez l’adéquation aux besoins, et non le nombre de fonctionnalités. Considérez l’échec d’un processus essentiel comme un problème à prendre en compte dans la décision, et non comme une lacune mineure de la démonstration.
• Demandez aux équipes finance et opérations d’examiner les preuves ensemble ; adressez les questions relatives au traitement comptable et à la structure juridique à des conseillers qualifiés.