Votre ERP peut-il rapprocher bons de commande, réceptions et factures ? Liste de contrôle pratique

Ce que vérifie le rapprochement à trois pièces — et ce qu’il ne garantit pas

Le rapprochement à trois pièces désigne généralement la comparaison d’une facture fournisseur avec un bon de commande et un justificatif de réception des marchandises. Dans un processus achats-paiements décrit, la comptabilité fournisseurs rapproche les factures des bons de commande et des justificatifs de réception; les factures concordantes passent ensuite au traitement du paiement [2]. Il s’agit d’un exemple de processus, et non d’une garantie que tous les ERP appliquent les mêmes règles.

Le rapprochement peut aider à repérer les incohérences entre les données de commande, de réception et de facture. À lui seul, il ne permet pas de déterminer si les marchandises sont utilisables, si le service était satisfaisant, si le fournisseur est légitime ou si le traitement fiscal est correct. Les contrôles de réception, d’approbation, de vérification des fournisseurs et de comptabilité restent importants.

Ne partez pas du principe que tous les ERP comparent les mêmes champs ou appliquent les mêmes règles. La comparaison peut se faire au niveau des lignes, du total du document ou des deux; elle peut appliquer des tolérances configurées ou exiger qu’une personne résolve les écarts. Testez le comportement dont vous avez besoin au lieu de vous fier à l’intitulé d’une fonctionnalité.

• Bon de commande : vérifiez les champs utilisés, par exemple l’article ou le service, la quantité commandée, le prix unitaire et le total de la ligne ou de la commande.
• Réception : vérifiez comment les quantités et les valeurs enregistrées justifient la facture, et si plusieurs réceptions peuvent être associées à une commande.
• Facture : vérifiez quelles quantités, quels prix, quels totaux et quels autres frais pertinents sont comparés.
• Décision : déterminez si la concordance signale seulement un statut, permet l’approbation ou fait passer la facture au processus de paiement.

Cartographiez votre cycle achats-paiements, les rôles et les seuils d’approbation avant les tests

Avant d’ouvrir une démonstration, consignez le cheminement d’un achat au sein de votre organisation. Indiquez qui en fait la demande, qui l’approuve, qui passe la commande, qui enregistre la réception, qui traite les factures et qui autorise le paiement. Un test n’est pertinent que si l’ERP est évalué au regard des responsabilités et de la séparation des tâches réellement requises par votre organisation.

Définissez les limites et les exceptions qui comptent pour votre activité. Consignez les seuils d’approbation, les écarts de prix ou de quantité autorisés, les justificatifs requis pour les services et les règles applicables à la modification d’une commande après approbation. Si vous n’avez pas encore de politique, indiquez que la décision reste à prendre au lieu de supposer que le paramétrage par défaut de l’ERP convient.

Les exigences varient selon l’organisation et la juridiction. Demandez aux responsables de la comptabilité, des achats et de la conformité de relever les exigences locales, notamment les règles applicables aux factures, aux taxes, à la tenue des registres ou aux approbations. Une description générale d’un processus par un fournisseur ne constitue pas un avis juridique ou comptable.

• Schématisez le parcours habituel, de la demande à la commande, à la réception, à l’examen de la facture, à l’approbation et au paiement.
• Attribuez chaque action à un rôle, y compris le droit de modifier un bon de commande ou une réception.
• Définissez des seuils d’approbation représentatifs et identifiez les personnes autorisées à approuver une exception.
• Dressez la liste des documents à conserver et des personnes qui doivent y avoir accès.
• Relevez les questions propres à votre juridiction à poser à un conseiller qualifié ou à l’autorité compétente.

Préparez des cas de test représentatifs : concordance exacte, réception partielle, écart, avoir et facture en double

Préparez un petit jeu de tests reproductible à partir de données fictives de fournisseurs et de transactions. Effectuez tous les essais dans un environnement de test ou un bac à sable, jamais dans l’ERP de production. N’y saisissez pas de factures réelles et ne lancez pas de paiements réels pour tester les doublons ou les exceptions. Incluez des opérations sans anomalie et des exceptions. Pour chaque cas, notez les documents et les valeurs saisis, le résultat attendu et les justificatifs à recueillir. Utilisez les mêmes cas pour chaque ERP évalué afin de comparer les solutions équitablement.

Incluez explicitement les livraisons partielles. Par exemple, commandez une quantité, enregistrez la réception d’une partie seulement, puis testez une facture portant sur la quantité reçue et une autre portant sur la quantité totale commandée. Enregistrez ensuite une réception ultérieure et vérifiez comment la quantité restante est traitée. L’essentiel est de savoir comment l’ERP associe plusieurs réceptions et factures, et ce qu’il autorise à chaque étape.

Dans la mesure du possible, ne faites varier qu’une condition à la fois. Il est plus facile d’évaluer un faible écart de prix contrôlé qu’un cas où le prix, la quantité et le transport changent simultanément. Ajoutez ensuite des combinaisons plus complexes correspondant à vos transactions réelles.

