Mejorando XBRL para el modelado de datos

¿Cómo se puede mejorar XBRL para ayudar a los autores de taxonomías para sistemas de informes de gran tamaño?

Un artículo reciente identificó el potencial de conflicto entre los enfoques de modelado de XBRL y la Metodología de Puntos de Datos (DPM). Sin embargo, ninguna discusión estaría completa sin revisar por qué la Autoridad Bancaria Europea (EBA) y la Autoridad Europea de Seguros y Pensiones Ocupacionales (EIOPA) optaron por utilizar DPM y luego traducir a una taxonomía XBRL, en lugar de comenzar con XBRL en primer lugar.

¿Fue una falta de funciones en XBRL, fue una falta de comprensión o simplemente una falta de herramientas? Este artículo sostiene que todavía faltan algunas características, muchas de las cuales están en el plan de trabajo del Modelo de Información Abierto (OIM) de XBRL International. pero aún no se han abordado algunos temas como el «control de versiones».

La otra idea clave es que no parece haber ningún incentivo para que los proveedores de software creen el tipo de herramientas de modelado de datos que necesitan los grandes autores de taxonomías XBRL.

Al revisar los requisitos clave de los grandes marcos de presentación de informes, como los de EBA CRD y EIOPA Solvency, este documento evalúa el estado de las especificaciones XBRL para cumplirlos y permitir que XBRL proporcione capacidades de gestión de datos maestros para los marcos de presentación de informes.

Se puede encontrar una versión PDF en — www.ubpartner.com

Los beneficios y problemas de XBRL

Las especificaciones XBRL están diseñadas para dar soporte a un conjunto diverso de aplicaciones de generación de informes de información empresarial en todo el mundo. Actualmente existen más de doscientos marcos de generación de informes XBRL importantes creados en torno a este estándar abierto, existe una gran comunidad de expertos y una gama cada vez mayor de proveedores de software.

Una de las fortalezas de los estándares XBRL, aparte del núcleo común, es su independencia entre sí, lo que permite a los diseñadores de taxonomías XBRL elegir las especificaciones que desean utilizar. Sin embargo, su debilidad es que el desarrollo como especificaciones independientes significa que hay poca interoperación entre ellas.

Esto es particularmente notorio para los desarrolladores de grandes marcos de generación de informes. Para ayudar a entender cuáles son los problemas específicos, vale la pena revisar los comentarios de la EBA durante sus recientes presentaciones sobre DPM 2.0, también conocido como «DPM Refit». La EBA presentó un caso para profundizar el uso de DPM frente a un enfoque XBRL más estandarizado. La diapositiva siguiente es un ejemplo de cómo comparan su DPM con XBRL.

Creemos que muchas de las observaciones de la EBA están sesgadas debido a su decisión de basar su sistema interno de almacenamiento de datos en DPM. Responderíamos en nombre de la comunidad XBRL que:

La taxonomía XBRL producida por las herramientas DPM no proporciona una guía semántica obvia para las definiciones, ya que está compuesta por unos pocos conceptos de alto nivel y desglosada en numerosas dimensiones; por ejemplo, existe globalmente un concepto para «activos», mientras que la taxonomía IFRS tiene muchos tipos. de activos que son subconjuntos del concepto más amplio. La taxonomía de la Directiva sobre riesgo de crédito (CRD) de la ABE es el llamado «modelo altamente dimensional». Bueno para las computadoras, pero deficiente para ayudar a la comprensión del lector, lo cual es importante para transmitir requisitos en sistemas de informes heterogéneos.
El proceso DPM también genera numerosas reglas de bajo nivel para comprobar la calidad de los datos, en lugar de una regla semántica de alto nivel, como «todos los totales deben sumar». Comprobar la coherencia de un volumen tan grande de reglas DPM de bajo nivel (alrededor de 8.000) de forma automatizada es algo dudoso.
Muchas de las diferencias citadas en la diapositiva de la EBA están relacionadas con la implementación específica, por lo que cuestiones como la integración y los identificadores invariantes solo existen según el punto de vista del observador.

