Tres mil doscientos clientes y un archivo de Excel
Toda operación de distribución de energía a escala residencial enfrenta, tarde o temprano, el mismo cuello de botella: la reconciliación de pagos. Para una empresa distribuidora de gas LP que atiende edificios residenciales en zona metropolitana, ese momento llegó cuando la cartera superó los tres mil clientes activos y el volumen de pagos diarios alcanzó los doscientos movimientos. El proceso que había funcionado con ochocientos clientes comenzó a colapsar bajo su propio peso. No porque los operadores trabajaran mal —trabajaban bien, con el único sistema que tenían— sino porque el sistema era fundamentalmente incapaz de escalar.
El flujo operativo heredado consistía en descargar manualmente cada mañana el archivo de movimientos bancarios del portal del banco, abrirlo en Excel, y contrastar uno a uno cada pago recibido contra una base de clientes mantenida en otra hoja de cálculo. La identificación dependía de la memoria del operador, de convenciones de nomenclatura no siempre respetadas en las referencias de transferencia, y de la disponibilidad de historial físico cuando el monto no correspondía exactamente al consumo del periodo. En días con volumen alto, el proceso consumía entre cuatro y cinco horas de trabajo de una persona. Todos los días, sin excepción.
Los errores de asignación —pagos aplicados al cliente incorrecto, pagos no identificados que se quedaban en un limbo contable semanas, referencias bancarias ambiguas que requerían llamadas de verificación al residente— generaban un segundo ciclo de correcciones que añadía tiempo y degradaba la confianza del departamento contable en la información que recibía. La estimación interna era que entre el 8% y el 12% de los pagos diarios requerían algún tipo de intervención manual adicional más allá de la asignación inicial. Con doscientos pagos al día, eso son entre dieciséis y veinticuatro excepciones que alguien tiene que resolver.
Cuatro sistemas que reemplazan un proceso único y frágil
El diseño de Corinto parte de una decisión arquitectónica deliberada: no construir un sistema monolítico que haga todo, sino cuatro módulos con responsabilidades claras y bien delimitadas que operan en secuencia y pueden mantenerse o actualizarse de forma independiente. Esta separación no es burocrática —es la diferencia entre un sistema que un equipo de dos personas puede operar y evolucionar, y uno que requiere intervención del equipo de desarrollo para cualquier ajuste operativo.
Módulo de carga de pagos
El primer punto de entrada del sistema es la carga del archivo de movimientos bancarios. Cada mañana, el operador descarga desde el portal del banco el archivo Excel acumulativo del mes en curso y lo sube al sistema. El módulo de carga ejecuta una validación en tres pasos: primero verifica que el archivo corresponde a la cuenta bancaria configurada, descartando movimientos de otras cuentas o conceptos distintos a pagos de clientes; segundo, filtra únicamente los movimientos del día actual, ignorando los registros ya procesados en cargas anteriores; tercero, verifica contra la base de datos de pagos ya conciliados que ninguno de los movimientos nuevos haya sido cargado previamente, garantizando idempotencia incluso si el operador carga el mismo archivo dos veces por error. El resultado es una lista limpia de pagos pendientes de conciliación, lista para el módulo core.
Módulo core de conciliación
El corazón operativo del sistema ofrece cuatro métodos de asignación que se aplican en orden de confiabilidad descendente. El primero y más potente es el procesamiento masivo por referencia bancaria: el sistema compara automáticamente cada pago descargado contra la base de clientes buscando coincidencias exactas en el campo de referencia de transferencia. Cuando encuentra un match —que en condiciones normales ocurre para entre el 72% y el 80% de los pagos diarios— lo asigna y lo marca como conciliado sin intervención humana.
Los pagos que no encuentran match por referencia pasan a la revisión asistida, donde el operador dispone de tres herramientas adicionales. El historial de consumo presenta, para un pago seleccionado, los clientes cuyo consumo del periodo activo coincide exactamente o aproximadamente con el monto recibido, ordenados por probabilidad de correspondencia. El historial de pagos permite buscar a cualquier cliente manualmente y revisar sus movimientos históricos —montos habituales, frecuencia de pago, banco de origen— para determinar si el pago anómalo corresponde a ese cliente por su comportamiento pasado. El registro de efectivo habilita la entrada manual de pagos cobrados en el momento de entrega de recibos mensuales, manteniendo todos los canales de pago dentro del mismo sistema de conciliación.
Módulo de exportación
Una vez concluida la jornada de conciliación, el módulo de exportación toma todos los pagos asignados durante el día y produce un archivo Excel con la misma estructura del archivo bancario original, enriquecido con la columna de asignación de cliente. Este archivo es el insumo directo que el departamento contable utiliza para su procesamiento posterior. La decisión de mantener el formato del archivo bancario original como base de la exportación fue deliberada: elimina cualquier curva de aprendizaje en contabilidad y garantiza compatibilidad con los procesos contables existentes sin requerir cambios en los flujos del departamento receptor.
Módulo de visualización y análisis
El módulo de datos resuelve una necesidad que el proceso anterior dejaba completamente sin atender: la visibilidad del estado financiero de cada cliente de forma individual. El operador puede seleccionar cualquier cliente de la cartera y acceder a su historial completo de consumos —metros cúbicos por periodo, importe generado, fecha de entrega del recibo— cruzado con su historial de pagos: monto, fecha, banco de origen y estado de conciliación. Esta vista combinada es la que permite resolver los casos ambiguos en el módulo de conciliación y es también la base para el segundo producto del módulo.
El reporte de adeudos consolida en un solo documento exportable el estado financiero actualizado de la cartera completa: consumo del periodo activo, pagos registrados, saldo pendiente, y clasificación de cada cliente como al corriente, con adeudo parcial, o sin pago registrado en el periodo. Este reporte, que antes requería construcción manual en Excel cruzando dos archivos distintos, se genera ahora con un solo clic y refleja el estado al momento exacto de la exportación.
Medio día laboral recuperado, todos los días
El indicador principal de éxito del proyecto se definió desde el diagnóstico inicial: reducir el tiempo diario dedicado al proceso de conciliación de pagos. La medición pre-implementación documentó un promedio de 4.3 horas diarias invertidas por un operador dedicado exclusivamente a esta tarea, con picos de hasta 5.5 horas en días de inicio de mes cuando los pagos acumulados de fin de semana llegaban juntos el lunes por la mañana.
El 78% de asignación automática por match de referencia bancaria corresponde al promedio de los primeros 90 días en producción. Este porcentaje varía entre el 68% en días con alto volumen de pagos en efectivo —que por definición no tienen referencia bancaria— y el 89% en días donde la mayoría de los pagos son transferencias electrónicas con referencia bien formateada. El 22% restante se resuelve mediante los tres métodos asistidos del módulo de conciliación, con un tiempo promedio de resolución por pago de aproximadamente 45 segundos frente a los 4-6 minutos del proceso manual anterior.
El impacto en errores de asignación fue igualmente significativo. En el primer mes de producción, los pagos que requirieron corrección posterior a su asignación inicial representaron el 1.3% del total, frente al 8-12% documentado en el proceso heredado. La diferencia se explica principalmente por la eliminación del factor de fatiga cognitiva: en el proceso manual, los errores se concentraban estadísticamente en los pagos procesados después de la tercera hora de trabajo. En el sistema actual, la precisión del matching automático es constante independientemente del volumen o la hora del día.
Un sistema diseñado para operar sin ingenieros presentes
El criterio de diseño arquitectónico de Corinto fue que el sistema debía ser completamente operable por el equipo administrativo de la empresa, sin requerir conocimiento técnico más allá del que ya tienen para usar Excel y el portal bancario. Esto tiene implicaciones concretas en cada decisión: el módulo de carga acepta el archivo Excel tal como lo produce el banco, sin transformaciones previas; el módulo de exportación produce un archivo en el mismo formato que el departamento contable ya procesa; y el módulo de conciliación presenta la información en el orden exacto en que el operador la necesita para tomar decisiones, no en el orden en que es conveniente para el sistema generarla.
El backend en .NET expone una API REST con autenticación por token que sirve los cuatro módulos desde el mismo servidor. La separación entre módulos es conceptual y de interfaz, no de infraestructura: todos comparten la misma base de datos PostgreSQL y el mismo motor de negocio. Esta decisión reduce la superficie de operación considerablemente —un solo servidor, un solo proceso, un solo punto de monitoreo— a costa de un acoplamiento interno que se justifica por el tamaño del equipo que va a mantener el sistema a largo plazo.
El procesamiento de archivos Excel —tanto la lectura del archivo bancario en la carga como la escritura del archivo enriquecido en la exportación— está completamente delegado a Python mediante un microservicio interno invocado desde el backend .NET vía HTTP local. Esta separación no es arbitraria: el ecosistema de Python para manipulación de archivos Excel (openpyxl, pandas) es sustancialmente más maduro que sus equivalentes en .NET, y la lógica de formato del archivo bancario —que varía según el banco e incluye celdas fusionadas, rangos con nombre y estilos condicionales— requiere control fino del archivo a nivel de celda que Python maneja con mayor naturalidad.
El frontend en Vue 3 con Composition API se estructura en cuatro vistas principales, una por módulo, con un componente de búsqueda de clientes compartido que aparece contextualmente en la conciliación asistida y en la visualización de datos. El estado de la sesión de conciliación —qué pagos han sido revisados, cuáles han sido asignados, cuáles están pendientes— se mantiene en el servidor entre sesiones, permitiendo que el operador cierre el navegador, regrese horas después, y continúe exactamente donde dejó la jornada de conciliación.
Tecnología que el equipo de mantenimiento puede sostener
La selección de tecnologías en Corinto estuvo condicionada por un factor que los proyectos internos de software frecuentemente ignoran: ¿quién va a mantener esto en dos años? La respuesta en este caso era clara desde el inicio —el equipo de TI interno de la empresa, de tamaño reducido, con experiencia consolidada en el ecosistema .NET y sin capacidad de incorporar nuevas plataformas a su stack de operaciones. Las elecciones de backend, base de datos e infraestructura de servidor siguieron estrictamente este criterio.
Vue 3 en el frontend fue una elección del equipo de desarrollo basada en velocidad de implementación y la naturaleza del sistema: cuatro vistas con interacción moderada, sin necesidad de renderizado del lado del servidor ni SEO, con un único perfil de usuario autenticado. La curva de aprendizaje del framework para futuras modificaciones de interfaz es suficientemente accesible para que el equipo de TI interno pueda realizar ajustes menores de layout o de comportamiento sin requerir apoyo externo.
La decisión más discutida del proyecto fue separar el procesamiento de Excel en un microservicio Python en lugar de usar las librerías disponibles en .NET. El argumento técnico fue concluyente cuando se evaluó el archivo de exportación real del banco: 47 columnas, combinación de estilos por celda, rangos con nombre utilizados por fórmulas del departamento contable, y un esquema de colores condicional que el área financiera usa para clasificar movimientos visualmente. Replicar esa estructura con fidelidad suficiente para que contabilidad pudiera continuar su flujo sin cambios requería openpyxl con acceso directo a la especificación OOXML del archivo. Fue la elección correcta.