SBR

Cómo funciona

Los equipos auditores delegan SBR a TI. Eso es lo que pasa en la práctica. El partner firma el informe en PDF el martes, considera el trabajo cerrado, y el archivo XML lo abre por primera vez el responsable de sistemas el jueves anterior a la entrega. Cuando aparecen los rechazos del validador del regulador, el equipo de auditoría está en otra firma, otro cliente, otra semana. Y entonces alguien tiene que sacar adelante con lo que hay.

Aquí es donde la NIA-ES 700.A30 (aplicación de ISA 700 Revisada 2019) se vuelve incómoda. La norma hace al auditor responsable de la forma y el contenido del informe en la forma en que se entrega. Lo que realmente ocurre es que la "forma" la define hoy un esquema XML que el regulador redacta, modifica cada año, y sobre el que el auditor no tiene control editorial. El auditor firma una opinión escrita en castellano y entrega un archivo XML cuyo vocabulario lo escribe la CNMV o el Banco de España.

SBR es un protocolo de entrega, no un cambio en los procedimientos o la opinión de auditoría. Cuando la ISA 700.A30 define los elementos del informe de auditoría, SBR etiqueta esos elementos con metadatos XML para que un sistema automatizado pueda extraer y validar cada componente. El auditor redacta el párrafo de opinión, el párrafo de base de opinión y los detalles de KAM (Key Audit Matters, cuestiones clave de auditoría según NIA-ES 701) exactamente como lo hace para un informe en PDF tradicional. Una herramienta de generación SBR luego envuelve cada elemento en etiquetas estandarizadas. Por ejemplo, el párrafo que describe el enfoque de auditoría se etiqueta como ``, el párrafo de opinión como ``, y cada cuestión clave como ``.

Los reguladores ingieren estos archivos y ejecutan validaciones de contenido. Verifican que el archivo contenga una opinión etiquetada correctamente, que la opinión sea consistente con los párrafos de base de opinión, y que los KAM estén dentro del período reportado. Un archivo SBR defectuoso se rechaza automáticamente si las etiquetas requeridas faltan o los valores están fuera de los parámetros permitidos. En España esto pasa por tres canales principales: la CNMV para cotizadas y MTF, el Banco de España para entidades de crédito vía FINREP/COREP, y los registros mercantiles autonómicos para cuentas anuales digitales. La EBA/ABE establece marcos a nivel europeo, pero el rechazo concreto llega siempre desde el regulador nacional.

La adopción de SBR amplía el alcance de la revisión regulatoria desde el contenido del informe a la estructura del informe. Una opinión con salvedades correctamente sustentada en un PDF ahora también debe cumplir con la estructura XML del esquema SBR para ser aceptada por el regulador.

Yo creo que SBR ha cambiado las responsabilidades del auditor más de lo que la profesión reconoce. La NIA-ES 700.A30 hace al auditor responsable de la forma de entrega, y la forma ahora la define un esquema XML que cambia cada año sin que el auditor lo redacte. Hemos pasado de un mundo donde el socio firmaba un documento Word y eso era el entregable, a un mundo donde el socio firma un PDF y un servidor en Madrid decide si la opinión que firmó "existe" para el regulador.

Ejemplo trabajado: Editores Ibéricos S.L.

Cliente: editorial con sede en Madrid, 35 millones de euros en ingresos anuales, informe de auditoría de 2024 conforme a NIA-ES 700 Revisada 2019.

Paso 1: Redacción del informe tradicional El equipo de auditoría redacta el informe en formato Word estándar con párrafos de responsabilidad de la administración, responsabilidad del auditor, párrafo de base de opinión con referencias cruzadas a párrafos de NIA-ES 315 y NIA-ES 330, y dos KAM (valuación de inventario editorial, deterioro de derechos de publicación). El informe contiene 8 páginas con márgenes estándar.

Nota de documentación: el informe tradicional se archiva en la carpeta "Deliverables / Audit Report / Draft 1" del legajo de auditoría. Todas las referencias de párrafo de NIA-ES están incluidas; el párrafo de base de opinión se revisa frente a cada hallazgo documentado en los papeles de trabajo.

Paso 2: Validación de alineación de contenido Antes de convertir a SBR, el equipo auditor verifica que: - La opinión sea coherente con la base de opinión (si la base menciona "no se encontraron desviaciones del control de inventario", la opinión debe ser sin salvedades) - Cada KAM tiene un párrafo de descripción, un párrafo de tratamiento en las cuentas anuales, un párrafo de cómo la auditoría abordó el asunto, y un párrafo de conclusión - Los números de párrafo de la NIA-ES citados en el párrafo de responsabilidad del auditor son correctos

