Recursos › Guía
Por qué se rechaza una presentación DORA
En la prueba de 2024, solo el 6,5 % de los 947 registros analizados superó los 116 controles de calidad — habían participado 1 039 entidades, y 92 envíos ni siquiera pasaron la integración (informe de síntesis de las AES, dic. 2024). Las demás no habían entendido mal el reglamento: habían formado mal un fichero.
Las Autoridades Europeas de Supervisión publican 120 reglas de control aplicadas al registro de información. No se ejecutan todas en el mismo momento, y ese orden es la clave: una presentación puede rechazarse antes de que se haya leído ni uno solo de sus datos. Este artículo recorre los cuatro niveles del control, en el orden en que se aplican, e indica en cada uno lo que falla con más frecuencia.
| Nivel | Reglas | Qué se examina |
|---|---|---|
| 1. Recepción | 12 | El archivo y su nombre. No se abre el contenido. |
| 2. Estructura CSV | 18 | Los ficheros técnicos y las declaraciones de plantillas. |
| 3. Técnico DPM | 11 | Tipos de datos, listas cerradas, cardinalidades. |
| 4. Negocio | 71 | La coherencia del registro en sí. |
Las ocho reglas restantes se refieren a la validez de los identificadores ante GLEIF y BRIS; volvemos sobre ellas al final, porque su estatuto particular es fuente de malentendidos.
Nivel 1 — La recepción: doce reglas antes de cualquier lectura
Estos controles se aplican al archivo en tanto que fichero. Un registro impecable dentro de un archivo mal nombrado se rechaza aquí, sin más mensaje. Se refieren a la extensión y la integridad del archivo, los caracteres permitidos en su nombre, la estructura de ese nombre segmento a segmento, la coherencia del módulo y del país, la validez de la fecha de referencia, la unicidad del envío, el tamaño y la codificación.
Cada uno de esos puntos, con la convención de nombres exacta y el árbol de ficheros esperado dentro del paquete, se detalla en el artículo dedicado al nombre y a la estructura del fichero.
Alrededor de un tercio de los rechazos observados en la prueba nunca pasó de este nivel. Son errores de nombre y de empaquetado, no de conformidad — y son los más frustrantes, porque no enseñan nada sobre el fondo.
Nivel 2 — La estructura: lo que el archivo debe contener
Una vez abierto, el archivo debe presentar tres ficheros técnicos en una ubicación exacta.
reports/report.json— los metadatos y la taxonomía a la que se dirige;reports/FilingIndicators.csv— la lista de las plantillas que usted declara transmitir;reports/parameters.csv— los parámetros de la presentación.
Los indicadores de presentación son el punto peor entendido. Ese fichero no contiene sus datos: declara, para cada plantilla, si la transmite o no. Las reglas asociadas son severas:
- el número de columnas debe ser exacto;
- una plantilla solo puede declararse una vez;
- solo se admiten valores booleanos —
true,false,1,0; - un código de plantilla presente sin valor asociado es un error por sí mismo.
Del lado de los parámetros, un control merece mención propia: el parámetro entityID debe existir y su valor coincidir con el nombre del fichero. Una entidad que renombra su archivo después de generarlo rompe esa correspondencia sin saberlo. Además, la línea de cabecera de parameters.csv debe contener exactamente name y value, en ese orden.
Por último, los ficheros de datos deben llevar nombres de tabla válidos: B_02.02.csv, no contratos.csv.
Una última regla de este nivel es la más lacónica del catálogo: «No data was integratable». Significa que el paquete era formalmente aceptable y que no se pudo extraer nada de él. Es el rechazo menos instructivo que existe.
Nivel 3 — Los controles técnicos DPM
Once reglas comprueban que cada valor respeta el modelo de datos: tipo esperado, pertenencia a una lista cerrada, cardinalidad, unicidad de los identificadores de fila.
Las listas cerradas causan la mayor parte de los fallos, y siempre del mismo modo. La taxonomía espera un código, la persona escribe una palabra:
| Introducido | Esperado | Columna |
|---|---|---|
| España | ES | País (ISO 3166-1 alfa-2) |
| Euro | EUR | Moneda (ISO 4217) |
| Nube | un código de la lista | Tipo de servicio TIC |
| Sí / No | el código de la lista | Cualquier columna booleana del DPM |
Ninguna de esas entradas es absurda. Todas se rechazan. Esa es la razón de ser de las listas desplegables en una herramienta dedicada: hacen el error imposible en lugar de detectable.
Nivel 4 — Las 71 reglas de negocio
Es el núcleo del control, y el único nivel que se refiere realmente a la calidad de su registro. Estas reglas comprueban la coherencia entre las plantillas. Tres familias aparecen constantemente.
Las referencias huérfanas
Una referencia de acuerdo contractual (CAR) citada en B_02.02, B_03.01 o B_07.01 debe existir en B_02.01. Un proveedor citado en una cadena de subcontratación debe existir en B_05.01. Una entidad usuaria debe figurar en el ámbito. Cada enlace roto es un error, y un identificador mal copiado suele producir varios de golpe.
Las obligaciones condicionales
Aquí se aloja el error más caro del registro. Declare una función crítica o importante en B_06.01 y columnas hasta entonces opcionales pasan a ser obligatorias en B_02.02: ley aplicable, preaviso de resolución por ambas partes, país de conservación de los datos, nivel de dependencia. Y una evaluación pasa a ser exigible en B_07.01.
Nada en una hoja de cálculo le avisa de ese cambio. Usted marca una casilla en una pestaña y seis columnas se vuelven obligatorias tres pestañas más allá. El control, en cambio, lo recuerda perfectamente.
Las coherencias aritméticas y lógicas
Una entidad que no es una sociedad holding debe declarar un balance total, y ese total exige la moneda correspondiente. Una fecha de fin de contrato no puede preceder a su fecha de inicio. Un rango de subcontratación no puede saltarse un escalón.
El caso particular de los identificadores
Ocho reglas comprueban la existencia real de los identificadores: seis para el LEI ante GLEIF (VR_2, VR_12, VR_23, VR_71, VR_77), dos para el EUID ante BRIS (VR_72, VR_78).
Esas reglas están marcadas como «do not run rule» por las propias autoridades, a falta de acceso garantizado a esas bases en el momento del control. La conclusión que muchos extraen de ello es errónea.
Lo que significa realmente: un LEI bien formado pero falso — el de una filial vecina, o el de una entidad dada de baja — supera los controles automáticos sin una palabra. Solo se detectará después, por un examinador humano, en un intercambio bastante menos agradable que un mensaje de error.
La validez formal, en cambio, se comprueba de inmediato y sin conexión: veinte caracteres, alfabeto restringido, dos dígitos de control ISO 7064. No hay ninguna razón para presentar un LEI cuya clave de control sea falsa — y sin embargo ocurre, porque una hoja de cálculo no calcula claves de control.
Lo que conviene retener
Las 120 reglas no ponen a prueba su comprensión de DORA. Ponen a prueba el rigor mecánico de un fichero: un nombre, una estructura, unos códigos, unas referencias cruzadas. Es exactamente el tipo de trabajo que una persona hace mal y que un programa hace perfectamente.
El método correcto cabe en una frase: reproducir los controles antes de presentar, en el orden en que la autoridad los aplicará, y corregir hasta llegar a cero errores. Es lo que hace Obligia — 113 reglas de las 120 publicadas. Las 7 restantes quedan fuera de ámbito, cada una por un motivo publicado: dos solo puede evaluarlas la autoridad destinataria, dos restringen tablas cerradas que el registro DORA no contiene, dos están marcadas «no ejecutar» por las AES, y la última solo tiene sentido en el momento de la presentación.
Para profundizar: el registro de información, plantilla por plantilla y el formato xBRL-CSV explicado con sencillez.
Crear mi registro Reservar una demostración ›
Esta guía es información general y no asesoramiento regulatorio; la responsabilidad de la presentación corresponde a la entidad.