Sin embargo, el problema del «versionado» es real. XBRL incluye una versión superficial y pautas de mejores prácticas para documentar las diferencias entre versiones, pero nada más. En contra de esto, la afirmación de la EBA de que DPM apoya la «historización» de conceptos se basa en su implementación patentada de DPM. Si XBRL va a proporcionar alguna forma de ‘gestión de datos maestros’ para grandes marcos de informes, entonces el control de versiones es una característica crítica. Sin embargo, vale la pena señalar que el intercambio de datos tiene requisitos de versiones diferentes a los de los sistemas de análisis de datos, como se analiza con más detalle más adelante, pero el requisito es importante para todos los sistemas XBRL.

La EBA también tiene previsto adoptar el nuevo modelo de información abierta (OIM) de XBRL y, en particular, el formato xBRL-CSV para los envíos con el fin de reducir el tamaño de los archivos de los informes. Sin embargo, una vez más, en lugar de centrarse en mejorar el diseño y el potencial de rendimiento de XBRL, ha optado por utilizar una estructura CSV que utiliza explícitamente el «DPM-ID», una construcción del sistema de almacenamiento de datos de la EBA que está semánticamente «vacío» y no proporciona ninguna ayuda para optimizar el procesamiento de XBRL. Para obtener más información sobre este enfoque y por qué creemos que es una mala idea, consulte el artículo anterior «DPM vs XBRL».

Entonces, hoy en día, si la EBA comenzara de nuevo, la gran pregunta sería: «¿Seguirían usando DPM para definir el modelo de los datos a recopilar o usarían XBRL?».

Nuestra opinión es que la EBA todavía encontraría una falta de herramientas de «desarrollo de taxonomía» con las que construir un «buen» modelo semántico que sea fácil de mantener. Creemos que la iniciativa OIM es un gran paso en la dirección correcta, pero las especificaciones XBRL independientes aún obstaculizan el proceso. Las siguientes secciones revisan los detalles de OIM y hacia dónde se dirigen, además de algunas recomendaciones para mejorar las capacidades de modelado XBRL.

Por ahora, el DPM funciona para la EBA y la EIOPA como un mecanismo útil para sus sistemas internos (podrían utilizar mejor XBRL, pero eso es para más adelante). El verdadero problema que la EBA revela a la comunidad XBRL es que definir marcos de información a gran escala en XBRL es un proceso en gran medida manual y complejo. Otros marcos de gran tamaño, como la taxonomía IFRS, experimentan problemas similares. Entonces, ¿qué se debe mejorar?

Estándares OIM y Future xBRL

El Modelo de Información Abierta (OIM, por sus siglas en inglés) es un esfuerzo estratégico de XBRL International para simplificar y modernizar aspectos importantes del Estándar XBRL mediante la definición de un modelo que represente el significado del estándar, sin referencia a una sintaxis específica, es decir, elimina la dependencia de XML. El OIM define formatos múltiples e intercambiables, que pueden ir modificándose con el tiempo.

xBRL-CSV: condensa los datos en un formato tabular muy compacto para permitir la recopilación de grandes cantidades de datos.
xBRL-JSON: proporciona datos XBRL en un formato más sencillo de procesar y presentar.
xBRL-XML: sigue admitiendo una amplia gama de requisitos de generación de informes.

Las habilidades y el esfuerzo para desarrollar reglas para validar los datos (fórmulas XBRL) han demostrado ser otra área de preocupación para los autores de taxonomías. El XBRL Standards Board (XSB) ha proporcionado recientemente un camino a seguir para las fórmulas XBRL en un mundo OIM:

Comenzando con Fórmula 2.0, que eliminará la sintaxis XPath y formalizará la especificación de XF, o Fórmula basada en texto, que proporciona la misma funcionalidad que la Fórmula XBRL, pero es más rápida de escribir y más fácil de leer.
Finalmente, el plan es desarrollar una nueva especificación que incluirá reglas tanto para la instancia XBRL como para la taxonomía, basándose en las nuevas especificaciones de taxonomía de OIM. Esto también implica un cambio de nombre a «Reglas XBRL 3.0» para reconocer su importancia.

