Índice
1. El error que todo el mundo comete 2. Qué dice la norma (y qué no dice) 3. Cómo funciona cada enfoque en la práctica 4. Impacto real en su estrategia de auditoría 5. Ejemplo práctico: Distribuidora Valencia S.A. 6. Lista de verificación práctica 7. Los errores que generan notas de revisión 8. Contenido relacionado
El error que todo el mundo comete
Vaya por delante que no estoy hablando de firmas pequeñas sin recursos. He visto esto en equipos con metodología propia y con acceso a especialistas de TI: el cliente dice "tenemos monitoreo continuo" y el equipo de auditoría lo traduce internamente como "podemos reducir sustantivos." Esa traducción es incorrecta, y la razón es que el monitoreo continuo no produce evidencia sobre aseveraciones de los estados financieros. Produce evidencia sobre si un control funciona.
La confusión tiene una causa estructural. En campaña, cuando el socio necesita cerrar el encargo dentro del presupuesto, cualquier excusa para reducir muestras es bienvenida. Si el cliente le dice que tiene un sistema automático que verifica controles, la tentación es documentar eso como base para reducir alcance sustantivo sin evaluar si realmente lo es. Desde mi punto de vista, esa es la bomba de relojería más frecuente en los archivos que he revisado: una reducción de muestra sin base normativa.
Qué dice la norma (y qué no dice)
Auditoría continua: lo que no es un simple dashboard
La NIA-ES 200.A1 exige que cualquier procedimiento de auditoría proporcione evidencia suficiente y adecuada para sustentar la opinión del auditor. Un sistema de auditoría continua genuino procesa transacciones en el momento en que ocurren y aplica pruebas sustantivas automatizadas capaces de detectar errores materiales de forma inmediata. Eso reduce el riesgo de detección para ciertas aseveraciones de los estados financieros.
Lo que realmente ocurre es que la mayoría de los sistemas que los clientes llaman "auditoría continua" no cumplen la NIA-ES 500. Verifican reglas de negocio (¿la factura tiene IVA correcto?), pero no generan evidencia con la fiabilidad, relevancia y suficiencia que la norma exige. En mi caso, de los últimos ocho clientes que afirmaron tener auditoría continua, dos tenían algo que se acercaba. Los otros seis tenían monitoreo continuo con un nombre más bonito.
Un sistema de auditoría continua genuino cumple cuatro condiciones: produce evidencia conforme a la NIA-ES 500 (fiabilidad, relevancia, suficiencia), puede sustentar conclusiones de auditoría específicas, dispone de controles compensatorios sobre la integridad del propio sistema e interactúa directamente con los datos transaccionales de la entidad.
Monitoreo continuo: lo que sí es (y hasta dónde llega)
La NIA-ES 315.26 requiere que el auditor obtenga un entendimiento de las actividades de monitoreo relevantes de la entidad. Un sistema de monitoreo continuo hace exactamente eso: evalúa de forma automática y periódica si controles internos específicos funcionan según su diseño.
Pero no produce evidencia directa sobre las aseveraciones de los estados financieros. Genera alertas cuando un control no opera como debería. Si el control de aprobación de órdenes de compra superiores a 10.000 euros falla, el sistema le avisa. Lo que no le dice es si el gasto se registró correctamente en las cuentas anuales.
En la práctica, el monitoreo continuo evalúa la efectividad de controles (no saldos contables), genera alertas sobre desviaciones en el funcionamiento de controles, facilita las pruebas de controles del auditor externo y no sustituye los procedimientos sustantivos requeridos por las NIA-ES.
Cómo funciona cada enfoque en la práctica
Auditoría continua: cuando funciona de verdad
Imaginemos que una empresa de distribución farmacéutica tiene un sistema que verifica automáticamente que todas las facturas de venta incluyan los impuestos correctos según la tasa aplicable por jurisdicción y tipo de producto. El sistema procesa el 100% de las transacciones en tiempo real, documenta cada excepción identificada y registra las resoluciones aplicadas.
Eso puede servir como evidencia de auditoría si cumple la NIA-ES 500.7 sobre sistemas de información automatizados. Pero aquí viene la zona gris: ¿quién verifica que las reglas de negocio programadas en el sistema son correctas? ¿Y si las tasas de IVA están mal configuradas desde el primer día? El sistema funcionará con precisión total, aplicando reglas incorrectas al 100% de las transacciones. He visto exactamente eso en un cliente del sector tecnológico con operaciones en cuatro jurisdicciones europeas. El sistema llevaba dieciocho meses funcionando sin una sola excepción. Cuando revisamos las tasas de IVA intracomunitario configuradas, tres de cuatro estaban mal. El sistema era perfecto, los parámetros no.
Monitoreo continuo: lo que le muestra (y lo que esconde)
Un sistema de monitoreo continuo opera mediante tableros de control que rastrean indicadores de rendimiento de los controles internos. Un ejemplo habitual: monitoreo del control "todas las órdenes de compra superiores a 10.000 euros requieren aprobación del gerente financiero."
El sistema verifica diariamente si este control se cumple y genera alertas cuando detecta órdenes no aprobadas. Lo que no verifica es si el gasto se registró correctamente en los estados financieros. Esa distinción es la que separa un sistema que le ayuda con las pruebas de controles de un sistema que le permite tocar los sustantivos.
Hay una pregunta que nadie se hace sobre estos sistemas y que, desde mi punto de vista, debería ser obligatoria: ¿quién investiga las alertas y en qué plazo? Porque si el sistema genera 47 alertas al mes y el responsable las marca como "revisadas" sin investigarlas, el monitoreo es un trámite. No un control.
Impacto real en su estrategia de auditoría
Si el cliente tiene auditoría continua genuina
Puede reducir el alcance de ciertas pruebas sustantivas según la NIA-ES 330.18. Pero "puede" no significa "debe." Antes de tocar una sola muestra, necesita: evaluar los controles generales de TI que respaldan el sistema, probar la integridad y exactitud de los datos procesados, verificar que los parámetros y reglas de negocio sean apropiados, y obtener evidencia de que las excepciones se investigan y resuelven adecuadamente.
Lo que realmente ocurre en la mayoría de las firmas es que el equipo evalúa los controles generales de TI de forma superficial porque no tiene un especialista de TI en el encargo. Se marcan las casillas, se documenta que "los controles de acceso son adecuados" sin probar un solo acceso, y se reduce la muestra. El archivo parece completo. Pero si el ICAC pregunta "¿cómo probó la integridad de los datos procesados por el sistema de auditoría continua del cliente?", la respuesta honesta muchas veces sería: "No la probé."
Creo que la reducción de alcance sustantivo basada en auditoría continua del cliente solo está justificada cuando usted tiene evidencia independiente de que los controles generales de TI funcionan, porque sin esa evidencia lo que tiene es una opinión del cliente sobre sus propios sistemas, no evidencia de auditoría.
Si el cliente tiene monitoreo continuo
Los reportes de excepción pueden servir como evidencia de que el control detecta desviaciones. La frecuencia y resolución de excepciones le indica la efectividad operativa del control. Los tableros de control demuestran que la gerencia supervisa el funcionamiento de los controles relevantes.
Sin embargo, sigue necesitando procedimientos independientes para confirmar que los controles operan según su diseño. Lo que el monitoreo continuo le ofrece es una base para ajustar su muestra en las pruebas de controles, no en los sustantivos.
Aquí hay un punto donde profesionales razonables discrepan. Un socio con experiencia en empresas industriales le dirá que si el sistema de monitoreo lleva dos años funcionando sin excepciones significativas, puede reducir la muestra de pruebas de controles del 25 al 10 por ciento. Otro socio, este con experiencia en inspecciones del ICAC, le dirá que la ausencia de excepciones puede significar que el sistema no detecta nada, no que los controles funcionen bien. Ambos tienen razones. En mi caso, me inclino por la segunda posición porque he visto más sistemas que no detectan que sistemas que funcionan sin fallos.
Ejemplo práctico: Distribuidora Valencia S.A.
Entidad: Distribuidora Valencia S.A., empresa de distribución farmacéutica con ingresos anuales de 45 millones de euros.
Sistema implementado: Monitoreo continuo de controles sobre el ciclo de ingresos.
Identificar los controles monitoreados
El sistema monitorea cuatro controles: - Verificación automática de límites de crédito antes de procesar pedidos - Conciliación diaria automática entre facturación y expediciones - Revisión semanal de cuentas por cobrar vencidas superiores a 90 días - Alerta automática cuando el margen bruto por línea de producto se desvía más de un 5% del margen histórico
Documentación: Obtener listado completo de controles monitoreados con frecuencia y parámetros de cada uno.
Evaluar el diseño del sistema de monitoreo
Verificar que cada control monitoreado esté diseñado para prevenir o detectar incorrecciones materiales relevantes para las aseveraciones de ingresos (existencia, integridad, exactitud, corte). Mapear cada control a las aseveraciones correspondientes en el papel de trabajo de riesgos.
Probar la efectividad operativa del monitoreo
Seleccionar una muestra de 25 días durante el período y verificar: ¿El sistema generó alertas cuando ocurrieron excepciones? ¿Las alertas se investigaron dentro del plazo establecido? ¿Las resoluciones fueron apropiadas y se documentaron?
Para cada día de la muestra, evidenciar la completitud de alertas, investigación y resolución.
Evaluar los controles generales de TI
Obtener evidencia sobre controles de acceso al sistema de monitoreo, controles de cambio sobre parámetros y reglas de negocio, y controles de respaldo y recuperación de datos.
Determinar el impacto en las pruebas de controles
Basándose en la evaluación anterior, reducir la muestra para pruebas directas de controles del 10% al 5% de las transacciones del período, manteniendo el mismo nivel de confianza. Justificar la reducción citando la NIA-ES 330.8 y referenciar la evaluación del sistema de monitoreo.
La complicación que nadie anticipa
Todo va según lo previsto hasta que, en el tercer trimestre, Distribuidora Valencia cambia de proveedor de software de facturación. La migración se completa en agosto, pero el sistema de monitoreo continuo sigue parametrizado con las reglas del software anterior. Durante septiembre y octubre, el sistema no genera una sola alerta. El equipo de auditoría interna lo interpreta como "todo funciona bien." Lo que realmente ocurre es que el sistema no está conectado al nuevo módulo de facturación.
¿Cómo se detecta esto? No con una prueba de controles más grande. Se detecta porque usted, al evaluar los controles de cambio en el Paso 4, pregunta: "¿Hubo algún cambio en los sistemas de información durante el período?" Si el cliente dice que sí y usted no evalúa el impacto en el monitoreo continuo, tiene un hueco en el archivo que ninguna ampliación de muestra va a tapar.
En mi caso, la pregunta que siempre hago en la reunión de planificación es: "¿Ha cambiado algo en los sistemas desde el año pasado?" No es una pregunta de cumplimiento. Es la pregunta que le salva el archivo.
Conclusión del ejemplo: El sistema de monitoreo continuo operó efectivamente durante los dos primeros trimestres y proporcionó evidencia adicional sobre la efectividad de los controles del ciclo de ingresos. Pero la migración de software invalidó esa evidencia para el segundo semestre. La reducción de muestra solo es defendible para el período enero-junio. Para julio-diciembre, las pruebas de controles vuelven al alcance original.
Lista de verificación práctica
1. ¿Produce evidencia directa sobre aseveraciones o evalúa controles? Esta es la primera pregunta. Si no la responde correctamente, todo lo que sigue estará mal orientado.
2. ¿Los controles generales de TI respaldan el sistema? Obtener evidencia sobre acceso, cambios y procesamiento de datos según NIA-ES 315.20. No basta con preguntar al cliente.
3. ¿El sistema procesa el 100% de las transacciones relevantes? Verificar integridad. Un sistema que procesa el 80% de las transacciones le da evidencia sobre el 80%, no sobre el 100%.
4. ¿Los parámetros del sistema son correctos? Confirmar que las reglas de negocio y umbrales son apropiados para detectar incorrecciones materiales. Pida la documentación de las reglas configuradas y compárela con los criterios que usted aplicaría.
5. ¿El tamaño de muestra refleja la confianza real obtenida? Ajustar basándose en la confianza que le da el sistema automático, no en la confianza que el cliente dice que debería darle.
6. ¿La gerencia actúa sobre las excepciones? Confirmar que la gerencia revisa y actúa sobre las excepciones identificadas según NIA-ES 315.26. Si las excepciones se acumulan sin resolución, el sistema de monitoreo existe pero no funciona como control.
Los errores que generan notas de revisión
Confiar sin verificar los controles generales de TI. Es el error más frecuente y el que más notas de revisión genera en los archivos que he revisado. Los controles automatizados son efectivos solo si los controles generales que los respaldan funcionan. Si usted no puede demostrar que evaluó los controles generales de TI del sistema del cliente, no puede sustentar una reducción de muestra. Punto.
Tratar cualquier sistema automático como auditoría continua. Que el sistema sea automático no significa que produzca evidencia de auditoría sobre los estados financieros. Un dashboard con semáforos verdes no es lo mismo que un procedimiento sustantivo automatizado. Sacar adelante el encargo con lo que hay no justifica documentar como auditoría continua lo que es monitoreo continuo.
Y aquí está la raíz del problema que nadie menciona: la propia NIA-ES no define dónde empieza la auditoría continua "genuina." No existe un umbral normativo que separe un sistema que produce evidencia de auditoría de uno que produce evidencia de control. Eso significa que cada cliente que afirma tener auditoría continua tiene razones para creerlo, y que cada auditor que acepta esa afirmación sin cuestionarla tiene una excusa que sostener ante el ICAC. El estándar crea la ambigüedad; la presión presupuestaria la convierte en error de archivo.
No evaluar los parámetros del sistema. Los sistemas pueden operar con precisión total aplicando parámetros incorrectos. El ejemplo de las tasas de IVA intracomunitario mal configuradas no es excepcional. Es lo que pasa cuando nadie revisa si las reglas programadas reflejan la realidad del negocio.
No reevaluar tras cambios en los sistemas del cliente. Si el cliente cambia de ERP, de módulo de facturación o de proveedor de software durante el período, toda la evaluación del sistema de monitoreo o auditoría continua necesita actualizarse. La evidencia del primer semestre no cubre el segundo si los sistemas son diferentes.
Contenido relacionado
- Glosario: NIA-ES 330 - Respuestas del auditor a los riesgos evaluados - Definiciones sobre pruebas de controles y procedimientos sustantivos - Calculadora de tamaños de muestra para pruebas de controles - Ajustar muestras considerando la confianza en sistemas automáticos - Evaluación de controles generales de TI en auditorías NIA-ES - Procedimientos específicos para evaluar el entorno de TI