En mayo de 2026, una empresa de Huesca pagó la misma nómina dos veces: una al estafador y otra al empleado legítimo. El engaño empezó con un correo rutinario de cambio de cuenta bancaria, documentación falsificada y un pago ejecutado con aparente normalidad (Hoy Aragón). Días antes, en Tenerife, otra mercantil transfirió el importe de unos cursos de cocina a una cuenta distinta tras interceptar el hilo entre empresa y proveedor (El Día).
Estos casos no son anécdotas aisladas. La Guardia Civil y el INCIBE llevan meses alertando sobre la oleada de Business Email Compromise en España: suplantación, urgencia y, casi siempre, un dato sensible que acaba modificándose en algún sistema operativo.
La pregunta incómoda para quien usa Business Central no es solo “¿cómo evitamos el fraude?”. Es otra: ¿sabríamos mañana si alguien cambió un dato crítico fuera del procedimiento que creíamos tener bajo control?
El escenario que se repite más de lo que parece
Imaginemos la mercantil tinerfeña del caso anterior —la que pagó unos cursos de cocina a una cuenta falsa tras interceptar el hilo con su proveedor— usando Business Central. Tras el susto, Finanzas diseña un procedimiento para cambios de cuenta bancaria de proveedor, forma al equipo y comunica la regla: ningún IBAN nuevo entra en producción sin validación y aprobación.
En papel, el control existe.
Meses después, en una revisión previa a certificación ISO, el responsable de compliance intenta demostrar que ese procedimiento se cumple. Cruza cambios sensibles del trimestre con las aprobaciones registradas. El resultado es incómodo:
- Once modificaciones en datos bancarios de proveedores.
- Cuatro con evidencia clara de supervisión.
- Siete sin ninguna referencia de control.
Ninguna de esas siete implicaría, de entrada, un fraude confirmado. Pero sí demostraría algo peor para el día a día: el procedimiento no se estaría usando de forma consistente. Cambios hechos “rápido”, “porque el proveedor lo pidió por teléfono” o “porque el compañero de vacaciones lo dejó pendiente”.
Uno de esos siete casos podría coincidir temporalmente con un pago que Tesorería tendría que reconstruir semanas después porque el proveedor reclama el cobro —exactamente el patrón del fraude BEC, donde el doble perjuicio no es solo el dinero desviado, sino la obligación de pagar de nuevo al acreedor legítimo. Sin nueva pérdida económica, quizá; pero sí horas de trabajo, tensión entre áreas y una pregunta que ningún auditor deja pasar: ¿quién autorizó esto y con qué criterio?
Ahí deja de ser un tema de ciberseguridad lejana y pasa a ser control interno operativo.
Registrar cambios no es lo mismo que supervisarlos
Business Central deja constancia de quién cambió qué y cuándo. Es imprescindible. Pero en la práctica ocurre lo siguiente:
- El registro crece cada día y nadie lo revisa de forma sistemática.
- Una modificación legítima y otra hecha a escondidas se ven iguales en el listado.
- La auditoría llega meses después, cuando reconstruir el contexto cuesta el triple.
- Tener un procedimiento definido no garantiza que se haya seguido en cada caso real.
El vacío no es tecnológico. Es de supervisión continua: saber a tiempo qué acciones sensibles ocurrieron sin el circuito de control previsto.
Muchas organizaciones descubren ese hueco demasiado tarde: cuando preparan una certificación, cuando llega una reclamación de un proveedor o cuando alguien pregunta por un pago concreto y empieza la búsqueda de correos.
Qué aporta la auditoría continua (más allá del registro)
Lo que falta no es otro informe estático ni más hojas de cálculo paralelas al ERP. Lo que falta es una respuesta directa a una pregunta sencilla: ¿esta acción crítica pasó por el control que diseñamos?
Eso es lo que aportan los informes de cumplimiento dentro de AWH GRC: una vista periódica de las acciones sensibles del ERP y de cuáles quedaron sin la supervisión prevista. No sustituyen el registro nativo de Business Central; lo completan con una lectura orientada al control interno.
En términos de negocio, el valor es concreto:
- Detección temprana de desvíos, no solo reconstrucción a posteriori.
- Menos dependencia de memoria de equipo o de cazar correos dispersos.
- Evidencia operativa cuando Finanzas, Compliance o auditoría preguntan qué pasó en un periodo.
- Cierre del ciclo entre diseñar un procedimiento y comprobar que se aplica de verdad.
Entre las situaciones que conviene vigilar están precisamente las que aparecen una y otra vez en los fraudes BEC recientes —como cambios en datos bancarios de proveedores—, pero también en errores operativos perfectamente evitables.
Qué haría esa empresa para cerrar el ciclo
La respuesta no sería “más formación genérica sobre phishing”. Sería convertir la supervisión en hábito operativo.
1. Revisar excepciones con regularidad, no solo en auditoría
Compliance y Finanzas acordarían quince minutos semanales para repasar qué acciones sensibles ocurrieron sin el control esperado. La regla sería simple: cada excepción se investiga o se justifica. No se archiva “para más adelante”.
2. Separar el caso puntual del fallo de diseño
De las siete modificaciones sin supervisión del trimestre, tres podrían tener explicación razonable (urgencia real, proveedor nuevo en onboarding). Otras cuatro no.
Ahí la conversación deja de ser “alguien se saltó la norma” y pasa a ser “nuestro control no es lo bastante operativo”. La respuesta no sería un email de regañina, sino reforzar el enlace entre cambio sensible y aprobación obligatoria —el mismo enfoque que desarrollamos en nuestro artículo sobre cambio de cuenta bancaria de proveedor.
3. Unificar evidencia donde ocurre la operación
Cuando una acción crítica sí pasa por el procedimiento previsto, la evidencia debería quedar en el mismo contexto operativo, no repartida entre Teams, correo y memoria individual.
Dejaría de ser una conversación del tipo “confiamos en que Marta lo revisó”. Pasaría a ser algo que Finanzas o Compliance pueden consultar sin reconstruir el caso a mano.
Tres preguntas para saber si te pasa lo mismo
Antes de asumir que “ya lo tenemos cubierto”, conviene responder con honestidad:
- ¿Sabes cuántas acciones sensibles hubo en Business Central el último mes?
- ¿Puedes identificar cuáles no pasaron por el procedimiento previsto?
- ¿Alguien revisa eso con regularidad, o solo cuando se acerca una auditoría?
Si alguna respuesta es no, el problema no es la falta de normativa externa. Es la falta de auditoría continua dentro del ERP.
Los informes de cumplimiento no añaden burocracia por añadir. Traducen una pregunta que todo CFO debería poder hacer —¿qué pasó ayer en nuestros datos críticos y estuvo supervisado?— en algo que el equipo puede mirar, discutir y corregir a tiempo.
Porque en control interno, el peor escenario no es solo perder dos millones en una transferencia fraudulenta. Es descubrir meses después que el sistema avisó, pero nadie estaba mirando.
