Automatización de conciliación bancaria multiempresa

Contexto

En un grupo empresarial B2B, la conciliación bancaria se resolvía a mano: el equipo bajaba los extractos de cada banco y armaba, sobre esos datos, las planillas que después se importan al ERP. Qué movimiento era una cobranza, cuál una transferencia entre empresas del grupo y cuál una venta de moneda dependía del criterio de quien revisaba el extracto. El alcance final cubrió las cuatro empresas del grupo, 9 bancos en 3 países y 4 monedas.

Problema

El problema tuvo dos capas. La primera: el criterio de clasificación era conocimiento tácito, no una regla escrita, así que el resultado dependía de quién hiciera la revisión ese mes.

La segunda apareció al escalar de unas pocas cuentas a las 28 del grupo completo: el motor resolvía el banco y el formato por el nombre del archivo, y sobre el conjunto completo de un mes solo 6 de 28 extractos se leían correctamente. El resto fallaba distinto —cero movimientos sin aviso, error, o importes que no correspondían al contenido real—, y una corrida sin errores visibles podía omitir un banco entero sin que nadie lo notara, con destino final en un asiento contable.

Solución

El diseño se ordenó en cuatro reglas: clasificación explícita y auditable; nunca fallar en silencio ni inventar un dato; revisión humana antes del ERP, con semáforo de certeza; y trabajo organizado en tareas chicas e independientes.

• Motor que clasifica los movimientos y genera las plantillas de importación al ERP, integrado en una aplicación web con flujo guiado de carga, revisión y descarga.
• El formato de cada extracto pasó a detectarse por su contenido —no por el nombre del archivo—, el banco por marcadores de texto y las columnas por su cabecera.
• Registro de líneas ya entregadas para no duplicar asientos entre corridas.
• Ventana de búsqueda para asociar cada cobro con su factura, calibrada sobre datos reales del grupo.

Resultados

• Sobre el mismo conjunto de datos usado para medir el problema, el resultado tras el rediseño fue de 28 extractos leídos sobre 28 (antes, 6 sobre 28).
• 1.785 movimientos verificados contra la cadena de saldos de cada extracto, sin cambios en la clasificación por semáforo respecto de la corrida previa.
• Movimientos sin categoría: de 9,0 % a 0,5 %. Falsos cobros: de 12 a 0.
• Cruce de cobranzas: 484 movimientos comparados contra 5.635 facturas abiertas, con 121 en verde, 291 en amarillo y 72 en rojo.
• Cada corrida entrega 11 archivos listos para importar al ERP, uno por empresa y tipo de movimiento.
• El sistema opera en un ambiente de prueba; la validación de extremo a extremo corresponde al negocio.

Arquitectura y decisiones

El sistema se organizó en dos capas. Un motor de clasificación concentra la lógica de negocio: identifica el banco y el formato de cada extracto por su contenido, clasifica los movimientos según reglas documentadas como datos editables (no como lógica fija) y genera las plantillas de importación al ERP para cobranzas de clientes, movimientos entre empresas del grupo y venta de moneda. Ese motor se reutiliza, sin reescribirse, tanto desde línea de comandos como desde una aplicación web con flujo guiado: subir extractos, previsualizar lo normalizado, traer facturas abiertas del ERP, revisar con semáforo y descargar los archivos listos. Una prueba automática verifica que ambos caminos den el mismo resultado sobre el mismo insumo.

La incorporación de un banco nuevo se resolvió como la declaración de un perfil de lectura (marcadores de texto y cabeceras esperadas), sin tocar el motor de clasificación existente. El registro de líneas ya entregadas evita duplicar asientos entre corridas sucesivas sobre el mismo período. El ambiente de ejecución quedó desplegado en contenedor, con autenticación corporativa y migraciones de base de datos automáticas.