Inicio › Capítulos › Capítulo 5 · Aspectos técnicos de XBRL

5.11 · Preparación y publicación de las reglas de reporte (filing rules)

18 min de lectura

Juan Carlos Rodríguez R. participó en la elaboración del contenido original de esta sección como desarrollador de contenido de XBRL International. La versión final en inglés es la publicada por XBRL International.

5.11 · Preparación y publicación de las reglas de reporte (filing rules)

Introducción

Preparar y publicar las reglas de reporte es esencial para gestionar un sistema de reporte digital. Las reglas de reporte responden a los requisitos técnicos del programa de reporte y buscan asegurar la interoperabilidad. Definen cómo deben estructurarse y enviarse los reportes XBRL, y cubren aspectos técnicos como los formatos de archivo, las convenciones de nombres, los límites de tamaño y las especificaciones o extensiones permitidas.

Las reglas de reporte ayudan a reducir errores evitables, como reportes enviados en un formato equivocado o que superan los límites de tamaño. Al aclarar lo que se espera, aseguran que los envíos sean compatibles con la plataforma del supervisor, simplifican el proceso de envío y reducen la necesidad de correcciones manuales. Esta sección explica cómo crear y publicar reglas de reporte claras y exigibles, alineadas con los requisitos técnicos del entorno de reporte.

Tipos de reglas de validación

Las reglas de validación se agrupan en dos categorías:

• Reglas de reporte: se centran en cómo se construye y se entrega un reporte. Cubren aspectos como los formatos de archivo, las convenciones de nombres, los límites de tamaño y las versiones aprobadas de las especificaciones XBRL. Estas reglas aseguran que el sistema pueda leer y procesar el envío.
• Reglas de validación de negocio: se centran en el contenido del reporte. Ayudan a verificar que la información reportada sea completa, coherente y lógicamente correcta. Por ejemplo, pueden exigir que ciertos hechos se reporten siempre o que los totales coincidan con la suma de sus partes.

La siguiente tabla compara las dos categorías de reglas de validación:

Esta sección se centra en las buenas prácticas para crear y publicar reglas de reporte. Para conocer en detalle las reglas de negocio y la implementación de la validación en los sistemas de reporte XBRL, consulte «Validación de datos XBRL: ¿por qué y cómo?» (sección 5.10).

Retos de las reglas de reporte

Aunque algunas reglas de reporte son esenciales para que los reportes XBRL cumplan los requisitos de quien los recibe, las reglas innecesarias crean una carga para los desarrolladores de software y pueden introducir problemas de interoperabilidad.

Los reportes XBRL e iXBRL deben cumplir las restricciones establecidas en las especificaciones XBRL, iXBRL y relacionadas. Los procesadores conformes (consulte la lista de software certificado) deben ser capaces de consumir cualquier reporte que cumpla las especificaciones pertinentes, y esto se comprueba con los completos conjuntos de pruebas de conformidad (conformance suites) que acompañan a las especificaciones. Esto asegura un alto nivel de interoperabilidad entre los productos de software XBRL. En otras palabras, un reporte producido con un producto de software XBRL puede ser procesado por cualquier otro. Por lo tanto, normalmente no se necesitan reglas adicionales de sintaxis.

Un ejemplo de regla innecesaria y potencialmente perjudicial sería una que establezca restricciones adicionales sobre el orden de los elementos dentro de un reporte XBRL, más allá de lo que exige la especificación XBRL. Todos los procesadores XBRL conformes deben consumir esos elementos en cualquier orden que permita la especificación, de modo que imponer restricciones adicionales sobre el orden no aporta ningún beneficio a los consumidores. En cambio, crea una carga adicional para los preparadores de la información, que podrían tener que modificar un software XBRL conforme para cumplir esa restricción adicional. Además, si distintos programas introducen distintas reglas técnicas de sintaxis, las soluciones de software pueden dejar de ser reutilizables entre mercados.

Se recomienda mantener las reglas de reporte al mínimo y, en particular, evitar restricciones innecesarias a nivel de sintaxis.

Tipos de reglas de reporte