• Concordance exacte : la quantité et le prix de la facture correspondent au bon de commande et à la réception enregistrée.
• Réception partielle : la facture porte uniquement sur la partie reçue; testez ensuite une facture dont la quantité dépasse celle enregistrée comme reçue.
• Écart de prix : le prix unitaire facturé diffère de celui de la commande, tandis que la quantité correspond.
• Écart de quantité : la quantité facturée diffère de la quantité reçue ou commandée.
• Avoir ou ajustement : testez le lien entre un avoir ou un ajustement fournisseur, la facture d’origine et la commande.
• Doublon : dans l’environnement de test, soumettez deux fois la même facture, puis testez une nouvelle soumission dont la référence ou la mise en forme a changé si cela correspond à votre niveau de risque.
• Frais supplémentaires : si nécessaire, testez séparément le transport, les taxes, les remises ou d’autres frais et vérifiez leur incidence sur la comparaison et l’approbation.

Vérifiez comment l’ERP repère les écarts et influe sur l’approbation ou le paiement

Pour chaque test, observez ce que le système compare et signale réellement. Notez s’il identifie le document, la ligne et le champ concernés, s’il affiche les valeurs attendues et saisies, et si l’utilisateur peut comprendre la mesure à prendre. Un statut générique « exception » peut être insuffisant si le personnel doit consulter plusieurs documents pour comprendre le problème.

Testez les conséquences de chaque résultat, pas seulement l’avertissement. Une exception bloque-t-elle l’approbation, empêche-t-elle le paiement ou apparaît-elle simplement dans une liste? Une personne autorisée peut-elle poursuivre le traitement? Le comportement diffère-t-il pour un petit écart et pour un écart important? Ne supposez pas qu’un avertissement constitue un contrôle de paiement ni qu’un statut bloqué ne peut pas être contourné.

Demandez au fournisseur quelles règles de rapprochement sont configurables et lesquelles sont fixes. Vérifiez si les tolérances s’appliquent en montant, en pourcentage, en quantité, par ligne ou par document, et si les taxes ou autres frais sont traités séparément. Consignez précisément ce que vous avez vérifié; ne généralisez pas à partir d’un seul exemple concluant.

• Consignez le résultat du système pour chaque cas normal et chaque exception.
• Vérifiez si l’écart est visible par la personne chargée de le résoudre.
• Faites avancer la facture suffisamment dans le processus pour confirmer si l’approbation ou le paiement est suspendu.
• Reprenez un cas d’écart juste en dessous puis juste au-dessus de toute tolérance envisagée.
• Vérifiez si la modification d’une commande, d’une réception ou d’une facture après le rapprochement modifie le statut ou crée une trace visible.

Vérifiez les autorisations, les dérogations et les justificatifs d’audit

Évaluez les personnes et les autorisations concernées, et pas seulement le calcul de rapprochement. Connectez-vous avec des comptes correspondant aux différents rôles et essayez les actions importantes : modifier une commande, enregistrer une réception, résoudre un écart, approuver une facture et autoriser un paiement. Vérifiez si une même personne peut effectuer des actions que votre processus prévoit de séparer.

Demandez ce qui se passe lorsqu’une personne déroge à un écart. Examinez l’historique généré par une transaction de test et vérifiez s’il indique qui est intervenu, quand, sur quelle transaction, ce qui a changé, le motif fourni et l’approbation associée, le cas échéant. Ce sont des éléments à vérifier, pas des fonctionnalités garanties. Un article de l’ACM décrit une piste d’audit dans un processus ERP proposé, mais n’établit pas quels détails ni quelles règles de conservation tous les ERP offrent [2].

Vérifiez les modalités de conservation, d’accès, d’exportation et de suppression au regard des besoins de votre organisation en matière de tenue des registres. Une démonstration du fournisseur ne prouve pas que le même paramétrage est activé dans l’installation ERP évaluée.

• Testez chaque rôle avec un compte distinct dans la mesure du possible; ne vous fiez pas uniquement à une démonstration faite par un administrateur.
• Essayez les actions autorisées et interdites, puis notez le résultat.
• Si votre politique l’exige, vérifiez si les dérogations nécessitent un motif ou une approbation supplémentaire.
• Examinez l’historique généré et vérifiez que les utilisateurs concernés peuvent y accéder.
• Demandez comment les données d’audit sont conservées, exportées et protégées, puis validez les réponses dans l’environnement de test.

Évaluez la gestion des exceptions, les rapports et les exports au regard des besoins opérationnels

L’utilité quotidienne du rapprochement dépend de la façon dont les exceptions sont traitées. Vérifiez si le personnel peut trouver les factures non résolues, identifier la raison de chaque blocage, consulter le bon de commande et la réception associés, attribuer ou acheminer le dossier et consigner sa résolution. Si votre processus repose sur le courriel ou un autre outil, vérifiez quelles informations doivent être transférées manuellement.

