Su software actual puede cerrar el mes sin errores y aun así no resistir una auditoría, si el control no queda registrado en el sistema.
Cuando el director financiero entrega el informe mensual, la gerencia ve una cifra final. No ve que una aprobación se hizo por correo porque el flujo del sistema ya no correspondía al organigrama, que un usuario conserva permisos asignados hace tres años o que compras y contabilidad registraron el mismo pedido con cifras distintas. La operación puede seguir así durante meses. Hasta que un banco, un cliente corporativo o la revisoría fiscal pregunta quién autorizó la operación, qué regla se aplicó y dónde quedó la evidencia. Ahí se descubre que un resultado correcto no siempre es un resultado que se pueda sustentar.
No es un riesgo aislado. Un análisis reciente de KPMG sobre empresas investigadas por la Comisión de Valores de Estados Unidos encontró que el 82% carecía de controles internos efectivos. Entre las debilidades identificadas estaban los errores en la documentación, la falta de políticas y procesos adecuados y los fallos en controles tecnológicos.
Cuando esa evidencia está repartida entre correos, chats y hojas de cálculo, el problema no se resuelve pidiendo más disciplina ni preparando carpetas antes de la visita. La empresa necesita un ERP para control interno que integre las reglas del negocio, haga obligatorios los flujos de aprobación, registre las excepciones y conserve el rastro de cada decisión mientras la operación ocurre. Sin esa base, la organización puede tener controles manuales, pero no un control suficientemente consistente, escalable y trazable para responder con rapidez ante una auditoría.
Una política escrita no basta si el ERP no la refleja
Un informe dice el resultado que se obtuvo; una auditoría pregunta ¿cómo se llegó ahí? y esa respuesta no puede depender de la memoria de una persona.
Lo que la gerencia recibe y lo que las áreas deben demostrar
La gerencia recibe un resumen: un total, una variación, un semáforo verde. finanzas, contabilidad y tecnología deben poder abrir el ERP y mostrar el origen del dato, la aprobación que lo respaldó y el momento exacto en que ocurrió. Una cifra puede estar bien calculada y, aun así, no ser defendible si nadie puede reconstruir quién intervino y qué criterio se aplicó.
El mismo problema aparece cuando una estrategia no se traduce en acciones concretas de la organización: una meta alcanzada tampoco basta si la empresa no puede demostrar qué decisiones, criterios y controles permitieron obtenerla.
Diseñar, ejecutar y demostrar son tres momentos diferentes
Las políticas y matrices de autorización describen cómo debería operar el control interno, pero solo se cumplen cuando quedan traducidas en roles, límites y flujos dentro del ERP. Definir una política es apenas el primer paso: hay que configurarla, exigir que la operación pase por ella y conservar evidencia de cada autorización.
Cuando la política y la configuración del sistema no coinciden
Las fugas más comunes aparecen aquí: aprobaciones que el sistema permite saltar, niveles de autorización desactualizados frente al organigrama y reglas que existen en el papel, pero no en la plataforma. Si la política dice una cosa y el ERP permite otra, en la práctica gobierna el ERP. La respuesta es ajustar la configuración para que el sistema represente el control requerido; si la plataforma ya no puede sostenerlo, corresponde evaluar su reemplazo.
El mismo informe de KPMG citado al inicio identifica dónde se concentran estas fugas con más frecuencia: compras, reconocimiento de ingresos y consolidación financiera. No es casualidad. Son justamente los procesos donde más se cruzan aprobaciones, sistemas y criterios de distintos equipos, y donde una política bien escrita tiene más terreno para dejar de cumplirse sin que nadie lo note.
Las excepciones revelan cómo se gobierna realmente la empresa
El control interno puede parecer sólido en el día a día. Son las excepciones las que muestran si el ERP realmente lo gobierna.
Una excepción autorizada no es lo mismo que evitar un control
Toda operación tiene excepciones legítimas: un cliente estratégico que requiere un plazo distinto o una compra urgente que no puede esperar el flujo normal. El ERP debe exigir el motivo, identificar al responsable, solicitar la autorización correspondiente y conservar el registro. Sin ese rastro, la empresa no puede distinguir una excepción válida de un incumplimiento informal.
Por ejemplo, una compra urgente puede salir una vez por una ruta excepcional configurada en el ERP. Si la misma vía se usa cada semana, no exige justificar el motivo y nadie revisa su frecuencia, la excepción deja de complementar el proceso: empieza a reemplazarlo. El ERP no elimina las excepciones; las gobierna y permite demostrar por qué ocurrieron.
Lo que la gerencia debería conocer sobre las excepciones
Cuántas excepciones hubo, quién las autorizó, qué impacto tuvieron y qué evidencia conserva el ERP: esa es la información que debería llegar periódicamente a la gerencia. Si una misma excepción se repite, deja de ser una salida puntual y empieza a revelar que el proceso real opera por fuera de la regla. Registrarlas y revisarlas dentro del ERP permite detectar ese desvío antes de que una auditoría externa lo convierta en un hallazgo.
Cerrar un hallazgo no significa haber corregido el problema
Responder a una observación y archivar el caso no corrige el control si la operación puede repetirse.
Corregir una operación frente a corregir el proceso
Ajustar una transacción puntual resuelve el síntoma. Corregir el proceso exige convertir el hallazgo en una regla dentro del ERP: un nuevo nivel de autorización, un bloqueo preventivo, un flujo distinto o un registro obligatorio. El procedimiento también debe actualizarse y la operación debe utilizar el flujo como fue diseñado. De lo contrario, incluso una buena configuración puede quedar reducida a una regla que existe en el sistema, pero no gobierna el trabajo real.
Qué debería cambiar después de una auditoría
Un hallazgo bien gestionado deja algo concreto: una regla nueva, un límite ajustado o un control que antes no existía, incorporado en el ERP. La prueba de que ese cambio funcionó no es la respuesta que se envió al auditor, sino si la misma situación puede repetirse un trimestre después. Esta misma lógica aplica cuando el foco es fiscal, por ejemplo al preparar a una empresa para una revisión de la DIAN: si el sistema sigue permitiendo lo mismo, el hallazgo no se cerró, solo se respondió.
El crecimiento puede dejar atrás reglas que antes funcionaban
Aquí el problema es estructural: la empresa ya no cabe en las reglas con las que comenzó.
Reglas diseñadas para la empresa de ayer
Nuevas sedes, más usuarios y nuevas líneas de negocio pueden dejar atrás una regla que antes era suficiente. Una autorización pensada para un punto de venta no funciona igual cuando la empresa opera diez, y un límite definido hace tres años puede ser irrelevante frente al volumen actual. Si esas reglas no se actualizan en el ERP, la organización compensa con correos, permisos informales y archivos paralelos. Esa no es una solución temporal: es una pérdida de control.
Cuándo su ERP y el partner se convierten en una decisión de control
El valor del partner está en convertir una necesidad del negocio (como separar funciones, actualizar montos de aprobación o documentar excepciones), en una configuración verificable dentro del ERP. Debe poder explicar qué riesgo resuelve cada ajuste, quién será responsable del control y qué evidencia conservará el sistema. Cuando esa traducción falla, el ERP puede registrar las operaciones, pero no gobernar el proceso. Por eso, elegir al partner es también una decisión de control, no solo tecnológica.
Checklist: la prueba que su empresa debería poder responder
Use este checklist como una prueba de decisión. Cada respuesta debería poder demostrarse directamente desde el ERP. Una respuesta negativa no se resuelve creando otra hoja de cálculo o pidiendo una aprobación adicional por correo: indica que el sistema actual no está sosteniendo el control que la empresa necesita.
● ¿Puede su software actual mostrar quién originó, modificó y autorizó cada cifra relevante del último cierre?
● ¿Las políticas de aprobación escritas coinciden con los roles, límites y flujos configurados en su software actual ?
● ¿El software conserva un registro de cambios que muestre quién modificó qué y cuándo?
● ¿Las excepciones quedan registradas con motivo, responsable, autorización e impacto?
● ¿Su sistema bloquea o escala las operaciones que superan los límites autorizados?
● ¿Los hallazgos anteriores se tradujeron en nuevas reglas o configuraciones dentro del sistema?
● ¿Los roles, permisos y niveles de autorización corresponden al tamaño actual de la empresa?
●¿Su proveedor actual puede convertir las necesidades de control del negocio en configuraciones reales del software?
Qué revisar en su software actual para entender si sigue siendo suficiente o se quedó corto en el crecimiento de su empresa
La revisión debe determinar cuál de las siguientes rutas le corresponde:, actualizar la configuración del sistema actual o sustituir una plataforma que ya no puede exigir autorizaciones, gobernar excepciones ni conservar trazabilidad. Lo que no debería ocurrir es compensar esas brechas con más Excel, firmas manuales o aprobaciones por chat.
Crecer con control y un partner que lo sostenga
El diagnóstico debería quedar registrado como una decisión documentada, no como una impresión general de que "todo funciona bien": qué controles respalda el software hoy, cuáles requieren ajuste y cuáles debe incorporar la empresa a medida que crece. El ERP por sí solo no define qué debe controlar la empresa, pero sí determina si esas reglas se ejecutan de forma consistente y quedan demostradas, según cómo se le configure.
Consensus acompaña este proceso con más de 35 años de experiencia y más de 1.000 implementaciones de SAP Business One en Colombia, Latinoamérica y Estados Unidos. Su conocimiento de la operación de empresas colombianas permite traducir políticas, autorizaciones y necesidades de trazabilidad en configuraciones que respondan al negocio real y puedan ajustarse a medida que la empresa crece.
Si su empresa aún no cuenta con un ERP para control interno, o su sistema actual no puede demostrar quién aprobó, qué cambió y qué excepciones se autorizaron, agende un diagnóstico con Consensus. El objetivo es definir qué controles deben incorporarse en SAP Business One, qué configuraciones necesitan ajuste y qué evidencia debe quedar disponible antes de la próxima auditoría.
Puntos clave
● La evidencia de control debe generarse mientras la operación ocurre. Reconstruirla cuando comienza una auditoría indica que el proceso depende de controles frágiles.
● Una excepción repetida y un hallazgo que reaparece revelan problemas diferentes, pero ambos exigen cambios verificables en el proceso y en el ERP.
● La decisión de implementar, un ERP para control interno debe surgir de un diagnóstico de las necesidades de control de la empresa, no únicamente de una evaluación tecnológica.
● El partner no solo implementa el ERP: debe traducir necesidades de control en configuraciones verificables, y esa capacidad pesa tanto como la funcionalidad del sistema.
● Actualizar los niveles de autorización y los flujos no es un ajuste técnico menor: es la forma en que el ERP refleja cómo creció realmente la empresa.
Preguntas frecuentes
¿Puede una empresa en crecimiento sostener su control interno sin un ERP que lo respalde?
No de forma consistente y escalable. Cuando las aprobaciones, excepciones y cambios dependen de correos, hojas de cálculo o memoria individual, la empresa no puede garantizar que la regla se aplicó de la misma manera ni demostrarla con rapidez. Para una organización que crece, busca financiación o responde ante auditorías y clientes corporativos, integrar esos controles en el ERP es una necesidad de control.
¿Qué señal indica que ya no basta con ajustar el software actual y hay que evaluar un reemplazo?
Cuando los ajustes recurrentes dejan de reducir el riesgo: si cada trimestre hay que reconfigurar de nuevo los mismos roles o excepciones, el problema no es la configuración, es que la plataforma ya no puede sostener la regla.
¿Cuándo debería revisar una empresa los roles y niveles de autorización del ERP?
Cada vez que cambien los responsables, las sedes, los montos de operación, las líneas de negocio o la separación de funciones, y no solo antes de una auditoría. Un organigrama actualizado con permisos antiguos crea una brecha entre la estructura que la gerencia aprobó y la operación que el sistema realmente permite.
¿Cómo ayuda SAP Business One a sostener el control interno?
Permite traducir las reglas de la empresa en roles, autorizaciones, flujos y registros dentro de una misma plataforma. Su valor no está únicamente en almacenar transacciones, sino en hacer que el proceso siga una regla y deje evidencia mientras ocurre.
¿Qué debe aportar el partner durante este proceso?
Debe entender cómo opera el negocio, identificar dónde el control depende de prácticas manuales y convertir las políticas en configuraciones reales. Su alcance debe concentrarse en el diagnóstico, la configuración y los ajustes técnicos y funcionales necesarios para que el ERP evolucione con nuevas sedes, usuarios, montos y procesos.
Es momento de actuar, ponga en marcha un plan
¡Solicite una asesoría PERSONALIZADA AQUÍ!
Fuentes
KPMG España. (2025, 17 de marzo). Fallos de control en casos de la SEC en los años 2023 y 2024. https://kpmg.com/es/es/informes-publicaciones/2025/03/fallos-control-subyacentes-sec-2023-2024.html
DIAN. (2026, 30 de enero). Informe de Gestión DIAN 2025. https://www.dian.gov.co/atencionciudadano/Documents/Informe-de-Gestion-DIAN-2025-30012026.pdf
Consensus S.A.S. (2026). Consensus, su socio Premier SAP Business One en Colombia. https://consensussa.com/
.jpg)
.jpg)