Las reglas de reporte cumplen un papel crucial para alinear los reportes XBRL con los requisitos específicos de quienes recogen los datos. Sin embargo, es importante distinguir entre las reglas esenciales y las que pueden introducir, sin quererlo, cargas técnicas o dificultar la interoperabilidad.

Normas y versiones permitidas

El estándar XBRL está compuesto por varias especificaciones técnicas modulares e interrelacionadas. Cada sistema de reporte usa los módulos de especificación que mejor responden a sus requisitos. En algunos casos pueden existir varias versiones de una misma especificación. Por eso, las reglas de reporte deberían indicar los módulos y las versiones de la especificación XBRL que se deben usar para crear los reportes XBRL. Dos ejemplos de este tipo de reglas son:

• Los reportes iXBRL deben crearse con Inline XBRL 1.1 y con las transformaciones del Transformation Rules Registry (Registro de Reglas de Transformación), versión 5.
• Las unidades reportadas en el reporte XBRL deben cumplir la especificación Unit Type Registry 1.0 (Registro de Tipos de Unidad).

Taxonomías permitidas

Las reglas de reporte deberían indicar las taxonomías de reporte que pueden usarse para preparar los reportes.

Las reglas de reporte deberían listar las URL de taxonomía válidas que pueden referenciarse en los reportes XBRL y en las taxonomías de extensión.

La regla anterior suele complementarse con una regla de negocio que indica los periodos de reporte a los que aplica cada versión de la taxonomía, o la fuente donde los preparadores pueden obtener esa información.

Restricción de las dimensiones incorporadas

Los requisitos sobre el contenido que se reporta en las dimensiones incorporadas (periodo, unidades, identificación de la entidad) provienen del dominio de negocio, pero las reglas de reporte deben indicar la sintaxis técnica esperada para expresarlos. Algunos ejemplos de estas reglas son:

• Definir el o los «scheme» (esquemas de identificación) que deben usarse para identificar a la entidad.
• Indicar si la dimensión de periodo puede usarse para identificar horas específicas del día o solo días completos.
• Normalmente, las unidades deberían restringirse exigiendo el cumplimiento de la especificación Unit Type Registry.

Tratamiento de los duplicados

Los reportes XBRL pueden incluir hechos duplicados, es decir, dos o más hechos que pretenden aportar el mismo dato. Esto es común en los reportes iXBRL, ya que un mismo hecho puede aparecer varias veces en distintas secciones del reporte. La práctica recomendada es marcar todas las apariciones de esos hechos, lo que puede producir hechos duplicados cuando se extraen los datos XBRL del reporte.

La especificación XBRL no prohíbe los hechos duplicados, pero quien recoge los datos debe indicar cómo se tratarán. Esto puede incluir reglas de reporte que provoquen el rechazo de los reportes con ciertos tipos de hechos duplicados. Los problemas relacionados con el uso de hechos duplicados, y los enfoques recomendados para tratarlos, se exponen en una nota de un grupo de trabajo (working group note) aparte.

Reglas para iXBRL

En un programa de reporte que recoge reportes iXBRL, hay algunos aspectos técnicos adicionales que las reglas de reporte deberían abordar. Por ejemplo:

• Es posible generar una sola salida XBRL a partir de varios documentos iXBRL (un «iXBRL Document Set», o conjunto de documentos iXBRL) y también generar varios reportes XBRL a partir de un solo documento iXBRL. Las reglas de reporte deberían indicar si alguna de estas opciones está permitida.
• Las reglas de reporte para iXBRL suelen incluir restricciones relacionadas con HTML sobre la inclusión de scripts ejecutables o de referencias a recursos externos, como imágenes y hojas de estilo.

Reglas para las extensiones de taxonomía

En un programa de reporte que permite o exige que las entidades que reportan entreguen taxonomías de extensión, deberían establecerse reglas de reporte que restrinjan la construcción y el contenido de esas extensiones. Algunos ejemplos de estas restricciones son:

