Le périmètre 2020 : quatre états financiers, rien d'autre
Le règlement délégué (UE) 2019/815 de la Commission européenne fixe le format électronique unique européen de reporting, dit ESEF. Il impose aux émetteurs cotés sur un marché réglementé de l'UE de publier leurs rapports financiers annuels au format iXBRL.
Pour le premier exercice (clôtures au 31 décembre 2020, dépôts au printemps 2021), le périmètre obligatoire est ciblé : seuls les états financiers primaires consolidés IFRS doivent être balisés. Concrètement :
- le bilan consolidé,
- le compte de résultat consolidé,
- l'état de variation des capitaux propres,
- le tableau des flux de trésorerie.
Les notes annexes restent hors périmètre en 2020. Elles y entrent progressivement à partir de 2022. La précision compte : beaucoup d'équipes ont sous-estimé la charge en pensant que baliser quatre tableaux irait vite.
Taxonomie ESEF 2019 : plusieurs milliers d'éléments à cartographier
L'ESMA (Autorité européenne des marchés financiers) a publié la taxonomie ESEF 2019. Elle est construite sur la taxonomie de l'IFRS Foundation, traduite et encadrée pour le contexte européen.
Cette taxonomie contient plusieurs milliers d'éléments XBRL couvrant les concepts IFRS courants : postes de bilan, lignes de résultat, variations de capitaux propres, flux de trésorerie. Chaque concept porte trois caractéristiques imposées. Le type de données attendu (montant monétaire, pourcentage, texte). La période de référence (instant ou durée). La balance attendue (débit ou crédit).
Ce que ça implique sur le terrain : le balisage commence par une cartographie. Chaque poste des états financiers de la société est confronté aux éléments de la taxonomie standard. Si un poste correspond à un élément existant, on l'utilise. S'il ne correspond à rien, on crée une extension. Ce travail demande une connaissance réelle des deux référentiels : la structure IFRS et la taxonomie ESEF.
Fin 2019, presque aucune direction financière ne savait faire du XBRL
Le constat est net à l'ouverture de l'exercice. Peu d'équipes connaissent XBRL. La taxonomie reste un fichier technique difficile à lire. Les outils de tagging sont en cours de développement ou tout juste mis sur le marché. Les cabinets capables d'accompagner sur le balisage ESEF sont rares.
Les directions financières ont géré la situation de différentes façons :
- certaines ont internalisé le sujet avec une personne formée en urgence,
- d'autres ont délégué à leur prestataire de publication (imprimeur financier),
- quelques-unes ont mis en place un outil comme Workiva avec un accompagnement externe.
La première option bute sur le temps de formation. Une personne formée en quelques semaines ne repère pas les défauts d'architecture d'une taxonomie maison. La deuxième bute sur le périmètre de compétence de l'imprimeur : il maîtrise la mise en forme, pas la logique XBRL. Dans les deux cas, les erreurs sont passées inaperçues.
Le balisage iXBRL traduit les états financiers dans un langage lisible par les machines. Quand la traduction est approximative, le fichier passe la validation technique et ment sur la structure réelle des données.
Cinq erreurs qui reviennent dans les packages de 2020
1. Extensions créées pour des concepts qui existent déjà
La taxonomie ESEF 2019 couvre la grande majorité des postes IFRS standards. Beaucoup de sociétés ont pourtant créé des extensions pour des concepts déjà présents. Le motif est souvent le même : le libellé affiché dans leur rapport différait un peu de l'élément taxonomique.
Résultat : une taxonomie étendue inutilement gonflée, avec des éléments redondants qui rendent la comparabilité inter-sociétés difficile. C'est précisément ce que le format ESEF cherche à éviter.
2. Ancrages manquants sur les extensions légitimes
Quand une société crée une extension pour un concept non couvert, elle doit l'ancrer sur l'élément IFRS le plus proche via des relations "wider-narrower". Cet ancrage permet aux systèmes de traitement de données de comprendre le positionnement du concept dans la hiérarchie IFRS.
En 2020, de nombreux packages contenaient des extensions sans aucun ancrage, ou avec des ancrages pointant vers des éléments IFRS éloignés du concept décrit. L'outil de validation Arelle ne bloque pas toujours sur ce point : le fichier est techniquement valide mais sémantiquement incorrect.
3. Labels XBRL en doublon ou absents
Chaque élément XBRL doit porter un label lisible, généralement en anglais selon la convention taxonomie IFRS, et potentiellement une traduction locale. Sur ce premier exercice, des packages présentaient des labels dupliqués, des labels vides, ou des labels qui ne correspondaient pas au contenu balisé.
Exemple concret : un poste "Immobilisations corporelles nettes" balisé avec l'élément ifrs-full:PropertyPlantAndEquipment mais portant un label personnalisé "Actifs immobilisés" dans le package. La donnée machine dit une chose, le label dit autre chose. Un analyste qui extrait les données automatiquement ne peut pas s'y fier.
4. Éléments placés dans le mauvais contexte
En XBRL, chaque valeur est associée à un contexte : l'entité déclarante, la période (date d'arrêté pour un instant, ou période pour une durée), et l'éventuelle devise. Des erreurs fréquentes portaient sur des montants de bilan balisés avec un contexte "durée" au lieu d'un contexte "instant", ou inversement.
Ces erreurs ne sont pas toujours détectées par une validation de surface. Elles apparaissent quand on analyse les données extraites du package iXBRL.
5. Packages invalides à la validation Arelle
Arelle est l'outil de validation de référence pour les fichiers XBRL et iXBRL. Les règles de validation ESMA sont implémentées dans un plug-in dédié. Sur le premier exercice, certains packages déposés à l'AMF n'avaient simplement pas été passés par Arelle avant dépôt. Les autorités ont détecté des erreurs techniques basiques au moment du traitement : fichiers manquants dans le package ZIP, références cassées entre le document HTML et les fichiers taxonomie.
L'AMF a documenté les erreurs avant de sanctionner
L'AMF a publié ses premières recommandations sur l'ESEF avant même le premier exercice. Elle a rappelé les exigences du règlement délégué (UE) 2019/815 et les règles de validation ESMA à respecter.
Sur le bilan du premier exercice, l'AMF a adopté une posture pédagogique : les erreurs les plus fréquentes ont été documentées et publiées, mais les sanctions n'ont pas été la priorité immédiate. L'objectif était de permettre au marché de monter en compétence.
Cette tolérance ne voulait pas dire que les erreurs passaient inaperçues. L'ESMA exploite les données des packages pour alimenter ses bases de données financières européennes. Un balisage incorrect dégrade directement la qualité de ces données.
Une configuration approximative reproduit les mêmes erreurs chaque année
Un package peut passer la validation technique sans refléter la structure réelle des états financiers. L'écart entre les deux tient à la qualité de configuration de l'outil.
Sur Workiva, par exemple, la taxonomie étendue de la société est construite une fois dans l'outil. Chaque poste des états financiers est mappé sur un élément taxonomique, les extensions sont créées avec leurs ancrages, les contextes sont paramétrés. Quand le document est généré en iXBRL, le balisage découle directement de cette configuration.
Si la configuration est correcte, le package est correct. Si elle est approximative (mauvais éléments choisis, extensions sans ancrage, contextes incorrects), le package sera incorrect à chaque exercice.
Ce que ça signifie en pratique : une configuration Workiva bâclée en 2020 produisait un package techniquement valide mais sémantiquement douteux. La même configuration reproduisait les mêmes erreurs en 2021, en 2022 et après. Jusqu'à ce que quelqu'un audite la taxonomie et la reprenne à la base.
Un fichier qui passe Arelle n'est pas pour autant un fichier correct
Le premier exercice ESEF a tranché une question de méthode. Le format iXBRL se construit dans la logique de la taxonomie, pas comme une couche technique appliquée après coup sur un document existant.
Cette logique se travaille. Elle demande de comprendre la taxonomie IFRS, de maîtriser la structure XBRL, et de configurer l'outil poste par poste. La validation Arelle mesure la conformité technique du package. Elle ne dit rien de la fidélité du balisage aux états financiers réels.
Les sociétés qui ont investi dans une configuration solide dès 2020 ont ensuite mis à jour leur taxonomie chaque année sans repartir de zéro. Les autres ont accumulé des erreurs silencieuses. Elles les ont découvertes plus tard, à l'occasion d'un changement réglementaire ou d'un audit qui a imposé de tout reprendre.