De manera confusa para algunos, en XBRL existe otra manera de verificar relaciones simples de los datos proporcionados usando la especificación de Cálculo. Idealmente, esto debería proporcionar un mecanismo más simple para definir los principales ‘controles de calidad’ que se encuentran en los modelos de informes financieros, por ejemplo, roll-ups, roll-forward y agregaciones. La especificación de cálculo se está actualizando y el plan para la versión 2.0 incluye capacidades de agregación dimensional. La fórmula XBRL entonces solo se usaría para reglas más complejas, así como para validaciones estructurales.

La OIM mantendrá esta flexibilidad para los autores de taxonomías, pero aún deja preguntas como «¿Debería utilizar fórmulas o cálculos XBRL?»:

La EBA desarrolla la fórmula XBRL a partir de su notación DPM, que los usuarios empresariales definen como parte de sus plantillas de hojas de cálculo, pero no describe las relaciones inherentes en las tablas ni utiliza cálculos para sumar jerarquías básicas.
La taxonomía NIIF en la que se basa el ESEF de la Autoridad Europea de Gestión de Valores (ESMA) utiliza cálculos y fórmulas, pero no utiliza tablas. En marcos de ‘Informes abiertos’ como ESEF, el emisor desarrolla sus propias estructuras de tablas. Un modelado deficiente de estos significa que los cálculos a menudo se omiten o se incluyen solo parcialmente en la taxonomía, lo que genera numerosos problemas de calidad de los datos.

Entonces, ¿OIM llega lo suficientemente lejos? Creemos firmemente que es necesario que la comunidad XBRL reflexione un poco más sobre cómo los hipercubos, las tablas, los cálculos y las fórmulas pueden trabajar juntos para ayudar a ofrecer mejores modelos XBRL.

Gestión de grandes marcos de informes

Si se va a utilizar XBRL para modelar sistemas de recopilación a gran escala, entonces debemos volver a algunas de las cuestiones subyacentes planteadas por la EBA, la EIOPA y las ANC europeas, que no sólo implementan la recopilación de informes de la EBA y la EIOPA de miles de los bancos y empresas de seguros europeos, sino que también los amplían a los requisitos de presentación de informes locales.

Es un área muy amplia para cubrir, por lo que es mejor comenzar dividiendo los temas en subáreas más pequeñas:

Desarrollo y mantenimiento de taxonomía.
Versionado
Archivos grandes
Una gran cantidad de fórmulas XBRL complejas

Desarrollo y mantenimiento de taxonomía

El modelado de datos es, sin duda, la decisión más importante para un equipo de generación de informes de datos. Determina la arquitectura y el camino que seguirá el proyecto. El modelado de conjuntos de datos grandes y complejos siempre ha planteado a los diseñadores decisiones y problemas.

Las taxonomías XBRL de gran tamaño (diccionarios de datos) pueden hacer referencia a otras taxonomías XBRL (eXtensibles) como bloques de construcción y pueden separarse en numerosos puntos de entrada, cada uno de los cuales contiene múltiples definiciones de tabla o ELR, que facilitan el modelado de las partes individuales. Esto ayuda, pero no es suficiente para ayudar realmente a los diseñadores a desarrollar un modelo semántico «bueno» y de alto rendimiento y gestionarlo a lo largo del tiempo, ni incentiva a los desarrolladores a crear el tipo de herramientas que respaldarían a los diseñadores en este proceso, como.

La especificación de dimensiones XBRL se utiliza para definir hipercubos, mientras que las bases de vínculos de tabla pueden utilizar las dimensiones y pueden vincularse a hipercubos; sin embargo, cada base de vínculos de tabla debe especificarse de forma independiente, es decir, codificarse. Más código equivale a más desarrollo y más mantenimiento. ¿Por qué no existe la posibilidad de producir una especificación de base de vínculos de tabla directamente a partir del hipercubo de informes? Esto animaría a los diseñadores de taxonomías a pensar detenidamente en la estructura del hipercubo y las tablas.
La especificación Table Linkbase define una capa de presentación tabular para renderizado. Sin embargo, no proporciona ninguna ‘aritmética tabular’ simple, como totales de filas, totales de columnas o subtotales. Esta idea de ‘agregación dimensional’ se ha propuesto antes y ha resurgido en Cálculos 2.0. El diseñador podría usar el código de fórmula hoy en día, como lo muestra la EBA, pero si el proceso está automatizado y es parte del modelo subyacente, entonces se reduce el código y los diseñadores de taxonomía estarán más estructurados en sus diseños de tablas.
Los diseñadores están claramente interesados en los formatos xBRL-CSV y xBRL-JSON. Añadir algunas ideas simples para ayudar a crear y gestionar definiciones a lo largo del tiempo reduce el código y pone el foco en el modelo:
o Método para la generación directa de xBRL-CSV a partir de definiciones de tablas e hipercubos.
o Vinculación bidireccional de definiciones de Table Linkbase y xBRL-CSV.
o Representación directa de datos xBRL-CSV en tablas definidas por Table Linkbase.