Nota de documentación: se crea una matriz de verificación "SBR Readiness" que vincula cada requisito del esquema SBR a la ubicación del informe Word. Por ejemplo: "auditOpinion / unqualified opinion": ubicación: párrafo 3, línea 1–2.

Paso 3: Conversión a formato XML mediante software SBR El informe Word se carga en la herramienta de generación SBR (software especializado como Ripcord, Donnelley Financial Solutions EFEN, o equivalente de la firma). La herramienta: - Detecta la estructura del informe Word y asigna párrafos a etiquetas XML - Solicita al auditor que confirme la asignación (por ejemplo, "¿este es el párrafo de opinión?", "¿cuántos KAM se incluyen?") - Valida contra el esquema XSD del regulador

Aquí salta la primera bomba de relojería. La herramienta mapea el párrafo de opinión como "opinión con salvedades" cuando la opinión real era sin salvedades. El error es invisible en la previsualización XML porque la previsualización muestra el texto del párrafo (que efectivamente describe procedimientos donde no hubo salvedades) pero la etiqueta `` queda mal asignada en el atributo. Lo detecta el senior cuando hace una revisión cruzada de la matriz SBR Readiness contra el archivo XML generado, no contra la previsualización. El partner toma la llamada con el responsable de TI: "no, no podemos enviar esto. La etiqueta dice 'qualified' y la opinión es 'unqualified'. Si entra así al sistema de la CNMV, el regulador registra una opinión con salvedades sobre Editores Ibéricos. Eso no es lo que firmamos."

Nota de documentación: el archivo de mapeo Word-a-XML se archiva como "Informe SBR / Mapping / 2024." Si la herramienta requiere edits manuales (por ejemplo, cortar y pegar un párrafo para cumplir con el esquema), esos cambios se documentan con justificación "para cumplir con la estructura SBR requerida, sin cambios sustantivos de contenido". El error de mapeo "qualified/unqualified" se documenta como hallazgo de control interno del proceso SBR y se añade a la checklist del año siguiente.

Paso 4: Validación de esquema XML y entrega El archivo XML resultante se valida contra el esquema SBR del regulador. En este caso, el esquema digital de la CNMV para cotizadas; en una entidad de crédito sería el esquema FINREP/COREP del Banco de España. Los errores de validación se corrigen (por ejemplo, "el código de KAM 'Inventory Valuation' no está en la lista permitida de códigos. Reemplace con 'Valuation of Inventories según ISA 330.A122'"). El archivo SBR se carga en el portal del regulador.

Nota de documentación: el archivo XML final validado se archiva como "Informe SBR / Final / 2024 / Editores Ibéricos SL.xml." Se guarda también un "SBR Validation Report" con timestamp de la validación exitosa.

Conclusión: el informe SBR de Editores Ibéricos contiene exactamente el mismo contenido, opinión y KAM que el informe PDF tradicional. El cambio es técnico (estructura de entrega) no sustantivo. El regulador puede automatizar la extracción de datos para análisis de tendencias sin necesidad de OCR o lectura manual de PDF. Pero conviene recordar que sin la revisión cruzada del paso 3, el regulador habría registrado una opinión distinta de la que firmó el socio.

Lo que los revisores y auditores suelen pasar por alto

- El error más frecuente en aplicaciones SBR: los equipos de auditoría tratan SBR como "marcar la casilla" — un trámite que resuelve TI — y dejan la revisión del archivo XML al personal de sistemas de la firma sin revisión del equipo auditor. Resultado: códigos de KAM incorrectos, alineación perdida entre la opinión y la base de opinión en el XML (aunque el contenido sea correcto en el informe Word original), y rechazos de validación que retrasan la entrega regulatoria. La NIA-ES 700.A30 requiere que el auditor sea responsable de la forma y contenido del informe en la forma en que se entrega. Lo que realmente ocurre cuando un archivo XML se rechaza es un incumplimiento de ese requisito aunque el contenido sustantivo del PDF sea impecable.

- Malinterpretación de "sin cambios sustantivos": algunas firmas reformatean párrafos, dividen oraciones largas o incluso omiten frases completas "para que el XML sea válido." Esto viola NIA-ES 700.12 (el auditor expresa una opinión clara e inequívoca). Una oración reformatada puede cambiar el significado de la opinión. He visto a un partner negarse a que TI tocara un párrafo de KAM "para que el XML valide" porque cambiar la sintaxis cambiaba el alcance de la cuestión descrita; el equipo de TI tuvo que pedir al regulador una extensión y reabrir el esquema. Posición correcta. El esquema SBR debe acomodar lo que el auditor escribió, no al revés.

