Los clientes de Nester gestionaban sus finanzas a trozos: conciliando a mano, una hoja de cálculo cada vez.
Comparar los movimientos bancarios con las facturas era lento y propenso a errores, y dejaba a los gestores sin una visión real y actualizada de su flujo de caja. Sin ella, los clientes exportaban datos o recurrían a herramientas de terceros solo para cerrar sus cuentas. Integramos WealthReader para traer la agregación de cuentas directamente a Nester.
Una funcionalidad tan grande que había que dividirla en tres.
Automatizar sin datos reales
El objetivo final era la conciliación automática, pero diseñar esa lógica de cruce antes de ver una sola transacción real implicaba construir reglas sobre suposiciones —cómo era una descripción de pago “típica”, con qué frecuencia aparecían los casos límite— en lugar de sobre patrones reales.
Tres fases, no una gran apuesta
En lugar de lanzar la automatización como un único bloque grande e incierto, el equipo dividió el desarrollo: primero conectar y visualizar, después la conciliación manual y, por último, la automatización, cuando ya hubiera datos reales de transacciones con los que diseñarla.
Dejar que el uso real enseñe al sistema antes de pedirle que piense solo.
Diseñar para datos que todavía no tienes
El lanzamiento por fases funcionó también como estrategia de research. Lanzar primero la conexión bancaria en modo solo lectura permitió a Nester observar la tipología real de las transacciones antes de definir las reglas automáticas de la Fase 3.
Un cruce que tiene que ser exacto, no aproximado
La conciliación manual se diseñó como un espacio de trabajo maestro-detalle con dos tablas: movimientos bancarios a la izquierda y registros de Nester sin conciliar a la derecha. Un resumen en directo calcula la diferencia entre los dos importes seleccionados, y el botón “Conciliar” solo se activa cuando esa diferencia es exactamente 0,00 €, para que un cruce aproximado no pueda descuadrar las cuentas sin que nadie lo note.
El caso que nadie había contemplado
A mitad del proyecto, diseñamos qué pasa cuando un ingreso bancario es mayor que la factura con la que se cruza. El sistema detecta el excedente automáticamente y permite al gestor resolverlo como saldo a favor del inquilino —que se aplica solo a la siguiente factura— o como ajuste por redondeo.
Tres fases, cada una con algo útil por sí misma.
Fase 1: conectar y visualizar
Vinculación bancaria mediante el widget de WealthReader, una vista consolidada de Tesorería › Bancos con un gráfico de flujo de caja de 12 meses, y una vista de detalle de cada banco con una tabla de movimientos con búsqueda y filtros.
Fase 2: conciliación manual
Una tarjeta de estado de conciliación (pendiente frente a conciliado, con barra de progreso) como punto de entrada, el propio espacio de conciliación y un atajo para crear un gasto o una factura que faltaba directamente desde un movimiento sin conciliar: prerrellenado y conciliado automáticamente al guardar.
Fase 3: automatización, diseñada pero aún no construida
Sugerencias de cruce según importe, fecha y descripción; reglas configurables; conciliación automática 1:1 para los cruces de alta confianza, e informes avanzados de conciliación.
Lanzar bajo presión real sin recortar en lo que importaba.
Mantener el listón de calidad
Días antes del lanzamiento previsto de la Fase 2, el equipo detectó que la lógica de pagos no tenía los riesgos totalmente controlados y retrasó la fecha una semana en lugar de lanzar algo incierto. El deploy que vino después se reconoció internamente como uno realmente difícil y bien hecho.
Lo que reveló el producto en producción
Revisar la Fase 2 en producción sacó a la luz huecos que la revisión de diseño no había detectado: a las tarjetas de bancos conectados les faltaban los mismos contadores de conciliados/pendientes que ya se mostraban en el detalle de cada banco. Quedó registrado para el siguiente release, no para un rediseño.
Lo que sigue abierto
Todavía no hay un flujo definido para desconciliar un pago cuando se devuelve un cargo bancario; los permisos son solo de Admin en el MVP, con un sistema de roles flexible aún por diseñar; cruzar un pago con varias facturas todavía no está definido; y los umbrales de confianza de las sugerencias de la Fase 3 siguen siendo una pregunta abierta.
La secuencia es una decisión de diseño, no solo de alcance.
Dividir el desarrollo en tres fases no fue hacer menos: fue negarse a diseñar la parte más difícil, la automatización, a partir de suposiciones cuando los datos reales de uso estaban a una fase de distancia.
