Convertir un registre Excel en xBRL-CSV DORA

Vous tenez votre registre sous Excel, mais le dépôt exige un package xBRL-CSV. Voici comment passer de l'un à l'autre — mapping des colonnes vers les tables, encodage des valeurs DPM, structure du package — sans reproduire les erreurs qui font rejeter.

En bref — Convertir un registre Excel en xBRL-CSV DORA se fait en six étapes : nettoyer le classeur, mapper chaque colonne vers une table B_xx.xx et son champ, encoder les valeurs selon le DPM (codes ISO, listes fermées, dates), générer les CSV UTF-8 avec le report.json, empaqueter en ZIP, puis valider avant dépôt.

Pourquoi un registre Excel ne se dépose pas tel quel

Excel est l'outil naturel pour construire le Registre d'Informations : on aligne les prestataires, les contrats, les fonctions, on ajoute des colonnes. Mais l'autorité n'accepte pas un classeur. Le dépôt se fait au format xBRL-CSV défini par l'EBA : un ensemble de fichiers .csv normalisés, structurés selon une taxonomie et un dictionnaire de données (le DPM), empaquetés avec un point d'entrée machine.

Convertir, ce n'est donc pas « exporter en CSV ». C'est transformer la structure et le contenu de votre classeur pour qu'ils correspondent, à la virgule près, à ce que la machine du régulateur attend. Une feuille Excel bien remplie mais mal traduite est rejetée sans interprétation.

Les 6 étapes de la conversion

Voici le chemin, de votre classeur à un package prêt pour le dépôt. Les étapes 1 et 5 relèvent de la mécanique ; les étapes 2 à 4 décident de l'acceptation.

1. Préparer le classeur. Une feuille par table, des en-têtes clairs, pas de lignes de titre, de cellules fusionnées ni de commentaires parasites. Retirez les lignes vides et les totaux calculés.
2. Mapper les colonnes vers les tables B_xx.xx. Chaque colonne de votre Excel doit trouver son champ dans l'une des 15 tables du registre.
3. Encoder les valeurs selon le DPM. Traduire les libellés en clair en codes attendus (pays, devise, criticité, dates, LEI).
4. Vérifier la cohérence inter-tables. Chaque référence d'accord, code prestataire ou identifiant de fonction doit pointer vers un enregistrement réellement déclaré ailleurs.
5. Générer le package. Produire les CSV en UTF-8, ajouter le report.json, respecter le nommage et empaqueter en ZIP.
6. Valider avant dépôt. Confronter le package aux règles de l'EBA pour corriger ce qui serait rejeté — avant, pas après.

Étape 2 — Mapper les colonnes vers les tables B_xx.xx

Votre classeur mélange souvent, sur une même feuille, des informations qui appartiennent à des tables différentes. La conversion consiste d'abord à éclater ces colonnes vers les bonnes tables. Le registre compte 15 modèles (B_01.01 à B_99.01), reliés par des clés étrangères, dont B_02.01 — les accords — est le pivot. Schématiquement :

Le point délicat : une référence d'accord saisie dans B_02.01 sera réutilisée comme clé dans B_02.02, B_04.01, B_07.01… Si votre mapping duplique ou décale ces références, le registre devient incohérent. Le détail des relations est expliqué dans le guide des tables et de leurs liens.

Étape 3 — Encoder les valeurs selon le DPM

C'est ici que la plupart des conversions échouent. Beaucoup de champs sont des listes fermées : ils n'acceptent qu'un code précis, pas un texte libre. « France » doit devenir FR, « euros » devient EUR, une date 31/12/2026 devient 2026-12-31. Les principales transformations :

À la main, il faut confronter chaque cellule à la liste de valeurs autorisées du champ, sur des centaines de lignes — le détail est couvert dans la page valeurs DPM et listes fermées. Le LEI mérite une attention particulière : il doit être valide et présent dans le registre GLEIF, sinon la ligne casse.

Étape 5 — Générer le package : ZIP + report.json

Une fois les tables mappées et les valeurs encodées, le dépôt n'est pas un fichier unique mais une archive structurée. Le nommage, l'arborescence, le point d'entrée et l'identifiant d'entité doivent être exacts :

Le report.json est le point d'entrée qui désigne le module DORA de l'EBA et liste les tables du dépôt. L'identifiant d'entité prend la forme rs:{LEI}.IND (ou .CON pour un dépôt consolidé). Chaque CSV doit être encodé en UTF-8, sans BOM inattendu. Une seule pièce manquante, mal nommée ou mal encodée et le package entier est invalide.

Les pièges de conversion les plus fréquents

• Export « brut » en CSV : séparateur point-virgule, encodage Windows-1252, dates au format local — tout ce qu'Excel produit par défaut est à corriger.
• Libellés en clair laissés dans des champs à liste fermée (« France », « critique », « oui/non » mal codés).
• Références orphelines : un code prestataire utilisé dans B_02.02 mais absent de B_05.01, ou une référence d'accord jamais déclarée dans B_02.01.
• LEI invalide, mal recopié, ou remplacé par le nom du prestataire.
• Table obligatoire manquante ou mal nommée dans l'archive.
• report.json absent ou incorrect, qui empêche la lecture du package.

Au dry run européen, environ 6,5 % (ESAs, 2024) des registres passaient du premier coup — presque jamais à cause du fond, mais de ces détails de conversion.

Pourquoi valider après avoir converti

Convertir la forme (Excel → CSV structurés) est la partie facile, et plusieurs outils gratuits le font. Le vrai sujet, c'est la conformité du contenu : valeurs DPM, cohérence inter-tables, complétude, LEI. Un package « bien converti » mais aux valeurs invalides est rejeté comme les autres. C'est pourquoi la validation contre les règles de l'EBA doit venir après la conversion et avant le dépôt — c'est le sujet détaillé de la page vérifier son registre DORA.

Le dépôt du registre est une obligation annuelle ; la date exacte de remise est à vérifier auprès de votre autorité compétente (en France, l'AMF ou l'ACPR, via la plateforme OneGate). Aucun outil ne peut garantir l'acceptation : la validation réduit le risque de rejet technique, elle ne remplace pas le contrôle officiel du régulateur.

Questions fréquentes

← Le guide complet du registre DORA