Même périmètre qu'en 2020, mais une base taxonomique à mettre à jour
L'exercice ESEF 2021 porte sur les mêmes états financiers primaires consolidés IFRS qu'en 2020 : bilan, compte de résultat, état de variation des capitaux propres, tableau des flux de trésorerie. Les notes restent hors périmètre.
La différence principale est la mise à jour de la base taxonomique. L'ESMA a publié la taxonomie ESEF 2020 en mars 2021. Elle incorpore les amendements IFRS publiés courant 2020 et corrige certains éléments de la taxonomie précédente. Les sociétés utilisant Workiva devaient mettre à jour le référentiel dans leur espace avant le dépôt.
Ce que ça signifie concrètement : une taxonomie étendue correctement construite en 2020 rendait la bascule vers la taxonomie ESEF 2020 très maîtrisable. Sur une base fragile, le risque de régression était réel. Des éléments standard légèrement renommés dans la nouvelle taxonomie suffisaient à casser les mappings existants.
Des extensions créées pour des concepts qui existaient déjà
Le premier bilan des packages déposés en 2021 (pour l'exercice 2020) a mis en évidence un problème récurrent : des sociétés avaient créé des extensions pour des concepts IFRS qui existent déjà dans la taxonomie standard.
La raison est souvent la même : le libellé affiché dans le rapport diffère du label de l'élément taxonomique IFRS. Une ligne intitulée "Résultat des activités opérationnelles" dans le rapport ne correspond pas mot pour mot à ifrs-full:ProfitLossFromOperatingActivities. Certaines équipes ont donc créé une extension là où un mapping sur l'élément standard suffisait.
Cette pratique pose deux problèmes. Premier problème : elle gonfle la taxonomie étendue de la société avec des éléments redondants. Deuxième problème : elle rend les données moins comparables entre sociétés, ce qui est exactement ce que l'ESEF cherche à corriger. L'ESMA exploite les packages déposés pour alimenter ses bases de données de comparaison inter-émetteurs. Des extensions superflues dégradent cette exploitation.
Une extension iXBRL se justifie quand un concept propre à la société n'a pas d'équivalent dans la taxonomie IFRS. Pas quand le libellé visible dans le rapport diffère de celui de l'élément standard.
Une extension sans ancrage ne dit rien à une machine
Ce qu'est l'ancrage et pourquoi il est obligatoire
Une société qui crée une extension pour un concept non couvert par la taxonomie IFRS doit l'ancrer. L'ancrage (anchoring) établit une relation entre l'extension et l'élément IFRS le plus proche dans la hiérarchie taxonomique.
Deux types de relations sont possibles. La relation "wider-than" : l'élément IFRS est plus large que l'extension (l'extension est un sous-ensemble). La relation "narrower-than" : l'extension est plus large que l'élément IFRS (elle englobe le concept standard et plus encore). Ces relations permettent aux systèmes automatisés de comprendre comment positionner l'extension dans la structure IFRS.
Ce que 2020 a révélé sur les ancrages
Beaucoup de packages du premier exercice présentaient des extensions sans ancrage, ou avec des ancrages incorrects. Trois cas de figure étaient fréquents :
- Absence totale d'ancrage : l'extension "flotte" sans lien vers la taxonomie IFRS.
- Ancrage vers un élément IFRS éloigné : le concept IFRS choisi n'a pas de lien logique réel avec l'extension.
- Sens de la relation inversé : une relation "wider-than" là où une relation "narrower-than" s'impose, ou inversement.
Exemple terrain : une société crée une extension company:RevenueFromContractsWithDistributors pour isoler un flux de revenus spécifique. L'ancrage correct pointe vers ifrs-full:Revenue en relation "narrower-than" : l'extension est plus étroite que le concept IFRS "Revenus". Un ancrage manquant, ou un ancrage vers ifrs-full:Assets par erreur de manipulation, rend l'extension sémantiquement inutilisable par les systèmes d'analyse.
L'AMF cible ses recommandations sur les extensions et les ancrages
Pour l'exercice 2020, l'AMF avait adopté une posture d'apprentissage collectif. En 2021, elle a publié des recommandations plus ciblées, en s'appuyant sur l'analyse des packages déposés.
Ses observations portaient notamment sur :
- le recours excessif aux extensions au lieu des éléments taxonomiques standards,
- la qualité des ancrages, souvent absents ou incorrects,
- la présence d'erreurs dans les rapports de conformité Arelle,
- les incohérences entre les valeurs balisées et les états financiers publiés.
L'AMF a également rappelé que la validation technique via Arelle est un prérequis, pas une garantie de qualité sémantique. Un package peut passer l'ensemble des règles de validation ESMA et rester incorrect sur le fond.
Les règles de validation ESMA changent chaque année, le plug-in Arelle aussi
Les règles de validation ESMA sont publiées sous forme de fichiers de règles à charger dans Arelle. Elles évoluent chaque année, en parallèle des mises à jour taxonomiques. Pour l'exercice 2021, de nouvelles règles portaient spécifiquement sur la cohérence des ancrages et la présence de labels obligatoires sur les extensions.
Concrètement : des packages qui passaient Arelle en 2020 pouvaient échouer sur les règles 2021, à contenu inchangé. Les exigences de validation avaient été renforcées, pas le document. Certaines équipes n'avaient ni mis à jour leur plug-in Arelle ni relu les règles de l'exercice. Elles ont découvert les erreurs au dernier moment.
Une taxonomie documentée se met à jour, une taxonomie bricolée se refait
Sur Workiva, la taxonomie étendue de la société est construite et maintenue dans l'outil. Chaque extension est créée avec son ancrage, son label, et son type de données. Quand l'exercice suivant arrive, la base est là : il faut la mettre à jour, pas la reconstruire.
Ce qui change entre une configuration solide et une configuration fragile : la capacité à absorber les évolutions annuelles sans régression. Mise à jour de la taxonomie ESEF, nouvelles règles Arelle, ajout d'une ligne dans les états financiers : ces situations demandent de savoir exactement ce qui est dans la taxonomie étendue, pourquoi chaque extension existe, et vers quel élément IFRS elle est ancrée.
Ce que ça donne en pratique : les sociétés qui avaient construit une taxonomie propre en 2020 ont basculé leur configuration Workiva vers la taxonomie ESEF 2020 en quelques heures. Les autres avaient une taxonomie mal documentée, avec des extensions sans ancrage et des mappings approximatifs. Il a fallu reprendre l'architecture avant même de lancer la mise à jour.
Le nombre d'extensions renseigne sur la qualité du balisage
Après deux exercices ESEF, la qualité du balisage iXBRL se lit d'abord dans les extensions. Leur nombre, leur pertinence, la rigueur de leur ancrage.
Une taxonomie étendue bien construite contient peu d'extensions. Chacune correspond à un concept réellement absent de la taxonomie IFRS. Chacune est ancrée correctement. Les labels sont cohérents avec le contenu balisé.
Une taxonomie étendue mal construite en contient beaucoup, souvent créées pour un simple écart de libellé, avec des ancrages approximatifs ou absents. Elle produit des packages qui passent Arelle sans refléter la structure réelle des états financiers.
En 2021, les sociétés qui avaient fait ce travail correctement dès le départ ont mis à jour leur taxonomie et rien de plus. Celles qui avaient bâclé l'architecture initiale ont tout repris. Ce qui les sépare tient à la rigueur appliquée à la taxonomie dès le premier exercice.
