Teclas: actualizaciones clave del último manual de informes y cómo afectarán a la próxima temporada de informes.
La Autoridad Europea de Valores y Mercados (AEVM) ha actualizado recientemente su Manual de Información, introduciendo varios cambios que afectarán a la próxima temporada de información. Para obtener una información general completa de estas actualizaciones, puedes visitar el sitio web oficial de la AEVM. Sin embargo, para facilitarte la comprensión de cómo estos cambios afectarán específicamente a tu proceso de elaboración de informes, ParsePort ha tomado la iniciativa de destacar los temas más relevantes.
En este artículo, analizaremos estas actualizaciones clave y las compararemos con nuestro enfoque y prácticas actuales. Nuestro objetivo es proporcionarte una comprensión clara y completa de las implicaciones para tus informes en la próxima temporada de informes.
Orientación 1.2.2: Utilización de elementos disponibles en la Taxonomía NIIF que aún no estaban incluidos en la taxonomía ESEF.
"La AEVM sugiere que los emisores determinen si la Taxonomía NIIF incluye un elemento que corresponde a una presentación del informe de los emisores y no está presente en la taxonomía ESEF. Los Emisores deben definir un elemento de taxonomía de extensión cuyo nombre, etiqueta y características XBRL se correspondan con el nombre, la etiqueta y las características XBRL del elemento en la Taxonomía de las NIIF".
El elemento de la taxonomía "Inmovilizado material, incluidos los activos por derecho de uso" se ha seleccionado como ejemplo de cómo los elementos de la actualización de 2023 de la taxonomía de las NIIF pueden utilizarse voluntariamente hasta que la modificación de 2024 del RTS sobre ESEF sea obligatoria para los ejercicios que comiencen a partir del 1 de enero de 2025.
En ParsePort, nos comprometemos a respetar la sintaxis y las configuraciones de la taxonomía. Este enfoque garantiza que, cuando se actualice la taxonomía, cualquier extensión pueda sustituirse sin problemas por elementos estándar, manteniendo así la comparabilidad de los archivos de nuestros clientes.
Al Elegir ParsePort para tus necesidades de etiquetado, puedes estar seguro de que estas actualizaciones se implementarán sin esfuerzo. Cuando se publique la nueva Taxonomía, incluidos los elementos estándar, la transición será tan fácil como chasquear los dedos.
Nuestro objetivo es que tu proceso de elaboración de informes sea lo más eficaz y conforme posible, asegurándonos de que siempre estés al día de las normas y reglamentos más recientes.
Orientación 1.4.1: Anclaje de elementos de extensión a elementos de la taxonomía de la ESEF que tienen un alcance o significado más amplio
"Además, la AEVM opina que, para mejorar la calidad y la utilidad de las relaciones de anclaje en los elementos de extensión de los emisores, éstos deberían anclar sus elementos de extensión a elementos de la taxonomía básica de la ESEF que compartan el mismo tipo de datos. Por ejemplo, si un emisor crea un elemento de extensión de monetaryItemType, dicho elemento sólo debe etiquetarse con el correspondiente elemento básico de la taxonomía ESEF de monetaryItemType (y no, por ejemplo, stringItemType)".
En ParsePort, llevamos mucho tiempo cumpliendo las mejores prácticas en materia de extensiones de taxonomía, garantizando que tus informes sean precisos y conformes. Aunque parezca obvio, es crucial que las extensiones utilizadas en tu informe "imiten" las características de sus elementos de anclaje (Delimitador más ancho).
Una extensión sirve como mecanismo para "rellenar un hueco" que la taxonomía básica no puede abordar. Sin embargo, el principio fundamental de la Taxonomía ampliada nos ordena anclarnos al significado disponible más cercano. Esto significa que la extensión y su ancla deben estar alineadas, sobre todo en lo que se refiere a su tipo de datos.
Al seguir estas mejores prácticas, nos aseguramos de que tus informes mantengan su integridad y comparabilidad, incluso a medida que evolucionan las taxonomías. En ParsePort, nuestro compromiso con estos principios garantiza que tu proceso de elaboración de informes siga siendo fluido y conforme con las normas más recientes.
Orientación 2.2.5: Etiquetado de guiones o campos vacíos
"Para facilitar el análisis y la comparación de los datos contenidos en los estados financieros primarios consolidados con arreglo a las NIIF, la AEVM recomienda a los Emisores que tengan en cuenta la siguiente orientación a la hora de marcar campos vacíos o símbolos de guiones en sus estados."
A menudo existe cierto debate sobre si utilizar ceros, guiones o espacios vacíos en los estados financieros. En ParsePort, recomendamos a los clientes que etiqueten siempre los valores de cero en todas las declaraciones (Declaración de la Renta, Ingresos Integrales, Balance y Flujo de Caja). Por ejemplo, si el Periodo 1 muestra 200, entonces el Periodo 2 debe tener un cero o un guión, pero no un espacio vacío.
Pueden aplicarse excepciones al Estado de Cambios en el Patrimonio Neto (SOCIE), dependiendo de si las partidas son las mismas en ambas tablas. Como regla general, sugerimos etiquetar los guiones como ceros, asegurándonos de que también aparecen visualmente en el informe.
Si sigues estas directrices, podrás mantener la coherencia y claridad de tus estados financieros, facilitando su lectura e interpretación.
Guía 2.2.7: Construcción técnica de una etiqueta de bloque
"En consonancia con la Nota del Grupo de Trabajo Internacional sobre XBRL publicada el 19 de abril de 2023 para hechos con un tipo de dato dtr-types:textBlockItemType, los Emisores deberán establecer siempre el atributo @escape de iXBRL en "true" para garantizar que el valor del hecho resultante es válido en XHTML. Mientras tanto, los datos con otros tipos de datos, como xbrli:stringItemType, establecerán en su lugar el atributo @escape en "false", ya que no se espera que sus valores contengan XHTML."
La Plataforma ParsePort ya está configurada de acuerdo con la nueva guía 2.2.7 de la ESMA. La ESMA subraya la importancia de cumplir las mejores prácticas en XBRL, una norma que nos comprometemos a respetar plenamente.
Esta actualización simplifica significativamente nuestros procesos. Ahora, todos los elementos BlockItemType (todos los bloques de texto) se escaparán siempre, independientemente de si el texto contiene símbolos específicos como "<" o "&". Esto garantiza la coherencia y el cumplimiento en todos los Informes, haciendo que tu experiencia de reportes sea más fluida y fiable.
En ParsePort, nos esforzamos continuamente por alinearnos con las últimas normas reguladoras y las mejores prácticas, garantizando que nuestra plataforma permanezca a la vanguardia de los informes XBRL.
Orientación 2.6.1: Incluir un documento XBRL alineado en paquetes de informes
"La AEVM recomienda a los emisores que preparen sus presentaciones ESEF de acuerdo con la especificación Report Package 1.0 publicada por XBRL International, que indica cómo deben incluirse los documentos XBRL Inline dentro de un paquete de informes.Los emisores deben seguir todas las disposiciones de la especificación anterior, específicamente en el contexto de las extensiones de archivo reconocidas para los tipos de informes y los paquetes de informes". Además, la AEVM recomienda que las empresas de software se aseguren de que, en caso de incumplimiento de la especificación anterior, se presenten a los emisores los códigos de error de la especificación oficial."
Con la aplicación de la recomendación anterior y la adopción de la especificación The Report Package 1.0, cambiará el formato de los archivos extraídos. Para la próxima temporada de informes, podrás extraer paquetes de informes de la Plataforma ParsePort en el nuevo formato .xbri, reemplazando al anterior formato .zip.
Ten por seguro que esta transición se producirá automáticamente dentro de nuestro sistema, por lo que no hay necesidad de preocuparse. Para garantizar una preparación sin problemas para la próxima temporada de presentación de informes, asegúrate de actualizar tus Archivos de entrada a la última versión. Una vez actualizado, ¡estarás listo para convertir tus archivos sin problemas!
Orientación 2.6.3: Convención de nomenclatura para los paquetes de informes y el archivo de informes
Según el Manual "el componente {version} del nombre de archivo debe indicar la versión del paquete de informes ESEF enviado a la autoridad pertinente. Concretamente, se añadirá un dígito aparte después del componente {date} (separado por el carácter guión-menos). Este dígito está limitado a solo un carácter numérico después del guión-menos y representará la versión de la presentación (es decir, para la primera presentación siempre debe ser 0, para cada nueva presentación del mismo paquete debe incrementarse en 1)"
Ejemplo: 12345NOTVALID1234503-2023-12-31-0-es (Primera presentación)
Recuerda: Siempre que un OAM o una Autoridad Nacional Competente proporcione indicaciones sobre las diferentes convenciones de nombres que se exigen a nivel nacional, los Emisores deben seguir dichas convenciones nacionales de nombres.
Teniendo en cuenta que el motor no puede prever cuántas versiones se han enviado ya, la opción de ajustar el contador estará disponible en los archivos de entrada (plantilla de Excel) para ser anulada en caso de una versión diferente.
Orientación 3.4.1: Documentar las relaciones aritméticas en la base de enlaces de cálculo
"La AEVM recomienda que se revisen cuidadosamente las incoherencias de cálculo resultantes de la evaluación de las bases de enlaces de cálculo de la taxonomía de extensiones, ya que pueden plantear problemas de etiquetado. Puede que no sea posible evitar algunas incoherencias de cálculo, incluso con la aplicación de los Cálculos 1.1. En particular, los Cálculos 1.1 pueden dar lugar a falsos positivos cuando hay conjuntos de datos incompletos. Esto ocurre cuando hay suficientes datos para activar un cálculo, pero no los suficientes para comprobarlo completamente . En los siguientes Párrafos se presenta un ejemplo de incoherencia de cálculo que puede surgir debido a conjuntos de datos incompletos: La Taxonomía de extensión de un Emisor ficticio incluye el siguiente cálculo en el Estado del resultado global: Resultado global = Beneficio (pérdida) + Otro resultado global En la misma taxonomía de extensión del emisor, éste utiliza en el Estado de cambios en el patrimonio neto los elementos "Resultado global" y "Beneficio (pérdida)". El emisor opta por utilizar dos nuevos elementos ("Otro resultado global que se reclasificará en resultados" y "Otro resultado global que no se reclasificará en resultados") en lugar del elemento "Otro resultado global". En este caso, el cálculo definido para el estado del resultado global también se evaluará para el estado de cambios en el patrimonio neto, pero solo podrá incluir el valor de los elementos "Resultado global" y "Beneficio (pérdida)", mientras que el valor del elemento omitido "Otro resultado global" será 0. Por lo tanto, el resultado del cálculo se considerará incorrecto y se planteará como una incoherencia de cálculo. El hecho de que se marque una incoherencia de cálculo no significa que el informe XBRL en línea de la ESEF sea incorrecto. Un cálculo definido para el estado del resultado global también se ha aplicado al estado de cambios en el patrimonio neto, donde hay suficientes datos para activar un cálculo ("Resultado global" y "Beneficio (pérdida)"), pero no suficientes para comprobarlo completamente, ya que falta el dato "Otro resultado global". Por lo tanto, la AEVM considera que este tipo de incoherencias de cálculo podrían no tenerse en cuenta"
La última versión del Manual de la AEVM proporciona información ampliada sobre las incoherencias de cálculo, detallando las incidencias más comunes observadas hasta la fecha. En concreto, hace referencia a los Cálculos 1.1 y destaca que estas incoherencias a menudo no surgen de cálculos incorrectos, sino de la selección de elementos utilizados en diferentes estados.
En el ejemplo proporcionado, el tratamiento contable es correcto, ya que ambos componentes de Otros ingresos globales (OCI) utilizados en el Estado de cambios en el patrimonio neto (SOCIE) representan con precisión el OCI total. Sin embargo, desde la perspectiva XBRL, existe una discrepancia que, aunque presente, se considera no bloqueante.
Esta guía ampliada ayuda a aclarar la naturaleza de estas incoherencias y subraya la importancia de una cuidadosa selección de elementos para garantizar tanto la precisión contable como el cumplimiento del XBRL. En ParsePort, nos comprometemos a ayudarte a navegar por estas complejidades, garantizando que tus informes sean precisos y conformes.
Puedes saber más sobre ello aquí.
Orientación 4.1.5: Convención de nombres para documentos XHTML independientes
Nueva orientación en consonancia con el ajuste de la Orientación 2.6.3. La recomendación relativa al nombre del archivo también es aplicable a los archivos xHTML (autónomos, individuales), lo que significa que debe cambiarse el nombre del archivo descargado de la plataforma ParsePort.
Orientación 3.4.8 (NUEVO): Documentar las relaciones aritméticas en la base de enlaces de presentación
"Algunos de los Estados Financieros Principales contienen una serie de relaciones aritméticas entre periodos que no pueden reflejarse en la base de enlaces de cálculo. Un ejemplo de relaciones aritméticas entre periodos es el estado de flujos de efectivo, en el que la suma de entradas y salidas del periodo corresponde a la variación del saldo de caja desde el principio del periodo hasta el final del periodo. Otro ejemplo es el estado de cambios en el patrimonio neto que contiene conciliaciones entre el importe en libros al principio y al final del periodo para cada componente del patrimonio neto. Como la base de enlaces de cálculo no puede utilizarse para definir eficazmente las comprobaciones de la calidad de los datos en esas relaciones entre periodos, la base de enlaces de presentación debe utilizarse para documentar esas dependencias aritméticas entre periodos y dimensiones, lo que permitirá la ejecución de validaciones al menos semiautomatizadas."
La orientación actualizada de la nueva versión del Manual de la AEVM, derivada de la orientación 3.4.1, introduce una recomendación (no obligatoria) de incluir resúmenes que definan el periodo de cálculo para las secciones del informe que abarquen un lapso de tiempo específico. Esto es especialmente relevante para los cálculos del Estado de Cambios en el Patrimonio Neto, que abarcan el principio y el final de un periodo y no pueden representarse en la base de enlaces de cálculo. Poner en práctica esta recomendación puede ayudar a resolver incidencias relacionadas, especialmente si lo solicita tu auditor.
A continuación, encontrarás una lista de otras directrices del Manual de Informes de la AEVM que se han actualizado y ajustado con cambios menores.
Orientación 1.1.2: AFR presentados en más de un idioma
Orientación 2.1.2: Formateo del elemento Punto en el contexto del documento XBRL alineado
Orientación 2.2.6: Legibilidad de la información extraída de una etiqueta de bloque
Orientación 2.6.2: Incluir documentos XBRL Inline multi-html y múltiples conjuntos de documentos XBRL Inline en los paquetes de informes
Guía 3.1.3: Paquetes de taxonomía
Guía 3.2.2: Tipos de datos que deben utilizarse en los conceptos de extensión
Orientación 3.3.1: Relaciones para anclar elementos de la taxonomía de extensiones a elementos de la taxonomía ESEF
Orientación 2.2.8 (NUEVO): Utilización del atributo ID en los datos