- Ignorancia de variabilidad regulatoria: los esquemas SBR difieren entre jurisdicciones y entre años. El esquema CNMV para 2024 puede exigir un campo `` que el esquema 2023 no exigía. Los equipos de auditoría que confían en plantillas "estándar" de SBR de hace dos años envían archivos rechazados. He visto una firma mediana descubrir treinta minutos antes del cierre del portal que el esquema 2024 requería un campo nuevo que su plantilla no incluía; los papeles estaban flojos, faltaba chicha en el mapeo, y el partner tuvo que firmar una entrega tardía con justificación al regulador. La validación del esquema debe ser el último paso de cada auditoría, no un paso único en el proceso.

Comparación: SBR vs. informe de auditoría tradicional en PDF

Cuándo la distinción importa en un encargo

Un auditor de una entidad de crédito española bajo supervisión del Banco de España (con marco a nivel EBA/ABE) realiza una auditoría conforme a NIA-ES 700 Revisada 2019. El Banco de España exige que el informe se entregue en formato SBR vía FINREP/COREP antes del 31 de marzo. El auditor entrega un informe PDF de alta calidad con opinión clara, base de opinión bien documentada, y cuatro KAM.

El regulador rechaza la entrega porque no se proporcionó el archivo XML SBR. El auditor debe ahora convertir el informe PDF a XML, validarlo contra el esquema del Banco de España, y reenviarlo. Un ciclo de entrega de dos semanas se convierte en cuatro. Si las etiquetas XML no se alinean correctamente (por ejemplo, una opinión no calificada etiquetada como "con salvedades" por error en el mapeo), el regulador abre una consulta de seguimiento. La distinción entre "informe entregado" y "entrega SBR" no está en el contenido de auditoría; está en la capacidad del sistema del regulador para leer el resultado.

Dónde la profesión está dividida

Hay un desacuerdo legítimo sobre dónde acaba la responsabilidad del auditor en SBR.

Posición A (firmas grandes): SBR es un problema de TI. El auditor revisa el contenido del PDF, firma, y delega la generación y validación del XML al equipo técnico de la firma. El archivo XML es entrega técnica, no producto auditor. El argumento: separar funciones permite que cada equipo se especialice y reduce el coste de revisión.

Posición B (firmas pequeñas y auditores con experiencia regulatoria): la NIA-ES 700.A30 hace al auditor responsable de la forma de entrega del informe. Delegar la conversión XML a TI sin revisión del equipo auditor es delegar responsabilidad regulatoria. Si la CNMV registra una opinión distinta de la firmada porque una etiqueta se mapeó mal, el responsable según la norma sigue siendo el socio que firmó.

La posición B es más defendible. La NIA-ES 700.A30 no distingue entre "contenido sustantivo" y "forma de entrega"; habla del informe "en la forma en que se entrega". Si el informe que recibe el regulador difiere del que firmó el socio, eso es un problema del auditor, no del departamento de sistemas. Lo que cabe discutir es cómo se organiza la revisión, no si la revisión es responsabilidad auditor.

El segundo orden

La trampa de SBR es estructural. El auditor firma una opinión escrita en lenguaje natural, pero el regulador la lee a través de un esquema XML cuyos valores permitidos los redacta el regulador, no el auditor. La opinión que firma el socio no es exactamente la opinión que el sistema regulador registra; es una traducción de esa opinión al vocabulario controlado del esquema vigente ese año. Si el esquema solo permite tres tipos de opinión y el auditor quiere expresar un matiz que cae entre dos, el matiz desaparece en la traducción. Y la responsabilidad por esa traducción, según NIA-ES 700.A30, sigue siendo del auditor.

Términos relacionados

- Cuestiones clave de auditoría: el contenido específico que SBR etiqueta como `` en el informe de auditoría ISA 700. - Opinión de auditoría: el elemento central que SBR etiqueta como ``; la alineación entre opinión y XML es crítica. - Párrafo de base de opinión: descrito en ISA 700.12; en SBR se mapea a `` y debe ser internamente consistente con la opinión etiquetada. - Responsabilidades de la administración: párrafo requerido por ISA 700.10 etiquetado como `` en SBR. - Responsabilidades del auditor: párrafo requerido por ISA 700.11 etiquetado como `` en SBR; contiene referencias de NIA-ES. - ISA 700 Revisada 2019: la norma que define la estructura del informe de auditoría que SBR operacionaliza.

Herramientas relacionadas

La validación de esquemas SBR vive fuera de ciferi — la hace el portal del regulador, no una calculadora. Lo que ciferi sí puede acompañar es el paso anterior: documentar la materialidad de los KAM que SBR luego va a etiquetar. La Calculadora de materialidad de NIA-ES es complementaria, no primaria, para un encargo SBR. Útil cuando los KAM que entrarán como `` necesitan umbrales de materialidad defendibles antes de pasar al mapeo XML.

---