• Qué componentes de la taxonomía base deberían usarse (p. ej., etiquetas, árbol de presentación, árbol de cálculo, dimensiones).
• Qué etiquetas deben entregarse para cualquier concepto nuevo que introduzca una taxonomía de extensión.
• Cómo deben vincularse los conceptos nuevos con los componentes de la taxonomía base mediante relaciones de presentación, de cálculo, dimensionales u otras.

Reglas relacionadas con el envío

Las reglas de reporte deberían indicar, en una sección separada de las reglas sobre el contenido del reporte XBRL, cómo debe enviarse el reporte XBRL en un sistema de recepción. Algunos ejemplos de reglas relacionadas con el envío son:

• Detalles del protocolo de envío (es decir, cómo debe entregarse el reporte a quien lo recibe, incluidos los detalles de cualquier mecanismo de seguridad requerido).
• Si el reporte debe entregarse como XBRL Report Packages.
• Cualquier límite de tamaño de archivo del reporte.
• Detalles de las firmas digitales que se exijan sobre el reporte.

Para una lista de verificación detallada de posibles reglas de reporte, consulte Filing Rules XBRL Report Checklist (lista de verificación de reglas de reporte para reportes XBRL) y Filing Rules Checklist for Taxonomy Extensions (lista de verificación de reglas de reporte para extensiones de taxonomía).

Reglas de reporte que deben evitarse

Las reglas de reporte innecesarias crean cargas adicionales para los preparadores y los desarrolladores de software, y pueden perjudicar la interoperabilidad. No se recomiendan los siguientes tipos de reglas de reporte.

Restricciones a nivel de sintaxis

Las reglas de reporte no deberían imponer restricciones sobre una sintaxis que las especificaciones XBRL ya permiten. Por ejemplo, las reglas que exigen un orden específico de los elementos en un reporte XBRL (como schemaRef, linkbaseRef, contextos, unidades, hechos y notas al pie) van más allá de lo que exige la especificación e introducen cargas de implementación innecesarias. De igual manera, establecer formatos para los ID de contexto, los ID de unidad u otros identificadores —que no tienen significado semántico— impone restricciones evitables al diseño del software.

Repetición de reglas de la especificación

Las reglas de reporte no deberían duplicar requisitos de validación que ya cubren las especificaciones XBRL. Esa repetición no agrega valor y puede introducir inconsistencias sutiles que generan confusión o problemas de interoperabilidad. Por ejemplo, las reglas que exigen que los hechos monetarios usen unidades de moneda ISO, o que prohíben el uso de miembros por defecto (default members) en los contextos, simplemente repiten lo que ya exigen las especificaciones XBRL 2.1 y Dimensions 1.0. Si conviene hacer énfasis en ciertos requisitos de la especificación para los preparadores o los proveedores, estos deberían incluirse como material de orientación y no como reglas de reporte.

Reglas no automatizables y textos de orientación

La orientación o las instrucciones que no pueden automatizarse no deberían presentarse como reglas de reporte. Aunque son útiles para los preparadores, estos materiales deberían mantenerse claramente separados de las reglas de reporte exigibles y automatizables. Algunos ejemplos de orientación no automatizable son: exigir que el atributo decimals coincida con la precisión reportada, indicar el uso de hechos nil para distinguir entre valores en cero y valores omitidos, inferir los valores por defecto de las dimensiones cuando no se entregan de forma explícita, desaconsejar unidades que impliquen factores de escala en las monedas, e indicar cómo deben reportarse las notas al pie según la diagramación del documento.

Creación y publicación de las reglas de reporte

Establecer reglas de reporte eficaces requiere entender claramente el ecosistema de reporte, hacer pruebas prácticas y comunicarse de forma cuidadosa con todos los grupos de interés. Esta sección ofrece una guía para crear y publicar reglas de reporte.

El primer paso para desarrollar reglas de reporte es entender el entorno en el que van a operar. Esto significa identificar las necesidades técnicas y regulatorias, y alinearlas con:

• La estructura y las capacidades de la taxonomía.
• Los límites técnicos y las validaciones del sistema de recepción.
• Los objetivos y las expectativas del programa de reporte.