Évaluez les rapports à l’aide de questions réalistes : quelles factures sont en attente de réception? Lesquelles présentent des écarts de prix ou de quantité? Quelles exceptions restent non résolues depuis longtemps? La comptabilité fournisseurs peut-elle distinguer une facture bloquée d’une facture approuvée mais non payée? Les noms et la disponibilité des rapports varient; vérifiez si l’ERP répond aux questions que votre équipe se pose réellement.

Testez les exports sur une période représentative et un petit nombre de transactions. Vérifiez qu’ils comprennent les champs, identifiants et statuts dont votre équipe financière a besoin pour le rapprochement ou les analyses complémentaires. La présence d’un champ dans un export ne prouve pas, à elle seule, que le contrôle sous-jacent a fonctionné correctement.

• L’équipe peut-elle trouver les exceptions en cours sans consulter individuellement chaque dossier fournisseur?
• Le personnel peut-il accéder au bon de commande, à la réception et à la facture concernés depuis l’exception?
• Pouvez-vous déterminer le responsable, l’ancienneté, le motif et le statut actuel d’un dossier non résolu?
• Les rapports ou les exports peuvent-ils être filtrés et rapprochés des documents utilisés dans votre processus?
• Les corrections et les résolutions restent-elles visibles après la clôture de l’exception initiale?

Appuyez-vous sur la documentation du fournisseur et un environnement de test; consignez les limites et les questions propres à votre juridiction

Commencez par la documentation officielle du fournisseur pour comprendre le processus prévu, les options de configuration, les prérequis et la terminologie. Par exemple, un guide d’installation de Hyland répertorie des champs de bon de commande tels que la quantité commandée, le prix unitaire et le total de ligne, ainsi que les quantités et valeurs totales des réceptions et des factures [1]. Il décrit aussi des options de configuration permettant d’obtenir les données de ligne d’un bon de commande à partir d’un fichier ou d’une base de données [1]. Ces exemples peuvent aider à préparer des cas de test, mais ne démontrent pas qu’un autre ERP comporte les mêmes champs ou se comporte de la même manière.

Confirmez le comportement dans un environnement de test à l’aide de vos propres cas. La documentation décrit un produit ou une configuration; elle ne prouve pas qu’un paramètre donné est activé dans l’installation évaluée ni qu’il convient à votre processus. Tenez un journal indiquant le scénario, la configuration, le rôle de l’utilisateur, les étapes, les résultats attendus et observés, les justificatifs et les questions en suspens.

Pour les applications ERP auto-hébergées, évaluez l’application séparément de l’hébergement. Examinez qui est responsable de la configuration de l’application, des accès utilisateurs, de la gouvernance des données, des sauvegardes et des procédures de reprise. Une infrastructure gérée peut réduire la charge liée à l’infrastructure, mais elle ne décharge pas votre organisation de ses responsabilités concernant les règles métier, les données et les décisions d’accès.

• Utilisez la documentation officielle comme guide, puis reproduisez le processus dans un environnement de test sécurisé ou un bac à sable.
• Consignez la version de l’application et la configuration utilisées pour le test.
• Conservez les justificatifs des rapprochements réussis, des exceptions, des dérogations, des autorisations et des exports.
• Pour chaque exigence, indiquez si elle est vérifiée, configurable, non prise en charge, incertaine ou si elle nécessite encore l’avis d’un professionnel.
• Faites confirmer les questions de comptabilité, de fiscalité, de confidentialité et de conservation des documents par des conseillers compétents dans votre juridiction.

Liste de contrôle pour décider entre plusieurs ERP

Évaluez les solutions candidates à partir des mêmes scénarios opérationnels plutôt qu’en comptant les noms de fonctionnalités. Une solution qui traite clairement vos transactions courantes et permet de responsabiliser les personnes chargées des exceptions peut mieux convenir qu’une solution avec une liste de fonctionnalités plus longue, mais dont le comportement reste flou là où votre processus est le plus exposé.

Distinguez les contrôles indispensables des préférences. Si un ERP ne peut pas démontrer une limite d’approbation requise, une dérogation traçable ou un processus comptable adapté à votre juridiction, consignez-le comme un manque à résoudre — et non comme une promesse à réexaminer après l’adoption. Tenez également compte de l’effort de mise en œuvre et de l’administration continue dans votre décision.

• Nous avons cartographié notre cycle achats-paiements, les rôles et les seuils d’approbation.
• Nous avons testé les concordances exactes, les réceptions partielles, les écarts de prix et de quantité, les avoirs et les doublons dans un environnement de test avec des données fictives.
• Nous avons vérifié ce que le système compare et ce qu’il advient d’une facture en cas d’écart.
• Nous avons testé les autorisations par rôle, les dérogations et les justificatifs conservés pour chaque action.
• Nous pouvons trouver, attribuer, résoudre et rapporter les exceptions d’une manière adaptée à notre équipe.
• Les exports répondent à nos besoins réels de rapprochement et de vérification.
• Nous avons documenté les dépendances de configuration, les limites et les questions sans réponse à poser au fournisseur.
• Nous avons examiné les exigences applicables en matière de comptabilité, de fiscalité, de confidentialité et de tenue des registres avec des personnes qualifiées.