Imagina que alguien de tu equipo recibe un correo de un proveedor de confianza. Todo parece normal: mismo remitente aparente, tono habitual, factura pendiente. Solo cambia un detalle: pide que el próximo pago vaya a una cuenta nueva. Se actualiza el maestro en Business Central, Tesorería emite el pago, se cierra el mes.
Semanas después, el proveedor real llama preguntando por qué no ha cobrado.
El patrón se repite en empresas de todos los tamaños y también en administraciones públicas. Solo en los últimos meses hay casos documentados en España: el Ayuntamiento de Valencia detectó en 2024 un fraude de unos 194.000 euros en el Palacio de Congresos tras no cumplirse el protocolo interno de verificación de cambios de cuenta (El Mundo), y el Ayuntamiento de Huércal‑Overa fue víctima en 2026 de una estafa “Man in the Middle” en la que se modificó la cuenta del proveedor en los correos de facturación (Europa Press). A mayor escala, INTERPOL publicó en 2024 el caso de una empresa que transfirió 42,3 millones de USD a un falso proveedor por un email de apariencia legítima (INTERPOL).
Si le puede pasar a ayuntamientos con procedimientos formales y a multinacionales con equipos financieros maduros, le puede pasar también a tu empresa.
Dónde está el riesgo real (y por qué se repite tanto)
El fraude en cambios bancarios rara vez empieza en Tesorería.
Empieza antes, en cómo se gobierna el dato maestro del proveedor. Los fallos más habituales son cuatro:
- Solicitud = aprobación: se recibe una petición por email y se interpreta como autorización.
- Una sola persona hace todo: valida, aprueba y aplica el cambio el mismo rol.
- Evidencia dispersa: la justificación vive en correos y llamadas, fuera del ERP.
- Sin plazos de validación: hay tareas críticas abiertas durante días sin escalado.
Cuando coinciden dos o tres de estos puntos, no hace falta un atacante sofisticado: basta con un email verosímil o un empleado con acceso suficiente.
Cómo debería gobernarse este proceso en Business Central (con AWH integrado)
La solución no es añadir burocracia ni montar un circuito paralelo en hojas de cálculo. La solución es que el cambio de cuenta bancaria no pueda ejecutarse fuera de un proceso controlado dentro del propio ERP. Aquí es donde Business Central, reforzado con AWH, convierte el control interno en algo operativo y no decorativo.
Separar solicitud de autorización desde el primer minuto
La trampa mental más habitual es tratar un correo entrante como autorización suficiente.
No lo es.
Cuando entra una petición de cambio bancario, lo primero es abrir un proceso formal vinculado al proveedor, adjuntar documentación mínima y dejar el dato bancario intacto hasta que alguien valide. AWH permite modelar esa primera etapa con instrucciones obligatorias y comentarios estructurados, de modo que todas las solicitudes entren por el mismo carril, independientemente de quién las reciba.
Verificar la identidad por un canal distinto al que trajo la solicitud
Si la petición llegó por email, la validación no puede hacerse respondiendo a ese mismo email. Hay que contrastar con un contacto conocido en ficha, un canal contractual previo o una verificación telefónica a un número que ya tuviéramos.
Esa comprobación, hoy, suele quedar fuera del sistema, y eso es parte del problema. Con AWH puede convivir como una etapa específica del proceso, con responsable asignado y evidencia adjunta en la tarea: deja de ser una buena práctica verbal y se convierte en un paso que el flujo exige antes de avanzar.
Aplicar una segregación de funciones real, no nominal
Segregar no es pedir un “OK por Teams” a otro compañero.
Es asegurar que quien valida y quien aprueba son personas distintas, y que el sistema lo hace cumplir.
AWH permite asignar propietario por usuario o departamento en cada etapa y apoyarse en tareas de usuario de Business Central para formalizar aprobación o rechazo, dejando constancia de quién decidió qué y cuándo. Si la misma persona intenta cerrar ambos pasos, el diseño del flujo lo frena.
Controlar el tiempo, no solo el contenido
Los cambios bancarios sensibles no deberían quedarse “pendientes de revisar” durante una semana. Cada etapa tiene que tener un tiempo objetivo razonable, y el sistema debe poder detectar qué está fuera de plazo. AWH soporta duraciones por horas laborables, días laborables o días naturales, y ofrece visibilidad de tareas vencidas.
Ejecutar el cambio solo cuando el control esté cerrado
Una vez validado y aprobado, se actualiza el registro bancario del proveedor en Business Central. Lo importante es que la edición no llegue antes que las aprobaciones: la actualización es el final del proceso, no un atajo que justificamos después. Al ejecutarlo dentro del flujo, el cambio queda unido a sus evidencias, sus responsables y su secuencia, y no como una edición aislada de maestro.
Cerrar con una trazabilidad que sirva para auditoría
El último paso no es cosmético.
Al cerrar el proceso queda claro quién solicitó, quién validó, quién aprobó, cuándo, con qué documentación y con qué criterio.
AWH concentra ese historial y permite consultarlo junto al contexto del ERP, lo que reduce de forma notable el tiempo de preparación ante una auditoría interna, una revisión externa o, llegado el caso, una investigación de incidente.
Si se quiere un control realmente operativo, conviene además enlazar este diseño con los workflows estándar de Business Central. AWH incorpora eventos y respuestas para escenarios de cambio en registros bancarios de proveedor, de forma que el control vive donde ocurre la operación y no en un circuito aparte.
Qué se nota cuando el proceso está realmente bajo control
El efecto más inmediato es aburrido, y en este terreno eso es una buena noticia: los cambios de cuenta dejan de generar sobresaltos. Cuando el flujo obliga a validar, separa responsabilidades y deja evidencia estructurada, el riesgo de pago desviado por suplantación cae de forma significativa y, sobre todo, deja de depender del criterio de quien recibe el correo.
También cambia la relación con la auditoría. Demostrar quién hizo qué deja de ser una carrera de última hora por recuperar correos y adjuntos, y pasa a ser una consulta directa dentro del ERP. Aunque cada organización tiene sus métricas, hay cuatro indicadores que conviene vigilar para medir la mejora:
- el tiempo medio desde la solicitud hasta la aprobación final
- el porcentaje de cambios con doble validación efectiva
- las tareas vencidas en etapa de validación o aprobación
- las incidencias de pago vinculadas a cambios bancarios recientes
Si esos cuatro números mejoran, el control está funcionando.