Cuando están bien diseñadas, estas reglas mejoran la calidad, reducen los errores y apoyan procesos de validación eficientes. Una publicación eficaz favorece el cumplimiento, al asegurar que los preparadores y los proveedores de software puedan interpretar y aplicar las reglas de manera coherente.

Reglas XBRL Formula

Las reglas XBRL Formula permiten definir reglas de validación dentro de una taxonomía. Así, el software XBRL conforme puede verificar las reglas sin necesidad de programación a la medida. Se recomienda definir las reglas de reporte como reglas XBRL Formula siempre que sea posible. De esta forma, los preparadores que usan software XBRL conforme pueden comprobar localmente el cumplimiento de las reglas de reporte antes de enviar el reporte al sistema de recepción. Implementar las reglas de reporte como reglas XBRL Formula asegura que no haya ambigüedad en su interpretación.

Para una visión breve de cómo funciona la validación en el reporte XBRL, consulte Validation – Key Concepts (Validación: conceptos clave), que explica el papel de las fórmulas para hacer cumplir la coherencia del reporte, junto con otras capas de validación como los cálculos y las restricciones del esquema.

Para explorar ejemplos prácticos y orientación sobre la construcción de reglas XBRL Formula, consulte el XBRL Formula Rules Tutorial (tutorial de reglas XBRL Formula).

Identificadores de las reglas

Cada regla debería tener un identificador único. En lo posible, los identificadores deberían mantenerse a lo largo de las versiones posteriores del documento de reglas de reporte.

Descripción de las reglas legible por personas

Además de publicar las reglas en un formato ejecutable como XBRL Formula, se recomienda publicar una descripción clara y legible por personas de todas las reglas de reporte, en un formato como HTML o PDF.

Las reglas de reporte deberían publicarse con documentación clara y estructurada que explique no solo en qué consiste cada regla, sino cómo funciona en la práctica. Esto incluye descripciones en lenguaje sencillo, definiciones técnicas y ejemplos concretos de envíos que cumplen y que no cumplen. Dar este nivel de detalle ayuda a los preparadores a entender la intención de cada regla, reduce los errores de interpretación y apoya una implementación coherente entre distintas herramientas y plataformas.

Pruebas y conjunto de pruebas

Antes de publicar las reglas de reporte, estas deben probarse a fondo para asegurar que funcionen como se espera en escenarios reales. Esto implica simular envíos válidos e inválidos, revisar las respuestas del sistema y confirmar que cada regla esté correctamente alineada con la taxonomía y con la lógica del reporte.

Probar las reglas de reporte cumple varios propósitos. Ayuda a identificar conflictos entre las reglas y la estructura de la taxonomía, asegura que los reportes válidos se acepten y que los que no cumplen se rechacen adecuadamente, y confirma que los mensajes de error se disparen de manera precisa y consistente. Además, aporta evidencia de que las herramientas de validación automatizada pueden aplicar las reglas de forma confiable.

Una buena práctica es desarrollar y publicar un conjunto completo de casos de prueba, cada uno con un reporte XBRL simplificado diseñado para pasar o fallar según una regla específica. Estos casos de prueba deberían documentarse con claridad, describiendo el escenario que se prueba, el resultado esperado y la respuesta real del sistema observada durante las pruebas. Publicar los conjuntos de pruebas ayuda a que las reglas de reporte se implementen correctamente y apoya a los desarrolladores de software en la comprensión de sus requisitos.

Ejemplos de casos de prueba:

• Si una regla limita el tamaño del archivo a 25 MB, se pueden crear dos casos de prueba:
  • Una instancia con un tamaño total de 24 MB, que debería aceptarse.
  • Otra con un tamaño de 27 MB, que debería disparar el error: «El archivo supera el tamaño máximo permitido de 25 MB».
• Para una regla que exige que el nombre del archivo del reporte siga un patrón específico —como [EntityID]Q[Quarter][Year].xbrl—, una instancia de prueba válida usaría un archivo llamado 12345_Q4_2023.xbrl, que debería aceptarse. Otro caso de prueba, con un archivo llamado report_final.xbrl, se rechazaría. El mensaje esperado podría ser: «El nombre del archivo no cumple el patrón requerido: [EntityID]Q[Quarter][Year].xbrl».

