Le principe sous-jacent à XBRL est que l’information « taggée » dès son entrée dans les systèmes lors de la première transaction peut être suivie dans les rapports internes soumis aux diverses divisions du groupe et finalement se déverser dans les états financiers consolidés publiés à l’extérieur du groupe.
S’il est possible de résumer l’évolution 20 dernières années des systèmes traitant d’informations financières en trois vagues successives,
- la première serait celle de la collecte avec l’apparition des systèmes sophistiqués d’ERP, de consolidation financière et de reporting,
- la seconde serait celle de l’analyse avec les systèmes de Performance Management, de Business Intelligence, les Dashboards et Scorecards,
- la troisième est celle de l’interaction qui comprend l’échange des données, la transparence et la collaboration.
XBRL a vocation à devenir la fondation de cette nouvelle génération d’applications financières à base de Web services qui permettront :
- aux régulateurs de mieux vérifier les données financières,
- aux dirigeants de comparer leur société à la concurrence,
- et aux intermédiaires financiers d’identifier les titres les plus performants.
La situation présente
Aujourd’hui, les directeurs financiers des groupes se remettent des traumatismes IFRS et Sarbannes Oxley (ou équivalent). XBRL est descendu très bas dans la liste des priorités, encore fallait-il qu’il fasse partie des dites priorités.
C’est pourquoi, la même échelle de priorités est observée chez les fournisseurs d’applications de « Performance management » qu’elles soient destinées à la consolidation, le reporting ou l’analyse (BI). Ils s’attachent à rendre plus sophistiquées les méthodes d’analyse ou à s’assurer qu’ils ne font encourir à leurs données aucun risque lié à une faille de contrôle interne. Cette démarche est basée sur l’hypothèse les données sont disponibles. Elles sont d’ailleurs d’autant mieux exploitables qu’elles sont stockées dans des entrepôts de données quasi propriétaires. Les ETL sont chargés de déverser ou transformer les données provenant des systèmes amont.
XBRL, dans son acceptation actuelle, est plus perçu comme une contrainte de publication de données au format requis par les instances réglementaires qui ont opté pour ce langage que comme une opportunité. Lorsqu’il est adopté volontairement, il s’agit souvent d’un acte de notoriété pour les groupes qui ont décidé de faire partie de programmes pilotes (tel celui de la SEC, aux Etats Unis) .
En ce qui concerne la consolidation et le reporting, les applications les plus avancées ne tiennent compte de XBRL qu’en bout de chaîne pour convertir les données qui doivent être transmises dans le cadre décrit ci-dessus. Cette conversion a souvent comme effet de briser la chaîne d’audit. Les données sont extraites du système, font l’objet d’une transformation selon une table de passage avant d’être converties au format XBRL. Les données sont certes exprimées en XBRL, mais le « tag » n’intervient qu’en bout de chaîne et ne permet pas de remonter la chaîne de production de la donnée.
La consolidation et le reporting sont au cœur d’une stratégie XBRL de groupe
Une application de consolidation et reporting aboutit à faire partager de l’information par l’ensemble du groupe, cette information n’étant disponible qu’en sortie de l’application de consolidation.
Une application de consolidation et reporting se nourrit en majeure partie, d’un échange de données entre les filiales ou divisions d’un groupe et l’organe central.
Le langage commun est le plan de compte groupe souvent défini par ces applications : plan de compte commun entre ces applications et les ERP lorsque les systèmes sont parfaitement intégrés, plans de comptes « synchronisés » entre les applications lorsqu’elles sont moins bien intégrées et plans de comptes multiples lorsque les applications sont disjointes.
La finalité de XBRL est de favoriser tous les échanges de données, y compris ceux intervenant à l’intérieur des groupes. Dans ce cas, il est possible d’affirmer que les systèmes de consolidation et de reporting ne peuvent que profiter des opportunités offertes par ce langage.
Les applications de consolidations peuvent d’ores et déjà tirer partie de XBRL qui est le langage de publication en sortie. Elles peuvent également bénéficier pleinement du fait que XBRL peut aussi devenir le langage commun de collecte des données.
Les taxonomies XBRL embarquent le plan de compte (traduit pratiquement nativement dans toutes les langues utilisées par le groupe). Ce plan de compte est lié à la norme de publication utilisée par le groupe et fait référence à la documentation officielle de cette norme. La taxonomie embarque également les détails sur les axes d’analyse utilisés par le groupe et les validations des données selon des règles présentes dans la norme comptable et qui peuvent être enrichies de validations propres aux groupes. Tout ceci n’est pas bien différent d’un système de collecte de données d’une application de consolidation. XBRL permet les échanges de données à l’intérieur et vers l’extérieur du groupe.
Les évolutions de XBRL en matière de consolidation et reporting de groupes
XBRL est limité aujourd’hui à l’agrégation de données selon des hiérarchies de calcul.
Les traitements que les applications de consolidation et reporting permettent de réaliser leur sont propres et ne sont pas réalisable dans XBRL aujourd’hui. Il s’agit des conversions monétaires qui peuvent suivre des règles très sophistiquées, des éliminations de transactions réciproques, des neutralisations d’opérations internes et autres écritures de consolidation, manuelles ou automatisées dont la complexité défie souvent l’imagination. Dans les applications, la donnée d’origine comptable est soumise à de tels traitements ou retraitements qu’il est souvent impossible de garder sa trace jusqu’à la donnée consolidée. Même « taggée », la donnée d’origine serait transformée en un autre « tag » à l’arrivée, ne serait-ce que par l’application de la conversion monétaire.
Cependant, les évolutions sont en marche et plusieurs chemins sont possibles.
Beaucoup de groupes anglo-saxons pratiquent d’ores et déjà le « push down accounting » par lequel la plupart des traitements de consolidation sont pris en charge par les filiales ou divisions avant la remontée dans le système de consolidation qui n’est dans ce cas qu’un système d’agrégation. Cette pratique pourrait s’étendre afin de permettre une utilisation plus large d’XBRL. Dans ce cas, l’agrégation permise par XBRL peut se substituer à l’application de consolidation.
Un autre chemin serait de faire évoluer les applications de consolidation de manière à les rendre plus intégrées à XBRL. En effet, une consolidation peut être schématisée en une suite d’écritures ou de transactions et XBRL GL permet de conceptualiser les différents types de transactions effectuées dans un traitement comptable. Dans ce cas, l’application de consolidation demeure mais ne brise pas la chaîne d’audit entre l’information produite par les ERP et l’information publiée.
Un coup d’œil à la « road map » de l’organisation XBRL, permet de s’apercevoir que la prochaine évolution du standard concerne les formules ou « business rules ». Il s’agit là d’un module optionnel qui permet la définition de calculs complexes, pour validation ou dérivation (évaluation d’une expression pour calculer une nouvelle valeur). Lorsqu’on analyse les traitements de consolidation, leur transcription en « business rules » est souvent possible, et de ce fait, XBRL, avec cette nouvelle extension, n’est plus très loin, voire pourrait se substituer à des traitements simples de consolidation.
En conclusion, le mot de révolution est souvent associé à XBRL et pour citer Victor Hugo à ce sujet : «Il y a une chose plus forte que toutes les armées du monde, c'est une idée dont le temps est venu».
