Recursos › Guía

xBRL-CSV, explicado con sencillez

La palabra asusta, y es una lástima, porque la cosa es sencilla. xBRL-CSV no es un lenguaje que haya que aprender. Es una convención de empaquetado: ficheros CSV corrientes, ordenados de una determinada manera, acompañados de dos o tres ficheros que explican lo que contienen.

Este artículo describe lo que hay realmente en el paquete, por qué lo exigen las autoridades y qué ocurre si intenta fabricarlo a mano desde Excel.

De dónde viene este formato

XBRL — eXtensible Business Reporting Language — es el estándar mundial de la información financiera estructurada. Existe desde principios de los años 2000 y se usa para los estados financieros, las declaraciones prudenciales y los informes de sostenibilidad.

Su forma histórica es el XML: potente, verboso y penoso de producir. Una presentación XBRL clásica pesa decenas de megabytes para unos pocos miles de valores.

xBRL-CSV es la respuesta a ese reproche. Mismo modelo de datos, misma taxonomía, mismo rigor — pero los valores se escriben en ficheros CSV legibles por cualquier hoja de cálculo, y solo un pequeño fichero JSON describe cómo enlazarlos con el modelo. Es bastante más ligero y, sobre todo, inspeccionable a simple vista.

Para el registro de información DORA, las Autoridades Europeas de Supervisión eligieron esta variante. Un punto merece señalarse: las reglas de recepción precisan que la presentación DORA debe ser un zip que contenga plain-csv — aquí la variante XML no se acepta.

Qué hay en el paquete

Descomprima un archivo conforme y encontrará esto:

Nada esotérico. Cada fichero de datos es un CSV cuyas columnas llevan los códigos de la taxonomía — 0010, 0020, 0030 — y no sus etiquetas en español o en inglés. Es la primera diferencia con una hoja de cálculo corriente.

El manifiesto

report.json indica con qué taxonomía debe interpretarse el paquete. Es lo que permite a la autoridad saber que su columna 0110 de B_01.02 es un balance total expresado en la moneda de la columna 0100. Sin él, los CSV son solo cifras sin significado.

Los indicadores de presentación

FilingIndicators.csv se malinterpreta con frecuencia. No contiene ningún dato de negocio: declara, para cada plantilla, si usted la transmite. Una plantilla declarada true pero ausente es una incoherencia; una plantilla presente pero no declarada, también.

Las restricciones son estrictas: número exacto de columnas, una plantilla declarada una sola vez, únicamente valores booleanos (true, false, 1, 0), y nunca un código de plantilla sin su valor.

Los parámetros

parameters.csv cabe en unas pocas líneas, con una cabecera que debe contener exactamente name y value. El parámetro decisivo es entityID: su valor debe coincidir con el nombre del fichero. Renombrar el archivo después de generarlo rompe esa correspondencia y hace fracasar la presentación.

El nombre del archivo

El nombre no es decorativo. Se analiza segmento a segmento:

Asunto_País_CódigoMarcoVersiónMódulo_Módulo_FechaDeReferencia_MarcaDeTiempo.zip

Extensión .zip obligatoria; caracteres limitados a los alfanuméricos, el guion, el guion bajo y el punto; fecha de referencia en formato aaaa-mm-dd, válida y nunca en el futuro; nombre único — un nombre ya enviado se rechaza aunque el contenido haya cambiado.

Por qué hacerlo a mano sale mal

Nada de lo anterior es intelectualmente difícil. Ese es precisamente el problema: cada paso es sencillo, son muchos, y ninguno perdona.

• Las cabeceras. Sus columnas deben llevar los códigos de la taxonomía, no sus rótulos de negocio. Una exportación de Excel produce sus rótulos.
• Las listas cerradas. ES y no «España», EUR y no «Euro», un código de servicio y no «alojamiento». Una hoja de cálculo no lo sabe.
• Los separadores y la codificación. Excel con configuración española exporta de buena gana en punto y coma y en Windows-1252. El paquete espera UTF-8.
• Los números. Una coma decimal, un separador de miles, un espacio duro copiado de un informe — otros tantos valores inválidos.
• Los indicadores de presentación. Deben corresponderse exactamente con los ficheros presentes.
• El nombre del fichero. Una convención que hay que respetar carácter a carácter, con una marca de tiempo coherente.
• Las referencias cruzadas. Los identificadores deben corresponderse de un fichero a otro. Un copiar y pegar desplazado una fila lo rompe todo, en silencio.

Cada uno de esos puntos es verificable. Ninguno es visible en una hoja de cálculo. Por eso, en la prueba de 2024, solo el 6,5 % de los 947 registros analizados superó los 116 controles de calidad, y por eso las consultoras facturan estas presentaciones con cinco cifras: no venden una experiencia regulatoria, venden paciencia mecánica.

Qué aspecto tienen realmente esos ficheros

Los tres ficheros técnicos caben en unas pocas líneas. Este es su aspecto, despojado de la jerga.

FilingIndicators.csv solo contiene dos columnas: el código de la plantilla y un booleano que dice si usted la transmite. Una entidad que no tiene sucursales declarará B_01.03 como false y no adjuntará el fichero correspondiente. Declarar true sin adjuntar el fichero, o al revés, es una incoherencia que se detecta de inmediato.

parameters.csv es aún más corto: una cabecera name,value y después los parámetros. El que cuenta es entityID, cuyo valor debe coincidir con el nombre del archivo. Es el vínculo entre el contenido y su empaquetado, y es también el control que rompe con más frecuencia un renombrado bienintencionado: «le añado _v2 para no perderme».

Los ficheros de datos, por su parte, llevan por cabecera los códigos de columna de la taxonomía. En B_01.02.csv, la columna 0100 es la moneda y la columna 0110 el balance total. Un lector humano no entiende nada sin la documentación; un validador, en cambio, no necesita nada más. Es un formato escrito para las máquinas, y lo asume.

Qué hacer con una presentación rechazada

Un rechazo no se corrige reenviando el mismo fichero. Dos reglas lo impiden: el nombre debe ser único — un nombre ya enviado se rechaza aunque el contenido haya cambiado — y la marca de tiempo de creación debe, por tanto, regenerarse.

El procedimiento es, pues: corregir el dato, regenerar íntegramente el paquete con una nueva marca de tiempo y volver a presentar. Modificar un CSV dentro del archivo existente y recomprimirlo produce casi siempre un segundo rechazo, porque el nombre no ha cambiado.

Y sobre todo: no cuente con el mensaje de error para instruirse. Algunos son precisos, otros se limitan a «No data was integratable». La única forma fiable de saber qué falla es reproducir los controles antes de presentar, en su casa, donde puede iterar en unos segundos en lugar de en unos días.

Una observación sobre los tamaños

El límite de recepción es de 10 GB. El registro de una entidad de tamaño medio pesa unas pocas decenas de kilobytes. Si su paquete se acerca al megabyte, algo no va bien: suelen ser filas vacías exportadas por una hoja de cálculo, o una plantilla duplicada.

Lo que produce Obligia

Usted introduce o importa sus datos en una interfaz que conoce las listas cerradas y rechaza un valor inválido en el momento de teclearlo. La herramienta reproduce después los controles de las autoridades, le enumera lo que bloquea y solo autoriza la exportación cuando la cuenta llega a cero.

El paquete producido lleva el nombre que marca la convención, está codificado en UTF-8 y contiene sus tres ficheros técnicos y un CSV por cada plantilla rellenada. Usted lo presenta tal cual.

Para profundizar: el registro de información, plantilla por plantilla y por qué se rechaza una presentación.

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.