Mensajes de error claros

Las reglas de reporte deberían disparar mensajes de error que no solo sean técnicamente precisos, sino también fáciles de entender y de atender por parte de los usuarios. Un buen mensaje de error identifica con claridad qué salió mal, remite a la regla o al requisito específico que se incumplió y sugiere cómo corregir el problema.

A continuación hay algunos ejemplos:

Publicación de las reglas de reporte

Las reglas de reporte, junto con los documentos de soporte, los casos de prueba y los archivos de reglas, deberían quedar disponibles en portales regulatorios accesibles para todos los grupos de interés, incluidos los preparadores y los proveedores de software.

Para evitar confusiones, es importante indicar con claridad el ámbito de aplicación de cada conjunto de reglas: si aplica solo a un periodo de reporte determinado, a una versión específica de la taxonomía, o desde su fecha de publicación hasta que se emita un nuevo conjunto.

Del mismo modo, otros factores de contexto relevantes para cada escenario de reporte deberían considerarse y comunicarse, según corresponda, para evitar ambigüedades y asegurar que los preparadores y los proveedores de software puedan interpretar y aplicar las reglas de manera coherente, al igual que el propio supervisor durante el análisis posterior y las revisiones futuras.

Control de versiones

Las reglas de reporte, al igual que las taxonomías y las plataformas de validación, evolucionan a medida que cambian los requisitos o se hacen ajustes. Un control de versiones eficaz asegura claridad y confianza en el proceso de reporte. Cada publicación de reglas debería incluir un número de versión y una fecha de publicación claros, acompañados de un registro de cambios (changelog) detallado que deje constancia de cualquier adición, modificación o eliminación. Las reglas obsoletas deberían seguir disponibles para consulta y estar claramente marcadas para evitar confusiones.

Soporte y asistencia a los usuarios

Para apoyar la adopción y la implementación adecuada, los supervisores deberían ofrecer una asistencia completa. Esto incluye mantener preguntas frecuentes y guías de solución de problemas, establecer puntos de contacto designados para la asistencia técnica y la incorporación (onboarding), y ofrecer canales de retroalimentación por los que los usuarios puedan reportar problemas o sugerir mejoras. La retroalimentación de los usuarios cumple un papel importante para identificar vacíos y mejorar la calidad y la facilidad de uso de las reglas de reporte en general. Estas medidas ayudan a que los preparadores y los proveedores apliquen las reglas correctas con confianza, lo que favorece la coherencia y la colaboración en todo el entorno de reporte.

Resumen

Las reglas de reporte son un componente esencial de cualquier programa de reporte digital. Proporcionan el marco técnico que asegura que los reportes XBRL puedan validarse, procesarse e interpretarse de manera coherente entre sistemas. A diferencia de las reglas de negocio, que definen qué datos deben reportarse y cómo se relacionan conceptualmente, las reglas de reporte definen los parámetros operativos del envío: qué se permite, qué se exige y cómo responderá el sistema.

Las buenas reglas de reporte no solo son técnicamente sólidas, sino que además:

• Están claramente alineadas con la taxonomía y con los objetivos del reporte.
• Son fáciles de implementar y de validar automáticamente.
• Están documentadas con claridad, con casos de prueba y mensajes de error que indican qué hacer.
• Se publican en formatos accesibles, con herramientas y orientación de apoyo.
• Se actualizan de forma transparente e iterativa, con base en la retroalimentación y en las necesidades cambiantes.

Unas reglas de reporte bien diseñadas y bien publicadas generan confianza, reducen costos y mejoran la integridad de los ecosistemas de datos regulatorios. Al aplicar las ideas y recomendaciones de este documento, las autoridades pueden establecer marcos de reglas de reporte sólidos, flexibles y listos para soportar entornos de reporte escalables y preparados para el futuro.

Texto original en inglés: https://playbook.xbrl.org/