Creemos que la incorporación de características tan simples garantiza que las especificaciones XBRL se vinculen entre sí de una manera más coherente y solidaria, es decir, que «reunifiquen» los módulos de especificación individuales. Podríamos llamar a esto «gestión maestra de informes», lo que sugiere una forma más estructurada y metódica de desarrollar una taxonomía, en lugar de utilizar una «mezcolanza» de diferentes herramientas.

Versionado

Con el tiempo, todos los marcos de presentación de informes se desarrollarán y cambiarán a medida que sea necesario actualizar los elementos, la arquitectura, las reglas y las especificaciones utilizadas. Desde una perspectiva XBRL, dos áreas han sido el foco del Grupo de Trabajo de Mejores Prácticas XBRL:

Cómo comunicar los cambios entre versiones de taxonomía: más detalles en https://www.xbrl.org/guidance/communicate-taxonomy-changes/
Cómo gestionar las versiones de taxonomía: para ver mayores detalles véase https://www.xbrl.org/guidance/communicate-taxonomy-changes/

Para la mayoría de los proyectos XBRL que implican el intercambio de información empresarial, estos son suficientes. Aunque no existe ninguna especificación técnica que permita que el software actualice automáticamente los sistemas de la versión antigua a la nueva de la taxonomía.

La visión de la EBA sobre el ‘versionamiento’ es mucho más profunda. Quieren revisar cuándo se hizo referencia por primera vez a un «concepto» (punto de datos), cuándo se modificó y cuándo quedó obsoleto, además de saber quién realizó el cambio y por qué. Por lo tanto, su visión se acerca mucho más a la «Gestión de datos maestros», donde se recopilan metadatos sobre el modelo para que el modelo en sí pueda revisarse.

Cabe señalar que la EBA confunde las cosas cuando afirma que «… (XBRL) no puede manejar la evolución de un punto de datos entre versiones, lo que los hace inadecuados para los análisis de series temporales. Creemos que esto confunde los sistemas de recopilación con los sistemas de análisis. Los sistemas de análisis requieren un enfoque diferente, ya que los datos de origen llegan en muchos canales diferentes, deben transformarse y almacenarse de una manera específica para que sean eficientes para el análisis, como las series temporales. En los sistemas de recopilación, la cuestión es cómo facilitar a los remitentes saber qué datos recopilar, cómo comprobar su validez y cómo hacer que el proceso de transferencia sea eficiente. Estos dos objetivos pueden entrar en conflicto, por lo que la mayoría de las organizaciones dividen los dos sistemas.

Los beneficios para XBRL de un modelo de taxonomía más detallado y control de versiones de elementos son:

Proporcionar un método estandarizado para que los proveedores de XBRL actualicen los materiales asociados con una versión más nueva de la taxonomía ayudaría y reduciría significativamente los costos para los proveedores y, por lo tanto, para los usuarios.
Comprender cómo las definiciones y reglas de los datos han cambiado con el tiempo proporciona información importante para el análisis y la toma de decisiones operativas.

Es cuestionable qué tan importante es esto para la mayoría de los proyectos XBRL, pero para marcos de informes más complejos y más grandes, claramente ayudaría a su gestión. Una advertencia es que agregar ‘versiones’ a XBRL es una tarea grande y algo que necesitaría un ‘caso de uso’ de la vida real como guía.

Rendimiento de validación de grandes conjuntos de datos

