Detectar anomalías financieras en datos de ERP en 2026 ya no es un proyecto de auditoría aislado, es una capa permanente sobre tu data lake que se ejecuta cada noche y manda alertas a la persona correcta. No buscamos problemas, los datos los revelan.
Esta guía cubre qué cuenta como anomalía, qué reglas mínimas tienes que tener corriendo, cuándo IA suma valor real, cómo se construye la bandeja de alertas y un caso real donde aparecieron hallazgos que ningún reporte mensual había revelado.
Qué cuenta como anomalía y qué no
Una anomalía financiera es cualquier registro o serie de registros que viola una invariante operativa o contable. Las anomalías serias caen en cuatro categorías:
Anomalías de integridad: Inventario negativo, asientos sin partida doble, facturas sin cliente asociado, pagos sin factura, llaves foráneas huérfanas. Estas son las más fáciles de detectar y las más comunes.
Anomalías de proceso: Servicios prestados pero no facturados, facturas emitidas pero no contabilizadas, comisiones pagadas dos veces, gastos sin orden de compra. Requieren cruzar módulos.
Anomalías de comportamiento: Operaciones fuera de horario, montos atípicos para el cliente, secuencias rotas de folios fiscales, usuarios que crean y aprueban su propia transacción. Requieren contexto histórico.
Anomalías estructurales: Esquemas de pago paralelos no documentados, archivos bancarios editados manualmente, registros borrados sin trail, balances que no cuadran entre módulos. Las más caras y las que más cuesta detectar.
El caso real: 197 tablas legacy y hallazgos invisibles
Una distribuidora con 10 años de operación llegó con SQL Server 2019, 197 tablas inconsistentes, 13 millones de filas legacy y reportes mensuales que mentían sobre dónde estaba el negocio. La arquitectura Bronze, Silver, Gold sobre Supabase tardó 12 semanas en levantarse. Los hallazgos invisibles aparecieron sin buscarlos durante las primeras 6 semanas:
- 3.6M filas migradas en 48 horas con chunking paralelo por rango de PK
- 197 tablas snapshot, 825 vistas Silver, 75 tablas Gold materializadas
- Verificación fila por fila entre fuente, bronce, plata y oro
- Inventario con cantidades negativas en 12 sucursales (problema de proceso)
- Servicios prestados pero nunca facturados (fuga de ingresos calculable)
- Archivos bancarios editados manualmente en formato propietario (riesgo de integridad)
- Esquemas de pago paralelos no registrados (registros manipulados)
Ningún reporte mensual había revelado los tres últimos puntos. El data lake los expuso en consultas SQL simples. La regla aplica universalmente: cuando los datos se unifican, los problemas se anuncian solos.
Las 8 reglas mínimas que tienen que estar corriendo
Para una pyme LATAM con ERP estándar (Odoo, SAP B1, Contpaqi, Siigo, Aspel), estas 8 reglas SQL deterministas detectan el 80 por ciento de anomalías serias sin necesidad de IA:
| Regla | Qué valida | Severidad típica |
|---|---|---|
| 1. Suma de partidas igual a cero | Cada asiento contable cuadra debe y haber | Crítica |
| 2. Inventario no negativo | Cantidad disponible siempre mayor o igual a cero | Crítica |
| 3. Facturas con cliente válido | Cada factura tiene FK a cliente existente | Alta |
| 4. Pagos con factura asignada | Cada cobro está vinculado a factura emitida | Alta |
| 5. Folios fiscales secuenciales | No hay huecos sin justificación en folios CFDI o equivalente | Alta |
| 6. Saldos cuadran entre módulos | Cartera AR cuadra con balance general | Crítica |
| 7. Operaciones en horario laboral | Transacciones fuera de horario se marcan para revisión | Media |
| 8. Mismo usuario crea y aprueba | Segregación de funciones, alerta cuando se viola | Alta |
Cada regla se codifica como test dbt o procedure SQL que corre diario contra la capa Gold del data lake.
Cuándo IA suma valor (y cuándo es marketing)
La IA suma valor real para detectar anomalías financieras solo después de tres condiciones cumplidas:
- Tienes data lake unificado con histórico de al menos 12 meses limpio
- Las 8 reglas deterministas ya corren y la bandeja de alertas está controlada
- Quieres detectar patrones nuevos que las reglas no contemplan
En esos casos, modelos como isolation forest o autoencoders detectan operaciones atípicas en montos, frecuencia o secuencia. Sin las tres condiciones, la IA produce falsos positivos que rompen la confianza del equipo financiero y nadie atiende las alertas.
Lo que sí funciona desde semana 1 es usar LLMs para narrativa sobre anomalías ya detectadas. KPIs y conteos en código TypeScript o SQL, narrativa generada con Claude o GPT sobre datos verificados. Auditable, defendible, sin alucinaciones en métricas.
Cómo se construye la bandeja de alertas
Una bandeja de alertas bien diseñada tiene cuatro elementos no negociables:
Severidad clasificada. Crítica, alta, media, baja. Cada anomalía detectada se clasifica al momento de la detección, no al momento de revisión.
Accountable nombrado. Cada categoría de anomalía tiene un responsable de revisión designado. Inventario negativo es para el gerente de operaciones, no para "el equipo de finanzas".
SLA explícito. Crítica se atiende en 24 horas. Alta en 72 horas. Media en 7 días. Baja se agrupa en reporte mensual.
Auditabilidad inmutable. Cada anomalía detectada se escribe a un log append-only con hash chain. Quién la atendió, cuándo, qué decisión tomó. Sin trail, las anomalías se "resuelven" borrándolas.
Herramientas open source que funcionan en LATAM
Para implementar detección de anomalías sin licencias caras:
- dbt para tests de integridad sobre Gold layer
- Great Expectations para validaciones de datos más complejas
- PostgreSQL con triggers para alertas en tiempo real sobre escrituras críticas
- Metabase para dashboard de bandeja de alertas con drill-down
- Sentry o similar para notificaciones cuando reglas fallan
- Python con scikit-learn para detección de outliers fase 2
El stack completo open source cubre 95 por ciento de necesidades de una pyme LATAM por menos de 200 USD al mes en infraestructura.
Lo que rara vez te dicen
La anomalía más cara es la que parece normal. Un servicio cobrado a precio menor del listado porque "es cliente histórico" no dispara ninguna regla automática. Hay que codificar la invariante explícita: precio facturado vs precio listado mínimo del catálogo. Esas anomalías estructurales son las que mueven la aguja.
Las anomalías cambian con la operación. Una regla útil hoy puede generar 200 falsos positivos al mes cuando cambias un proceso. Revisa el catálogo de reglas cada trimestre con el equipo financiero.
El backlog inicial duele. En las primeras 4 semanas, las reglas detectan acumulado histórico de 2 a 5 años. La bandeja se llena. Hay que asignar un sprint para resolver el backlog antes de operar en steady state.
Próximos pasos
Si tu ERP tiene más de 3 años de historia y nunca has corrido auditoría sistemática de integridad, hay anomalías invisibles esperando a ser descubiertas. Una capa de detección bien construida sobre tu data lake actual o construyendo el data lake desde cero entrega valor desde la semana 4.
En MAGIA Core entregamos discovery, data lake unificado, catálogo de reglas de detección y bandeja de alertas operativa en 12 semanas. Sin retainers, sin licencias atadas, código a tu nombre.