Publicado el 10 de junio de 2021
Uno de los objetivos de la auditoría de un formato de informes digitales como ESEF es garantizar que un lector humano tome las mismas decisiones y comprenda los datos de la misma manera que una computadora que analiza los datos etiquetados. Esto significa que el auditor debe verificar el aspecto legible por máquina del informe y compararlo con el contenido legible por humanos, por auditores que en general no tienen experiencia técnica.
La solución que hemos desarrollado significa que los auditores no necesitan ningún conocimiento técnico de XBRL para auditar con éxito una presentación ESEF. Todos los elementos técnicos pueden ser auditados por software, gracias a nuestro análisis de reglas ESEF para empresas de software. El software también convertirá el contenido etiquetado de un archivo ESEF en una vista coherente y legible, que se puede comparar con el informe original. Las discrepancias aquí indican discrepancias entre la máquina y los datos legibles por humanos y nos dicen que es probable que algo esté mal.
Una historia de garantía XBRL
En los Países Bajos, tenemos un historial de brindar garantía en los informes XBRL, como parte del estándar nacional Standard Business Reporting (SBR). Desde 2017, es obligatorio para las empresas independientes de tamaño mediano y superior presentar sus informes financieros anuales en XBRL, acompañados de la opinión de un auditor. Decidimos convertir ese proceso en digital. Los informes de auditoría digitales se basan en una taxonomía XBRL, lo que significa que la opinión del auditor es en sí misma un informe XBRL completamente etiquetado.
Como en otros países, este informe debe estar firmado por el auditor. Dado que tanto el informe anual como el del auditor son digitales, esta firma también es digital , generada con un Dispositivo Calificado de Creación de Firma Electrónica (QSCD). El significado formal de la firma digital se puede encontrar en la política de firma. Nuestro registro mercantil, la Cámara de Comercio de los Países Bajos, recibe por tanto tres archivos: el informe anual en XBRL, la opinión del auditor también en XBRL y una firma separada que contiene los códigos hash de estos archivos y la firma digital del auditor.
Creemos que la solución SBR Assurance tiene pilares: en primer lugar, una presentación coherente, mediante la cual se utiliza un conjunto de reglas generalizadas para generar una visión verdadera, justa y coherente a partir de un informe XBRL. En segundo lugar, está la creación de informes de auditoría, un proceso respaldado por la taxonomía XBRL y que admite diferentes tipos de informes de auditoría en uso. El tercero es vincular y firmar, produciendo una firma digital segura y confiable. De estos tres, el primero es quizás el más importante, ya que es una presentación consistente la que nos permite transformar los datos en un informe XBRL en un documento que sea legible y comprensible para los humanos, en particular, los auditores.
En el caso de SBR, estábamos trabajando con informes XBRL estándar. Estos archivos, a diferencia de Inline XBRL, solo son legibles por una computadora. Como primer paso, el software procesa el informe utilizando definiciones de taxonomía descubiertas de XBRL Table Linkbase, Presentation Linkbase y Label Linkbase, para producir una presentación «sin procesar».
La especificación para la presentación coherente contiene un conjunto genérico de reglas, que luego se utilizan para convertir la presentación sin procesar en una imagen que sea completamente visible y comprensible para los humanos. El auditor utiliza esta presentación para auditar el estado financiero y, debido a que todos los proveedores de software usan las mismas reglas, los resultados del render son siempre idénticos o, como decimos, consistentes. Por lo tanto, los auditores no solo ven siempre la misma presentación, sino que todos los demás usuarios de datos siempre ven lo que vio el auditor al evaluar la presentación XBRL.
¿Cómo probamos esto? Todos los proveedores de software de los Países Bajos utilizan las mismas instancias de prueba y se comparan sus resultados de renderizado. Se realizan cambios en el software hasta que cumple con los requisitos y todos los proveedores de software crean la misma presentación coherente.
Aplicando nuestro enfoque a ESEF
Copiamos y modificamos nuestro enfoque existente para la auditoría de ESEF. La gran diferencia es que ESEF usa Inline XBRL y, por lo tanto, el paquete de informes genera un informe que es legible tanto por humanos como por máquinas. Debido a que las reglas de transformación son parte de la conversión, llamamos a este método transformación consistente.
¿Por qué es esto tan importante? La verdad es que la mayoría de los auditores tienen poco o ningún conocimiento técnico de XBRL. Por supuesto, hay excepciones, pero en un equipo de auditoría promedio, puede tener suerte si hay una persona que conoce la diferencia entre un elemento abstracto y uno no abstracto. Esto significa que hay partes de las Normas Técnicas Regulatorias (RTS) de ESEF y del Manual de Informes que son absolutamente incomprensibles para ellos. Eso es comprensible; todos tenemos nuestras propias especialidades, y conozco profesionales de TI que no conocen la diferencia entre débito o crédito.
Por lo tanto, el desafío era desarrollar una metodología que permitiera la auditoría efectiva y eficiente de una presentación ESEF, sin que el auditor necesitara ningún conocimiento sustancial de XBRL.
Nuestro primer paso fue comprender y capturar los requisitos de ESEF como un conjunto de reglas. Los requisitos formales se describen en la RTS. Cuando un informe anual, o estrictamente hablando un paquete de informes, no cumple con estos requisitos, creemos que el auditor debe detenerse, informar a la entidad informante y solicitar un paquete de informes corregidos. Si el declarante no cumple, esto debe mencionarse en la opinión del auditor. Por supuesto, deberíamos considerar el tema de la materialidad. No todo terminará como un comentario en la opinión del auditor, pero ese es un asunto para el juicio profesional del auditor.
Además de estos, tenemos los requisitos informales, como se establece en el Manual de informes de ESEF. El incumplimiento de estas pautas no debería, por regla general, afectar la opinión del auditor, pero hemos compilado una lista de situaciones en las que razonablemente podría tener un impacto.
¿Por qué debería ser ese el caso? El manual de informes está destinado a garantizar que un paquete de informes pueda procesarse fácilmente mediante software, con un cierto nivel de estandarización. Si una entidad no se adhiere a los requisitos informales, por ejemplo mediante el uso de tuplas, miembros mecanografiados, hipercubos, etc., que no están permitidos por el manual, surge el riesgo de que el software no pueda procesar el paquete de informes. El propósito final de ESEF es aumentar la transparencia de la información, por lo que debemos asegurarnos de que se pueda acceder y leer todos los paquetes de informes. En los Países Bajos, creemos que el auditor tiene la responsabilidad de prestar atención a esto.
Con esto en mente, comenzamos por realizar un análisis completo del RTS. Explicamos todas las reglas y proporcionamos una instrucción o ejemplo de cómo ejecutar cada regla. Este es el núcleo del enfoque. Estas reglas no están destinadas al auditor, sino a la empresa de software que crea el software de auditoría para su uso con los archivos ESEF. En otras palabras, explicamos las reglas de ESEF para los proveedores de software.
Luego llevamos a cabo el mismo análisis para los requisitos en el manual de informes, capturando aquellos que, en nuestra opinión, no estaban ya cubiertos por el RTS, nuevamente dirigido a los proveedores de software. También le dimos a cada requisito informal una ‘clasificación’, que no pretende ser normativa, sino más bien proporcionar alguna orientación al auditor sobre el impacto si no se cumple con el requisito.
En total, identificamos 33 requisitos formales y 67 requisitos informales, que se han combinado en lo que llamamos nuestro enfoque de auditoría técnica para ESEF, junto con un proceso de auditoría que hemos desarrollado. Hemos descubierto ciertas áreas que requieren una atención especial, como el registro de reglas de transformación, que no está cubierto por el RTS y el manual de informes. Entonces, por ejemplo, ¿qué deberíamos hacer si nos encontramos con la regla de transformación fijo-vacío, que reemplaza todo el contenido con nada, de modo que el lector humano ve los datos pero la computadora no obtiene nada? O la regla de transformación fijo-cero, que reemplaza todos los números con un cero? Hemos desarrollado respuestas a estos escenarios en ausencia de orientación oficial, aunque esperamos que surja esta última.
Las fórmulas también requieren una consideración especial; la taxonomía de ESMA ESEF los contiene y, por lo tanto, también deberíamos usarlos. Sin embargo, es importante tener en cuenta que los hechos notificados que producen advertencias o errores en el proceso de validación no son necesariamente incorrectos. Esa distinción puede ser difícil de explicar tanto a los auditores como a los emisores, pero es importante hacerla. Por ejemplo, se puede marcar un error si a una empresa informante le falta el nombre de su entidad matriz, cuando de hecho no tiene una entidad matriz y no hay motivo de preocupación.
Otra preocupación potencial, de la que nos informaron nuestros colegas alemanes, es el uso de hojas de estilo en cascada para controlar el formato de visualización. Esto puede influir en la imagen del documento XBRL en línea que muestra un navegador, por ejemplo, haciendo que se muestre de manera diferente en orientación horizontal y vertical, o en diferentes anchos de visor o navegador, e incluso puede tener un impacto en los resultados impresos, en otras palabras, es posible que el mismo documento produzca diferentes vistas en diferentes sistemas.
El proceso de auditoría digital
Entonces, ¿cómo funciona el proceso de auditoría digital? Comenzamos extrayendo todos los datos etiquetados del archivo XBRL en línea, es decir, el informe ESEF, teniendo en cuenta las reglas de transformación, para generar un archivo XBRL simple y completo. A continuación, el software descubre la taxonomía completa del emisor del paquete de informes y utiliza las definiciones para convertir los datos XBRL en una vista de presentación, una vista de cálculo y una vista de definición. Esto es lo que llamamos transformación consistente.
Estos resúmenes son legibles y comprensibles para los auditores, y se pueden comparar con el documento Inline XBRL original. En otras palabras, los auditores pueden comparar los datos legibles por máquina etiquetados que hemos extraído con la vista legible por humanos presentada en el informe ESEF. Esto permite la identificación de datos mal etiquetados, así como errores en las relaciones de cálculo, anclajes, etiquetas, etc.
Como auditor, este enfoque le brinda una visión general; por otro lado, al evaluar únicamente los datos etiquetados con un visor en línea, no verá la relación entre cada concepto y la taxonomía total. En nuestra vista legible, los elementos de extensión del emisor también se destacan, mostrando a qué elemento IFRS de la taxonomía ESMA ESEF están anclados.
Junto con el auditor, cuando el software de auditoría procesa el paquete de informes, también lo evalúa frente a todos los requisitos técnicos del manual de informes RTS y ESEF, así como los procesos y fórmulas de validación básica de XBRL. Al final, tenemos una auditoría del 100% del paquete de informes, que incluye tanto una vista legible para el auditor, que utilizan para evaluar la exactitud e integridad del informe anual, como la ejecución de controles automatizados para las partes técnicas del auditor. no entiende.
¿Y cómo se ven los resultados? Aquí, por ejemplo, a la izquierda tenemos un estado de situación financiera renderizado producido usando la transformación consistente (los datos legibles por máquina), y a la derecha está la imagen del informe Inline XBRL (los datos legibles por humanos). Ambos lados se pueden comparar fácilmente.
Este segundo ejemplo está tomado de otro producto de software, mostrando el mismo equilibrio también renderizado de acuerdo con la transformación consistente. Esta vista se puede auditar fácilmente porque le resulta familiar al auditor, con la ventaja de que se puede examinar cada elemento.
En resumen, los pasos básicos para realizar una auditoría en una presentación ESEF son los siguientes. El auditor realiza su auditoría ‘clásica’ en el documento Inline XBRL legible por humanos de la manera tradicional. Además, utilizamos software de auditoría para descubrir el contenido de la taxonomía del emisor y extraer un archivo XBRL simple del informe. En esta etapa, se llevan a cabo todos los controles automatizados posibles, incluida la validación genérica de XML y XBRL, las verificaciones de las reglas capturadas del RTS y el manual de informes, y la validación de cálculos y fórmulas, y, si es necesario, se generan informes de excepción.
Luego, los datos XBRL se procesan, utilizando la taxonomía descubierta y siguiendo las reglas de transformación consistentes, para crear una vista amigable para el auditor de los datos etiquetados legibles por máquina. Esto se compara manualmente con el informe Inline XBRL realizado por el auditor. Si hay una discrepancia, podemos suponer que es probable que se haya producido un error en alguna parte. Por ejemplo, si falta una cifra en el balance general, podemos asumir que Presentation Linkbase no es correcta, o si falta una columna en el estado de cambios en el patrimonio, probablemente nos falte un miembro dimensional.
Integridad digital
Usamos códigos hash para ayudar a proteger la integridad del proceso. Para asegurarnos de que todos estamos hablando del mismo objeto de auditoría, en este caso el paquete de informe completo, incluido el archivo meta taxonomypackage.xml, el esquema del punto de entrada, las bases de enlaces y, por supuesto, el archivo Inline XBRL en sí mismo, desarrollamos un código abierto, solución para crear códigos hash de archivos individuales y un código hash general para el paquete de informes. Esta herramienta, que incluye fuentes en C # y VB.Net y un paquete de instalación, se puede descargar de nuestro sitio web . Los códigos hash los utiliza, por ejemplo, el auditor en su carta de consentimiento para identificar el paquete de informes que examinaron y asegurarse de que no se modifique posteriormente. Entiendo que otros países ahora están siguiendo nuestro ejemplo y adoptando este enfoque.
¿Funciona todo esto?
¡Sí, hemos descubierto que sí! Por supuesto, hay algunos problemas menores a medida que aprendemos en el trabajo, pero en general, nuestro enfoque de auditoría digital parece estar funcionando extremadamente bien al ofrecer un método para que los auditores aborden las presentaciones de ESEF y verifiquen los datos digitales sin conocimientos técnicos.
Aunque el mandato se ha pospuesto durante un año en los Países Bajos, como en la mayoría de los demás países europeos debido a la crisis del Covid-19, 18 grandes empresas han presentado paquetes de informes ESEF de forma voluntaria. Todas estas presentaciones se auditaron utilizando nuestro enfoque, que hasta ahora se ha integrado en el software de auditoría ofrecido por dos empresas, Accept y ParsePort. La conclusión de la Autoridad Holandesa para los Mercados Financieros fue que las 18 presentaciones presentadas eran 100% técnicamente correctas, lo que podría dejarnos con una falta de problemas interesantes para resolver, pero muestra que los procesos de informes y aseguramiento están funcionando notablemente sin problemas, por lo que ¡lejos!