Las preocupaciones sobre el tiempo de procesamiento de informes grandes siempre han estado presentes, pero el tamaño de lo que se define como un archivo de datos «grande» ha aumentado exponencialmente. Cualquier prueba de rendimiento dependerá del entorno en el que se ejecuta, es decir, si se le da al programa más memoria y más rendimiento de la CPU, debería ejecutarse más rápido. Por lo tanto, la pregunta debería reformularse como «¿Está funcionando de manera eficiente?» para que escale.

Cuando se analiza el rendimiento en grandes marcos de informes, como EBA CRD y EIOPA Solvency, los problemas aparecen principalmente con conjuntos de datos basados en registros, expresados como tablas «abiertas». Una tabla abierta es aquella en la que hay un número ilimitado de filas, columnas u hojas. El formato de registro o los datos transaccionales a menudo se organizan en una fila por registro, es decir, se agrupan en una fila múltiples hechos relacionados. En otras tablas, que contienen relativamente pocos puntos de datos agregados, el rendimiento siempre ha sido bueno para la mayoría de los procesadores XBRL.

La especificación xBRL-CSV se desarrolló específicamente para manejar los problemas resultantes de grandes conjuntos de datos basados en registros. En primer lugar, comprime los datos, por lo que los archivos de informes son más pequeños y más fáciles de transmitir. En segundo lugar, si la estructura CSV sigue el diseño de la tabla, es decir, según su «formato de registro», entonces los datos podrían leerse como filas, lo que proporciona una agrupación «natural» de los datos asociados, mejorando significativamente el rendimiento de las fórmulas XBRL en archivos grandes. mesas abiertas.

Esto proporciona una enorme mejora de rendimiento con respecto a xBRL-XML, donde dichas tablas se expresan como un único hecho por fila y un procesador XBRL debe «reagrupar» las filas individuales, lo que obliga a procesadores como el XPE de UBPartner a emplear un «optimizador» para determinar la mejor manera de agrupar. y filtrar los datos para una fórmula determinada.

Tenga en cuenta que, cuando se combinan grandes conjuntos de datos con numerosos controles de calidad de datos de bajo nivel, como los creados con el DPM de la EBA, se observa un aumento de los tiempos de procesamiento. Lamentablemente, el enfoque propuesto por la EBA para la recopilación de datos CRD en xBRL-CSV no ayuda, ya que decidió por primera vez introducir por completo la notación DPM directamente en el modelo XBRL seleccionando el siguiente formato xBRL-CSV fijo:

DPM_ID, Valor, Unidad

Esto es como el modelo xBRL-XML de un hecho por línea y luego agregar una búsqueda adicional utilizando el ‘DPM-ID’ semánticamente vacante como clave en el archivo CSV. Una indirección que, desde el punto de vista de las autoridades nacionales competentes y los remitentes, no ofrece ventajas. En cambio, restringe el rendimiento de la validación y dificulta la conversión entre otros formatos.

La incorporación de capacidades semánticas, como la aritmética tabular, en el modelo subyacente ayuda a los procesadores XBRL a comprender la estructura de los datos con los que están trabajando y luego se pueden formalizar los «optimizadores» para mejorar el rendimiento en función de los datos y su estructura.

Lo anterior también debe vincularse con la especificación del Indicador de presentación de XBRL, que también proporciona un mecanismo para ayudar a dividir grandes conjuntos de datos en secciones lógicas más pequeñas. Estas secciones lógicas pueden vincularse a las tablas y a los conjuntos de fórmulas. Poder identificar las subsecciones adecuadas de los datos y sus construcciones de taxonomía asociadas permite a los procesadores XBRL:

Reducción del alcance de fórmulas y cálculos, que actualmente apuntan al conjunto de datos completo.
Oportunidad de dividir el procesamiento en operaciones más pequeñas, que utilizan un subconjunto del modelo y los datos y tienen el potencial de procesarse independientemente.

Mejoras en la fórmula XBRL

