Financial data quality management : fiabiliser la clôture sans multiplier les corrections

Un reporting peut être juste dans sa présentation et faux dans ses fondations : compte mal affecté, taux de change obsolète, écriture chargée deux fois. Le financial data quality management organise les contrôles, les responsabilités et les corrections nécessaires pour rendre les données financières fiables, de leur saisie jusqu’à leur utilisation. L’enjeu n’est pas seulement de nettoyer des fichiers : il faut empêcher les mêmes anomalies de revenir à chaque clôture.

Définir la qualité à partir des usages financiers

Le financial data quality management, ou FDQM, associe méthodes, règles métier et outils pour vérifier que les données sont adaptées au reporting, à la consolidation, aux prévisions et aux obligations applicables. Son périmètre couvre les transactions, mais aussi les référentiels : comptes, entités, fournisseurs, devises et axes analytiques.

La gouvernance des données fixe qui décide, qui porte la responsabilité et quelles définitions font autorité. La gestion de la qualité applique ce cadre : elle mesure les écarts, déclenche les contrôles et organise leur résolution. Un logiciel ne peut pas arbitrer seul la définition du chiffre d’affaires retenue par deux directions.

Cinq dimensions à traduire en règles vérifiables

Une donnée n’est pas « bonne » dans l’absolu. Elle doit satisfaire des critères liés à son usage. Pour une clôture, les cinq dimensions suivantes constituent une base de travail, à compléter selon les risques et les processus.

• Exactitude : le montant correspond à la pièce justificative et au traitement attendu.
• Complétude : les écritures et les attributs obligatoires sont présents.
• Cohérence : comptes, devises et périodes concordent entre systèmes.
• Actualité : les données sont disponibles avant l’échéance de leur utilisation.
• Unicité : une transaction ou un tiers n’est pas enregistré plusieurs fois à tort.

Ces critères doivent déboucher sur des tests précis. Par exemple, une écriture sans entité juridique peut être bloquée, tandis qu’un libellé inhabituel peut simplement déclencher une revue.

Repérer les ruptures qui fragilisent reporting et audit

Les anomalies apparaissent souvent aux interfaces : export d’un ERP, retraitement dans un tableur, conversion de devise ou correspondance entre plans de comptes. Dans un environnement multi-ERP, deux codes identiques peuvent désigner des réalités différentes. À l’inverse, plusieurs identifiants peuvent représenter le même fournisseur.

Prenons une filiale qui transmet sa balance dans une ancienne nomenclature. Le chargement réussit techniquement, mais certaines charges sont affectées à la mauvaise rubrique. Le total reste équilibré ; la marge présentée devient trompeuse. Un contrôle technique réussi ne prouve donc pas la validité financière.

Le coût dépasse le temps de correction : rapprochements supplémentaires, prévisions faussées, justification des écarts et perte de confiance. Gartner citait en 2020 une perte annuelle minimale de 12,9 millions de dollars liée aux problèmes de qualité des données. Ce repère général ne constitue pas une estimation du coût propre à chaque direction financière.

La pression de conformité renforce cet enjeu : la part du budget IT bancaire consacrée à la compliance est passée de 9,6 % en 2016 à 13,4 % en 2023, soit une croissance de 40 %. Pour autant, un dispositif FDQM ne garantit pas à lui seul la conformité réglementaire.

Pour l’audit, il faut pouvoir retrouver l’origine d’un montant, les transformations appliquées, la règle utilisée et la validation obtenue. Cette traçabilité, ou data lineage, permet d’expliquer un résultat plutôt que de simplement affirmer qu’il a été contrôlé.

Déployer les contrôles là où les erreurs prennent naissance

Le bon point de départ est un flux critique et délimité : balance de consolidation, factures fournisseurs ou reporting de trésorerie. Un périmètre pilote permet de vérifier la méthode avant de l’étendre.

1. Diagnostiquer : cartographier le parcours des données et profiler les champs pour détecter valeurs absentes, doublons et formats atypiques.
2. Prioriser : classer les anomalies selon leur impact financier, leur fréquence et leur proximité avec une échéance.
3. Corriger et standardiser : nettoyer les données existantes, harmoniser les référentiels et formaliser les correspondances.
4. Industrialiser : intégrer validations, alertes et circuits de traitement aux flux opérationnels.
5. Améliorer : analyser les incidents récurrents et corriger leurs causes dans les systèmes producteurs.

Pour chaque règle, documentez le périmètre, le seuil, le responsable et le traitement attendu. Une anomalie bloquante doit disposer d’un circuit d’escalade ; une exception acceptée doit conserver sa justification et sa durée de validité.

Pensez les contrôles comme une couche de protection à chaque changement de sens de la donnée. À l’entrée, vérifiez le format ; après transformation, vérifiez la signification comptable ; avant publication, vérifiez la réconciliation. Cette séparation évite qu’un fichier parfaitement lisible transporte silencieusement une mauvaise interprétation financière. Elle aide aussi à localiser la rupture sans recommencer toute la chaîne.

Le monitoring continu ne signifie pas nécessairement temps réel. Contrôlez chaque chargement critique, puis adaptez les autres fréquences aux usages. Une alerte immédiate sans responsable disponible crée surtout du bruit.

Choisir une solution selon le problème, pas selon la démonstration

Les approches sont complémentaires. Avant de comparer des plateformes, identifiez si la difficulté dominante concerne les référentiels, les transformations, la détection ou le traitement des anomalies.

Testez les connecteurs ERP et grand livre, les volumes de clôture, les habilitations, l’historique des corrections et la capacité à remonter au justificatif. OneStream annonce notamment des capacités de drill back vers plus de 250 systèmes ERP, HCM, CRM et autres : vérifiez la couverture effective de vos applications et versions.

L’automatisation convient aux règles stables. L’IA peut suggérer des rapprochements ou signaler une écriture atypique, mais une proposition ne vaut pas validation comptable. La RPA peut automatiser certaines manipulations ; elle ne résout pas une définition métier ambiguë.

Demandez une démonstration sur vos anomalies réelles, avec résolution complète. Évaluez aussi le coût des connecteurs, du paramétrage, de la maintenance des règles, de la formation et de l’exploitation. Un accompagnement externe est pertinent s’il transmet une méthode et des compétences, pas seulement une configuration.

Faire durer le dispositif avec des responsabilités et des indicateurs utiles

La direction financière doit porter les exigences métier ; l’IT sécurise les flux et l’exploitation. Un responsable de données arbitre les définitions, tandis qu’un référent opérationnel, ou data steward, suit les anomalies. Le producteur de la donnée doit participer à la correction des causes.

Suivez quelques indicateurs reliés au travail réel : taux de rejets, délai de résolution, anomalies récurrentes, temps de rapprochement et corrections après clôture. Conservez des dénominateurs stables : comparer des nombres d’erreurs sans tenir compte des volumes peut masquer une dégradation.

Enfin, formez les équipes sur des situations concrètes et rendez le circuit de correction plus simple que le contournement par tableur. Le succès se mesure à la diminution des reprises manuelles et à la capacité d’expliquer les chiffres. Commencer par un flux maîtrisé, puis étendre les règles éprouvées, rend cette ambition plus réaliste qu’un nettoyage général sans responsables identifiés.