Auditoría Interna

En este artículo, que constará de varias entregas, definiremos mejores prácticas para la generación de matrices de control con alto valor para nuestras rutinas de auditorias de procesos.

Mucho se ha hablado en este espacio sobre temas como auditoría interna, SOX, controles generales, etc.

En este caso me gustaría explayarme sobre una de nuestras “fascinantes” formas de documentar nuestro trabajo de auditoria de procesos, las cuales son, ni más ni menos, que nuestras queridas matrices de control.

Para aquellos que no les ha tocado lidiar con algunas de estas planillas sábanas/interminables no me queda mas que decirles que la matriz (generalmente desarrollada en MS EXCEL® o similar) contiene prácticamente TODA la información de nuestros controles básicos, y es allí a su vez donde volcaremos toda la información relacionada con c/u de ellos (por ej. Testing, Remediation Plans, etc.)

Más allá de la broma e ironía las matrices son una herramienta fundamental ya que nos permite, rápidamente, entre otras:

- Verificar nuestros procesos y objetivos de control
- Identificar a los owner de “procesos” y “controles”
- Confirmar los riesgos mitigados
- Identificar si se encuentran correctamente cubiertos los objetivos COSO
- Verificar el estado de los tests.

Ahora bien, ¿qué debería contener una matriz de control al menos “decente”?

Existen muchas opciones, modelos y templates disponibles, sin embargo, y alineando nuestra matriz a las mejores prácticas hoy existentes, considero existen un “kit” de datos mínimos que debemos identificar y documentar en nuestros papeles de trabajo y que, espero, pueda explicar correctamente:

-PROCESO: Resulta básico definir en una primer columna de nuestra hermosa matriz a que proceso estamos haciendo foco. De la misma forma esta matriz debería subdividirse en subprocesos de acuerdo a la complejidad de los mismos. Un ejemplo clásico podría ser el siguiente:

ABASTECIMIENTOS
COMPRAS Y CUENTAS POR PAGAR
PROCESAMIENTO DE FACTURAS
DATOS MAESTROS DE PROVEEDORES

De esta forma pueden ver como nuestra matriz va ganando columnas en “complejidad” pero nos permite claramente definir todos los procesos que estaremos abarcando en nuestra auditoría.

-OBJETIVOS DE CONTROL: Muy bien, una vez posicionados en nuestro proceso deberemos empezar a plasmar todos aquellos objetivos de control que estaremos intentando mitigar con el marco de control interno implementado. Estos objetivos de control deben ser claros y precisos, y evitando ambigüedades ya que si no tenemos claro el objetivo de control, no podremos identificar claramente el riesgo asociado. Tengan en cuenta que riesgo y objetivo de control van de la mano. Por lo cual y siguiendo el ejemplo del subproceso “DATOS MAESTROS DE PROVEEDORES” un buen ejemplo de objetivo de control podría ser:

- “Todos los datos de proveedores son cargados en forma exacta, íntegra y por única vez”

Creo el ejemplo es claro y contundente, no deja lugar a dudas de lo que estamos persiguiendo con nuestra “batería” de controles asociados a este objetivo.

- ACTIVIDAD DE CONTROL: En esta columna de nuestra matriz detallaremos fila tras fila la/s actividad/es de control que la organización lleva a cabo a fin de cumplir con el objetivo de control planteado precedentemente. Es importante destacar algunos “tips” a los fines de redactar correctamente una actividad de control. Se considera que una actividad de control esta correctamente documentada si define claramente:

- Quien ejecuta el control 
- Que es lo que hace
- Con que frecuencia lo hace
- Que evidencia deja al efectuarlo.

Detallando claramente estos aspectos el auditor tiene el “camino despejado” al momento de realizar el testing ya que sabe claramente su frecuencia, por lo cual puede determinar una muestra acorde. A su vez sabe que pedir (evidencia) y a quien dirigirse (el responsable de ejecutar el control).

Siguiendo hilo del caso “testigo” podríamos definir las siguientes actividades de control

“Cada vez que el Analista de Cuentas a Pagar registra un nuevo proveedor, el sistema XXX valida que no exista un registro cargado anteriormente con el mismo número de NIT. Tal configuración se encuentra documentada en el módulo ZZZ”

O bien

“El sistema XXX se encuentra configurado de tal manera, que al momento de registrar un nuevo proveedor, los siguientes campos resultan de carga obligatoria

a) Razón Social
b) Domicilio
c) Condición IVA
d) NIT
e) Forma de Pago
f) Cuenta de Reconciliación
g) Etc……
Tal configuración se encuentra documentada en el módulo ZZZ”

De esta manera, vemos para ambas actividades de control se cumplen las condiciones anteriormente detalladas que son:

- Quien ejecuta el control (en este caso es un control automático que realiza el sistema XXX)
- Que es lo que hace (Validar campos con datos sensibles)
- Con que frecuencia lo hace (Cada vez que el Analista registra un nuevo proveedor en el sistema)
- Que evidencia deja al efectuarlo (aquí la evidencia esta en la configuración del módulo ZZZ)

- RIESGOS: En esta columna intentaremos detallar el riesgo mitigado por la actividad de control efectuada. Obviamente el mismo debe tener alguna concordancia con el objetivo de control predefinido, sino claramente estaremos confundiendo nuestro alcance.

Ya que estamos con el tema datos maestros podríamos definir como riesgo mitigado para las actividades detalladas:

- "Incorrecta imputación contable en cuentas de IVA. Contingencias impositivas por omisiones como agente de retención"

He visto que algunas veces el riesgo es detallado como la NEGACIÓN al objetivo de control. Es decir que podría poner (siempre siguiendo este caso)

- OBJETIVO DE CONTROL: “Todos los datos de proveedores son cargados en forma exacta, íntegra y por única vez”

- RIESGOS: “Los datos de proveedores NO son cargados en forma exacta, íntegra y por única vez”

Primero me parece poco “original” ya que es obvio que si no cumplimos con nuestro objetivo de control ocurrirá lo contrario

Por otro lado creo es necesario destacar el problema final al no efectuar los controles detallados. Fijense que en este ejemplo estoy imaginando que si los datos de proveedores no son correctos un “responsable inscrito” en IVA podría ser registrado como “no responsable” y en este caso tendría un error en la cuenta contable “IVA” ya que estaría omitiendo el % del impuesto.

A su vez si se cometiera el error de definir como “EXENTO DE RETENCIÓN” a un proveedor que no lo es, la empresa podría ser intimada a actuar como tal e incurrir en multas formales por su omisión.

Esta definición del riesgo es mucho más cuantificable y “vendible” a la gerencia, siendo mucho mas interesante que el intangible hecho de que “los datos de proveedores NO son cargados en forma exacta”

CONTINUA EN PRÓXIMA ENTREGA

Aportado por: Luis Romero de

http://www.portalcontar.com.ar/