La capacidad de incorporar reglas de validación en una taxonomía es una de las características más poderosas de XBRL para el intercambio de datos y la fuente de una mejor calidad de los datos. Hoy, como se mencionó, tenemos dos métodos: cálculos y fórmula XBRL. La primera es simple y fácil de implementar, pero limitada, mientras que las fórmulas XBRL ofrecen mucho más, pero son difíciles de desarrollar, ya que están ligadas a XML. Además, un diseñador de una taxonomía ‘abierta’, como ESMA ESEF o US GAAP, actualmente no puede escribir reglas para verificar la extensión de la taxonomía creada por el emisor.

En respuesta al último problema, XBRL US ha creado su propio sistema de reglas (DQR) con una tecnología diferente, XULE. Si bien esto proporciona una solución inmediata, no ayuda a la estandarización en toda la comunidad XBRL.

Como se destacó anteriormente, XSB anunció recientemente la Fórmula 2.0, eliminando la dependencia de XML y formalizando el uso de XF (fórmula basada en texto). XBRL Rules 3.0 planea romper con las especificaciones existentes y se espera que aproveche en gran medida la experiencia adquirida por XBRL US. Lo anterior debería ayudar significativamente a los diseñadores de taxonomía y permitir una definición más sencilla de reglas comerciales de calidad con las que verificar el documento de instancia y cualquier extensión de taxonomía.

Además, XBRL Europa ha reconocido que la arquitectura DPM de la EBA y la EIOPA tiene ciertas características específicas con tres modelos en uno: puntos de datos, plantillas y dimensiones semánticas que necesitan un «puente» para ayudar a pasar a las nuevas características XBRL. Ha creado un grupo de trabajo para revisar ‘XF-DPM’, lo que ayudaría a traducir entre las reglas DPM y las fórmulas XBRL, pero también posiblemente mejoraría el rendimiento de las fórmulas XBRL resultantes. Sin embargo, todavía se vería afectado por la definición de ‘controles de calidad de datos’ a nivel de punto de datos, por lo que produciría muchos de estos, en lugar de utilizar la semántica incorporada en un modelo XBRL dimensional.

Conclusiones

XBRL continúa creciendo y brinda soporte a una gama cada vez más amplia de marcos de informes. OIM es un paso crucial para garantizar el futuro al admitir formatos alternativos; sin embargo, el XSB también debe centrarse en recomendaciones que simplifiquen y requieran menos recursos para diseñar y desarrollar una taxonomía XBRL que sea consistente y eficaz.

Cuando la EBA y la EIOPA comenzaron su andadura en XBRL, este sistema ofrecía un método basado en estándares para recopilar los datos que necesitaban para supervisar su mercado. Sin embargo, XBRL no contaba con las características que les permitieran modelar los datos en XBRL, y en su lugar utilizaron DPM como herramienta de modelado. Ahora hay pocos incentivos para cambiar esta configuración y, de hecho, la propuesta de la EBA para la reforma de DPM es trasladar el marco de presentación de informes más hacia la arquitectura DPM.

La comunidad XBRL necesita ofrecer ese incentivo. El XSB entregó el formato OIM y XBRL-CSV y realizó importantes propuestas sobre la actualización de las Fórmulas. Sin embargo, esto no satisface la necesidad de utilizar XBRL como base para un sistema de «gestión de informes maestros». También significa que hay pocos incentivos para que los proveedores proporcionen herramientas para ayudar a las ANC, del mismo modo que la EBA y la EIOPA están desarrollando sus propios sistemas de gestión de datos utilizando DPM.

Creemos que la visión de la OIM debe ampliarse a:

Reunificar el conjunto de especificaciones.
Armonización de dimensiones/tablas/especificaciones de colección.
Agregue capacidad de control de versiones.

Lamentablemente, la especificación de estándares lleva tiempo para lograr un consenso y luego desarrollar las especificaciones. La comunidad XBRL se basa en voluntarios que contribuyen a este proceso, por lo que es importante que el trabajo sea relevante y prioritario si queremos ver beneficios tangibles en un plazo realista. Los autores sugieren que se comience por ampliar la hoja de ruta de OIM para que los usuarios y desarrolladores tengan una imagen más clara de los desarrollos futuros y dar orientación a autores como la EBA y la EIOPA.

Los autores son David Bell, Kapil Verma y Martin DeVille de UBPartner. Envíe comentarios, correcciones e ideas alternativas a info@ubpartner.com.