Los emisores de los mercados regulados por la UE y del Reino Unido han presentado sus primeros estados financieros en formato electrónico único europeo (ESEF), que en esencia es un informe XBRL en línea. Anticipamos que ESEF hará que los datos de informes europeos sean más consistentes, comparables y, en última instancia, útiles. Fue alentador ver a muchos emisores presentando voluntariamente presentaciones ESEF en los países que optaron por posponer la implementación de ESEF debido a la pandemia de Covid-19.
La adopción de Inline XBRL representa un cambio significativo en el proceso de información financiera. Brinda a los usuarios de todo tipo acceso a información financiera en un formato que no solo puede ser entendido por lectores humanos, sino también consumido y analizado automáticamente utilizando las etiquetas XBRL integradas.
Al igual que con cualquier formato electrónico, es fundamental que los informes ESEF cumplan con las especificaciones técnicas pertinentes para garantizar que se abran correctamente en los productos de software. Además de esta validez técnica, los preparadores deben asegurarse de que las etiquetas XBRL se apliquen con precisión para evitar una mala interpretación de los datos por parte de los consumidores.
Para muchos preparadores, la presentación de ESEF será su primera experiencia en la creación de informes XBRL e Inline XBRL, e inevitablemente hay una curva de aprendizaje. Hemos visto con la adopción de Inline XBRL en otros sistemas en todo el mundo que las presentaciones tempranas a menudo tienen problemas de calidad que deben abordarse para garantizar la usabilidad de los datos XBRL.
XBRL International ha desarrollado un depósito para presentaciones ESEF, con el fin de facilitar su descubrimiento, comparación y discusión, demostrar los beneficios de los datos XBRL estructurados y acelerar las mejoras necesarias. También estamos en el proceso de analizar los errores de validación y las advertencias producidas en cientos de informes.
En esta serie, examinaremos algunos de los errores comunes que hemos observado en las primeras presentaciones de ESEF, discutiremos sus implicaciones y describiremos cómo se pueden evitar estas trampas. Muchos de los problemas son de naturaleza técnica y se pueden evitar fácilmente mediante la aplicación de una validación automatizada utilizando un software compatible. Otros se relacionan con el contenido de los datos XBRL y, aunque el software a menudo puede ayudar a identificar tales problemas, resaltan la necesidad de que los preparadores adopten procesos de revisión que garanticen la precisión de las etiquetas XBRL.
La serie está destinada a proporcionar información a las partes interesadas a lo largo de la cadena de informes: los proveedores de software y los proveedores de servicios deben garantizar que se implementen las validaciones técnicas adecuadas; los preparadores y auditores deben considerar qué mejoras se pueden hacer a los procesos de revisión; y las Autoridades Nacionales Competentes y el regulador europeo pueden explorar expandir y hacer cumplir las validaciones aplicadas a los informes para mejorar la usabilidad y la calidad de estas presentaciones digitales.
Errores ESEF y trampas comunes: 1 – Señales incorrectas
Esto es parte de una serie de errores comunes y trampas en las presentaciones de ESEF, observadas en nuestro análisis de cientos de informes recopilados en nuestro repositorio.
Etiquetar valores con el signo incorrecto (negativo en lugar de positivo, o viceversa) es un error común y potencialmente grave en los informes XBRL. Esto se debe a que el signo utilizado para un hecho XBRL está determinado por la definición del concepto contra el cual se informa, mientras que el signo utilizado cuando se presenta el valor en un informe financiero suele estar determinado por la contribución que hace al estado en el que se informa. esta reportado. Por ejemplo, las empresas presentan el gasto fiscal como un valor negativo, porque reduce su ganancia declarada, pero las taxonomías XBRL suelen definir un concepto de ‘Gasto fiscal’, lo que significa que dicho gasto debe declararse como un valor positivo. Para garantizar que los datos XBRL en los informes estén firmados de manera consistente, la taxonomía ESMA utilizada para los informes ESEF ha definido un conjunto de reglas, que generará una advertencia si se encuentran señales inesperadas. Como veremos, esto no es necesariamente una panacea, pero si se ha emitido una advertencia, requiere investigación.
Claramente, el etiquetado con un signo incorrecto puede dar lugar a importantes malentendidos para cualquier persona que trabaje con los datos XBRL. Reportar un valor negativo contra ‘Gastos por Impuestos’ representa ingresos por impuestos.
Los intereses pagados se presentan en el informe como un valor negativo porque reducen el total de ‘Flujos de efectivo de las actividades operativas’. Sin embargo, el concepto XBRL se define como ‘Interés pagado’ y, por lo tanto, se debe usar un valor positivo para representar el monto pagado, y el valor negativo informado por el hecho que se muestra arriba es un error.
Algunos puntos de datos se pueden informar como un valor positivo o negativo. Por ejemplo, el concepto ‘Ganancia (Pérdida)’ toma un valor positivo para indicar una ganancia y un valor negativo para indicar una pérdida. Normalmente, otros conceptos solo se utilizarán con un valor positivo. Por ejemplo, ‘Ingresos financieros’ generalmente se informará solo como un valor positivo.
En el siguiente ejemplo, la advertencia de señal incorrecta de ESMA ha revelado que se utilizó la etiqueta incorrecta, lo que provocó nuestra revisión:
Se espera que la etiqueta utilizada aquí, ‘Dividendos recibidos de inversiones contabilizadas utilizando el método de la participación, clasificadas como actividades de inversión’ se informe como positiva. La investigación adicional sugiere que este es en realidad un caso de una etiqueta incorrecta, ya que la cifra se refiere a la salida en lugar de los dividendos recibidos. El concepto correcto aquí sería ‘Flujo de efectivo neto de las actividades de inversión.
Los signos incorrectos también desencadenarán a menudo inconsistencias de cálculo en un informe. Esto se discutirá con más detalle en una publicación de blog posterior.
Cabe señalar que, si bien las reglas de la fórmula XBRL y la verificación de la consistencia del cálculo pueden ayudar a detectar algunos errores de signo, nunca puede ser una verificación exhaustiva, ya que algunos conceptos pueden tomar legítimamente valores tanto positivos como negativos. Por lo tanto, es fundamental que todos los valores etiquetados se revisen cuidadosamente. Puede encontrar más información sobre este tema en nuestra guía.
Errores ESEF y trampas comunes: 2 – Duplicados inconsistentes
Esto es parte de una serie de errores comunes y trampas en las presentaciones de ESEF, observadas en nuestro análisis de cientos de informes recopilados en nuestro repositorio.
A menudo, el mismo hecho se informa varias veces en diferentes secciones de un informe. Etiquetar todas las ocurrencias de un hecho asegura que los valores sean consistentes y permite a los consumidores usar el software Inline XBRL para navegar entre estas diferentes ocurrencias y profundizar en los detalles de la figura dondequiera que aparezca.
Por lo tanto, el etiquetado múltiple del mismo hecho conduce a duplicar los hechos en el informe. Los duplicados que tienen el mismo valor, o los valores que son consistentes teniendo en cuenta la precisión informada, no representan un problema, ya que se pueden duplicar mientras se procesan los datos. Sin embargo, los hechos duplicados informados con valores inconsistentes son problemáticos, ya que es imposible saber cuál debería ser el valor correcto para el hecho.
Hemos notado algunos casos de duplicados inconsistentes informados en las presentaciones de ESEF. Un recurso útil aquí es la Nota del grupo de trabajo de XBRL International que brinda más información sobre el tema del manejo de datos duplicados en XBRL e Inline XBRL.
El siguiente ejemplo muestra que el concepto ‘Flujos de efectivo de actividades de inversión’ se informa dos veces con valores diferentes (23.008 millones de euros y 23.007 millones de euros). En ambos casos, el valor se informa con una precisión de un millón. Claramente, no es posible que ambos valores sean correctos, por lo que se genera un error de duplicados incoherentes.
Extracto del estado de flujo de efectivo
En este caso, parece que el error de hecho duplicado ha señalado un error en las cifras presentadas.
Si bien se alienta a los preparadores a etiquetar todas las ocurrencias de hechos numéricos para garantizar la coherencia y facilitar la navegación del informe, los hechos de texto duplicado pueden diferir debido a cambios inmateriales en el espaciado o las mayúsculas. Cuando esto ocurra, es aceptable dejar las ocurrencias adicionales sin etiquetar.
Errores ESEF y trampas comunes: 3 – Inconsistencia de cálculo
Una taxonomía XBRL puede definir un árbol de cálculo para describir y validar totales y subtotales simples en un informe XBRL. Por ejemplo, consideremos una relación de cálculo simple definida como Activos = Activos corrientes + Activos no corrientes. Los hechos informados para estos tres conceptos normalmente deben satisfacer la ecuación aritmética. Se produce un error de incoherencia de cálculo cuando los valores de hecho notificados no se ajustan a la relación de cálculo definida en la taxonomía.
Muchos informes ESEF que se han presentado hasta ahora tienen inconsistencias de cálculo. Las inconsistencias de cálculo no se consideran errores que invalidarían el informe, pero sí indican con frecuencia errores en los datos informados o en la construcción del árbol de cálculo. Hay casos raros en los que se informan inconsistencias en un documento etiquetado correctamente.
Las causas comunes de las inconsistencias de cálculo son:
- Los hechos han sido informados con el signo equivocado. Esta es una razón común, ya que las convenciones de signos utilizadas para presentar números en un informe financiero no siempre coinciden con el enfoque requerido por XBRL. Nuestra guía sobre la detección de errores debería ser de ayuda aquí.
- Los conceptos incluidos en el árbol de cálculo no coinciden con los hechos incluidos en el informe.
- Se ha producido un error de redondeo, que puede deberse a que la suma de los valores redondeados no coincide exactamente con el total real redondeado.
Para ilustrar este último punto, tomemos un extracto de una presentación ESEF. Este es el Estado de Cambios en el Patrimonio:
El árbol de cálculo se define para esta declaración de la siguiente manera:
Los procesadores XBRL calcularán la cifra de ‘Ingreso integral’ como la suma de ‘Ganancia (pérdida)’ y ‘Otro resultado integral’. En este caso, ‘Otro resultado integral’ no se informó directamente, por lo que un procesador calculará el total en la columna Patrimonio total como 18 400 000 €, que no coincide con el valor informado de 14 800 000 €, lo que genera inconsistencias en el cálculo.
Aunque se informan los elementos contribuyentes para «Otro resultado integral», un procesador XBRL no los utilizará para inferir el subtotal no informado. La solución aquí sería alinear el árbol de cálculo ajustándolo a través de la taxonomía de extensión para reflejar el informe (como se muestra a continuación). Alternativamente, un informe que incluye el subtotal faltante también se consideraría coherente.
Todos los procesadores XBRL conformes identificarán las inconsistencias de cálculo y los preparadores deben asegurarse de que se aborden las inconsistencias informadas.
Tenga en cuenta que documentar las relaciones aritméticas entre los conceptos informados utilizando el árbol de cálculo es un requisito del manual. Por lo que las inconsistencias no deben abordarse eliminando las relaciones de cálculo.
El RTS establece que no se requiere anclaje para un concepto de taxonomía de extensión correspondiente a «un subtotal de otras divulgaciones en la misma declaración». La razón de esto es que dicha relación acumulada se capturaría en el árbol de cálculo. Esta es otra razón para garantizar que se proporcionen relaciones de cálculo precisas.
Errores ESEF y trampas comunes: 4 – Informe de errores del paquete
Esto es parte de una serie de errores comunes y trampas en las presentaciones de ESEF, observadas en nuestro análisis de cientos de informes recopilados en nuestro repositorio.
Un informe ESEF se compone de varios archivos que deben enviarse en un archivo ZIP con formato especial, conocido como paquete de informes. Los archivos dentro del archivo ZIP del paquete de informes se deben distribuir de una manera específica, definida por la nota de informes. Aunque un paquete de informes es un archivo ZIP ordinario, el contenido debe estar estructurado correctamente, ya que esto es lo que permite que el software XBRL ubique automáticamente el informe XBRL y otros archivos dentro del ZIP.
No cumplir con la estructura prescrita del paquete de informes es probablemente el error más común que se observa en las presentaciones de ESEF y es probable que provoque que el informe no se abra en el software XBRL. Muchas de las presentaciones tienen errores en el paquete de informes, y hemos tenido que tomar medidas manuales adicionales para solucionar los errores y permitir que estas presentaciones se carguen en el índice.
Los ejemplos comunes de construcción de paquetes de informes defectuosos incluyen:
Múltiples archivos de nivel superior
Los paquetes de informes deben tener un único directorio de nivel superior dentro del ZIP. Sin esto, el software no podrá ubicar automáticamente los archivos XBRL dentro del ZIP. Por ejemplo, numerosas presentaciones han incluido un archivo PDF en el nivel superior, lo que viola esta regla.
Otra infracción común es la inclusión de un .DS_Storedirectorio. Este es un directorio que el sistema operativo Mac OS agrega automáticamente y generalmente es una indicación de que el archivo ZIP se ha editado manualmente después de la creación.
La mejor manera de evitar estos errores es utilizar el software certificado por XBRL que genera y valida un paquete de informes y asegurarse de que el paquete no se edite de ninguna manera después de la creación.
Separadores de ruta incorrectos
La especificación del archivo ZIP requiere que los directorios dentro del ZIP se utilicen /en lugar de \como separador de directorios. Lamentablemente, algunos programas ZIP utilizan incorrectamente \, lo que da como resultado un archivo ZIP no válido.
Al igual que en el caso anterior, los separadores de ruta incorrectos suelen ser una indicación de que el archivo ZIP se ha editado manualmente, en lugar de haber sido generado por el software XBRL.
Metadatos de taxonomía no válidos
Los paquetes de informes incluyen algunos metadatos estandarizados que describen la taxonomía incluida (este es el taxonomyPackage.xmlarchivo).
La estructura de este archivo está definida por un esquema XML y los metadatos deben ajustarse a este esquema. Un ejemplo del tipo de error de metadatos observado es no usar un código de país ISO de dos dígitos para el elemento «publisherCountry», sino usar el nombre del país (por ejemplo, «Finlandia» en lugar de «FI») o dejar el elemento vacío.
El software de creación de XBRL debe aplicar la validación de este archivo, pero está claro que no todo el software lo hace correctamente. XBRL International está trabajando actualmente para expandir su software para garantizar que este tipo de validación se realice mediante el software de creación de informes. Si ve este tipo de error en su informe, debe comunicarse con su proveedor de software.
Errores ESEF y trampas comunes: 5 – Fechas incorrectas
Esto es parte de una serie de errores comunes y trampas en las presentaciones de ESEF, observadas en nuestro análisis de cientos de informes recopilados en nuestro repositorio.
Un error común en los informes XBRL es etiquetar hechos con la fecha incorrecta. Esto surge debido a las diferentes convenciones que normalmente se utilizan para describir las fechas y los períodos de presentación de informes.
Los elementos del saldo (por ejemplo, ‘Activos totales’) se informan a partir de un instante en el tiempo, generalmente el instante al final de un período de informe y el comienzo del siguiente. Por ejemplo, los activos totales pueden informarse al 31 de diciembre, lo que convencionalmente se entiende como el saldo después del cierre comercial el 31 de diciembre. Sin embargo, dichas partidas también pueden informarse como un ‘saldo de apertura’, en cuyo caso normalmente se informarían a partir del ‘1 de enero’, y se entiende que esto significa el saldo antes de la apertura comercial el 1 de enero. Esta diferencia en la interpretación de una fecha en función del contexto en el que se usa puede causar confusión fácilmente al etiquetar en XBRL.
Un saldo de cierre para un período y el saldo de apertura del siguiente son realmente lo mismo, y XBRL no distingue entre los dos. Como tal, XBRL aplica una interpretación única y consistente para todos los hechos de saldo (‘instantáneos’): cuando se informa un saldo en una fecha, se entiende que significa el saldo al final de esa fecha. En efecto, para saldos de cierre esto no presenta problema, mientras que para saldos de apertura se debe dar la fecha del día anterior.
El siguiente ejemplo demuestra el tipo de error que puede ocurrir en los informes XBRL:
El saldo de apertura resaltado se ha etiquetado con una fecha del 1 de enero de 2019. Como se describió anteriormente, XBRL trata esto como el saldo posterior al 1 de enero, que obviamente no es lo que se pretende. Este hecho deberá ser etiquetado en XBRL como 31 de diciembre de 2018, por lo que se entenderá posterior al 31 de diciembre de 2018.
Además de los hechos instantáneos relacionados con fechas únicas, también tenemos hechos informados durante un período de tiempo, o ‘hechos de duración’. El período para un hecho de duración se define en XBRL por una fecha de inicio y una fecha de finalización, y estas siguen la convención esperada de especificar la primera y la última fecha incluidas en el período. En otras palabras, un período que cubra todo 2019 se etiquetaría correctamente como ‘1 de enero de 2019 al 31 de diciembre de 2019’.
Las fechas incorrectas, en gran medida derivadas de los saldos de apertura, son un problema muy común en las presentaciones de ESEF; hemos visto alrededor de 180 informes con este error de una muestra de menos de 700. Estos errores son fáciles de detectar y enfatizan la necesidad de que los preparadores revisen sus informes utilizando herramientas de revisión XBRL adecuadas.
Errores ESEF y trampas comunes: 6 – Etiquetas redundantes
La taxonomía ESEF de ESMA contiene elementos de taxonomía en todos los idiomas oficiales de la UE. Se espera que los informes ESEF utilicen estas etiquetas de taxonomía de ESMA para los elementos solo creen nuevas etiquetas para los elementos específicos de la entidad definidos en una taxonomía de extensión. En muchas presentaciones de ESEF, observamos que las etiquetas para los elementos de la taxonomía base se están redefiniendo en las taxonomías de extensión de los preparadores. Aunque las etiquetas redefinidas suelen ser exactamente las mismas que las etiquetas de la taxonomía base, incluirlas es redundante y aumenta innecesariamente el tamaño del informe. Es preferible proporcionar etiquetas para estos elementos haciendo referencia a los archivos de etiquetas de taxonomía base.
En algunos casos, los preparadores han proporcionado sus propias etiquetas para los elementos de la taxonomía base que son diferentes de los definidos en la taxonomía ESEF. Por lo general, esto se hace para que la etiqueta coincida más con la descripción de la línea de pedido utilizada por el preparador. Aunque este enfoque se utiliza en las presentaciones ante la SEC de EE. UU., que originalmente requería informes XBRL en lugar de XBRL en línea, no es obligatorio ni deseable en las presentaciones ESEF.
Analicemos el siguiente extracto de una cuenta de pérdidas y ganancias consolidada:
Los valores resaltados están etiquetados con el concepto IFRS ‘Ingresos por alquileres de propiedades de inversión, netos de gastos operativos directos’. El preparador reemplazó la etiqueta estándar de taxonomía base con «Ingresos de alquiler netos» para que coincida con la descripción utilizada en el elemento de línea. Este reetiquetado es innecesario e indeseable, ya que tales etiquetas a menudo brindan una descripción menos completa del concepto, lo que puede dificultar la comprensión correcta del hecho XBRL fuera del contexto de la tabla.
Nuestra guía señala que para los informes XBRL en línea, si los recopiladores de datos desean capturar la etiqueta preferida del preparador como una etiqueta XBRL para el concepto, deben hacerlo utilizando una función de etiqueta específica para este propósito y deben proporcionarse en adición a la etiqueta de taxonomía base en lugar de reemplazarla.
Errores ESEF y trampas comunes: 7 – Formato HTML
Inline XBRL incorpora etiquetas XBRL en un documento HTML, lo que da como resultado un documento único que permite a los archivadores proporcionar datos legibles por computadora mientras conservan un control significativo sobre la presentación del informe. HTML permite aplicar estilo y formato al informe, y las presentaciones ESEF a menudo incluyen un nivel muy alto de diseño de documentos, similar al que se ve en los informes financieros en PDF. Sin embargo, las técnicas utilizadas para lograr este estilo pueden causar problemas con las etiquetas Inline XBRL. Esta publicación describe algunos de estos problemas y cómo evitarlos.
Hechos ocultos
Según la especificación actual de Inline XBRL v1.1, no se permite que las etiquetas numéricas contengan etiquetas HTML. Esto significa que cualquier estilo debe aplicarse a todo el número etiquetado. Esto normalmente no es un problema, ya que rara vez es necesario aplicar estilo a dígitos o caracteres individuales dentro de un número. Sin embargo, algunos archivos ESEF se han creado mediante un proceso de conversión de PDF a HTML automatizado, lo que puede dar como resultado que se incluyan etiquetas HTML dentro de los números que deben etiquetarse.
Tomemos el ejemplo de este extracto para entender el problema.
Aunque el número resaltado no parece tener ningún estilo o formato inusual, si miramos la fuente HTML podemos ver que hay una <span>etiqueta adicional entre el punto decimal y el último dígito:
El <span> elemento se utiliza para realizar un ajuste muy pequeño en el espaciado entre caracteres, a fin de conservar la apariencia del PDF a partir del cual se creó. Dichos ajustes suelen tener menos de un píxel de ancho y son casi imperceptibles, pero la inclusión del <span> elemento crea un problema para el etiquetado en Inline XBRL.
El enfoque adoptado en este caso fue repetir el número en un segundo elemento HTML sin el formato adicional y luego ocultarlo y etiquetarlo:
Desafortunadamente, este enfoque socava uno de los beneficios clave de Inline XBRL: el vínculo entre el valor visualizado legible por humanos y la información etiquetada legible por máquina. Si este informe se muestra en un visor XBRL en línea, no es posible ver el número que se ha etiquetado ni usar la información de la etiqueta para navegar por el documento.
Este enfoque también crea una carga de revisión adicional, ya que no hay garantía de correspondencia entre el valor etiquetado y el valor mostrado.
La solución ideal en esta situación es eliminar las etiquetas HTML adicionales para que el número se pueda etiquetar de la forma habitual. Esperamos que ESMA aclare su punto de vista sobre esto a su debido tiempo.
El uso de un elemento HTML oculto como solución contraviene la especificación Inline XBRL, aunque no se requieren procesadores para validar esta regla.
Manejo de espacios en blanco en etiquetas de texto
El uso de estilos puede generar resultados inesperados en las etiquetas de texto. HTML normaliza cualquier espacio en blanco utilizado dentro del texto; cualquier combinación de espacios, tabulaciones y nuevas líneas se trata como un solo espacio cuando se muestra. Por esta razón, los documentos HTML a menudo incluyen espacios en blanco adicionales que no afectan la apariencia del documento. Por ejemplo, el texto resaltado del siguiente extracto se usa para etiquetar el concepto Domicilio de la Entidad.
Como en el ejemplo anterior, el HTML contiene estilos adicionales que se utilizan para ajustar el espacio entre caracteres:
Para que la fuente HTML sea más legible, cada <code;> elemento se coloca en una línea separada y se sangra. Esto no tiene ningún efecto en la visualización del documento, pero el espacio en blanco adicional se incluirá en los valores de los hechos XBRL. En este caso, el valor etiquetado es:
Aunque el software de consumo puede optar por normalizar este espacio en blanco adicional, no es necesario, por lo que se recomienda eliminar dicho espacio adicional del documento HTML para evitar el problema.
Si desea obtener más información sobre estas preguntas (que, según sabemos, afectan en su mayoría a los proveedores de XBRL), únase a los grupos de trabajo de representación XBRL y especificación XBRL, que actualmente están trabajando en formas de mejorar en gran medida estos problemas.
Errores ESEF y trampas comunes: 8 – Redondeo y cálculos
Las inconsistencias de cálculo son ocurrencias comunes señaladas en nuestra serie de blogs. Ocurren cuando el informe no se relacionan entre sí como se esperaba, o, en otras palabras, no se ajustan a las ecuaciones aritméticas definidas en un árbol de cálculo en la taxonomía.
Las inconsistencias de cálculo que surgen de hechos informados con el incorrecto pueden, y deben, corregirse, ya que hay un error real detrás de ellos. En este blog, veremos otra posible causa: el redondeo de las cifras informadas.
Tomemos este ejemplo de ‘Beneficio bruto’ calculado como ‘Ingresos’ menos el ‘Costo de ventas’. Supongamos que los valores de estos hechos para un período determinado son los siguientes:
Valores originales
Estos valores satisfacen el cálculo de la ganancia bruta:
432.875.000 – 218.942.000 = 213.933.000
Las cifras numéricas en la versión legible por humanos de los informes a menudo se escalan y redondean para una mejor legibilidad. En este caso, nuestra empresa hipotética bien podría preferir presentar estos hechos en millones de euros, redondeados a los 100.000 € más cercanos, como se muestra a continuación.
Extracto del estado de resultados
Los valores mostrados no parecen satisfacer la relación de cálculo. El valor calculado para la Utilidad Bruta sería 214.0:
432,9 – 218,9 = 214,0
Esto no coincide con el valor presentado de la Utilidad bruta, que es 213,9. Aunque puede ser sorprendente ver cifras presentadas que no suman como se esperaba, esto es puramente un artefacto del redondeo.
XBRL en línea etiqueta las cifras exactamente como se muestran en el informe legible por humanos, por lo que los valores etiquetados serían los valores redondeados que se muestran arriba, completos con la aparente falta de coincidencia de cálculo. Los procesadores XBRL señalarían este desajuste como una inconsistencia de cálculo, pero no indica un error en el informe o su etiquetado.
Las inconsistencias de cálculo no son errores y no invalidan el informe, pero deben servir como un indicador para confirmar que los valores se informaron y etiquetaron correctamente. Los preparadores deben revisar y comprender todas las inconsistencias de los cálculos para determinar si se necesitan más acciones.
El software de revisión XBRL dedicado puede ayudar con este proceso y también puede ayudar a identificar las diferentes causas de las inconsistencias en los cálculos.
