Continuidad de la conciliación: recuperar procesos sin duplicar efectos

Separar fallas técnicas de diferencias de negocio

Este artículo desarrolla un control específico del proceso de conciliación automatizada: conserva separadas la venta, la liquidación y la confirmación del abono.

Un proveedor puede responder correctamente y entregar un archivo incompleto. También puede fallar una descarga aunque el dinero ya esté en la cuenta. El estado de la integración y el estado del recaudo responden preguntas distintas: ambos deben conservarse.

Clasifica cada incidente por fuente, entidad, moneda y período. Separa fuente ausente, formato incompatible, registros duplicados, regla no evaluable y abono vencido. Una fila sin datos suficientes no es una diferencia confirmada ni una partida conciliada.

Conocer la cobertura antes de cerrar

Mantén un registro de archivos esperados y recibidos, su fecha de corte y la última carga válida. Un proceso terminado no prueba que todas las tiendas o medios de pago estén cubiertos. Publica el período pendiente junto al resultado disponible.

Define con operación qué hacer en modo degradado: continuar con fuentes completas, suspender un cálculo dependiente o pasar un caso a revisión. El cierre parcial debe identificarse como parcial. No reutilices silenciosamente el archivo de ayer para presentar un cierre de hoy.

Recuperar un archivo sin volver a registrar la liquidación

Ejemplo ilustrativo: el archivo de liquidación de un comercio llega completo, pero el extracto bancario no está disponible al corte. El proceso puede validar ventas y comisiones; no puede dar por confirmado el abono. La cobertura debe mostrar qué fuente falta y para qué período, en lugar de convertir todas las operaciones en diferencias de dinero.

Cuando llegue el archivo bancario, conserva el lote original y agrega una nueva versión de la evidencia. Repite solamente los cruces que dependían de esa fuente. La identidad del archivo no basta para evitar duplicados: un proveedor puede reenviar las mismas operaciones en un archivo con otro nombre. También necesitas identidad de operación, período y comercio.

Una caída después de solicitar un ajuste exige una decisión distinta. Antes de reenviar, consulta si el sistema receptor ya lo registró. Si no es posible comprobarlo, envía el caso a revisión y conserva la incertidumbre. Reintentar una lectura suele ser recuperable; repetir un ajuste financiero sin conocer su resultado puede duplicar el efecto.

Prueba la recuperación con tres cortes: antes de recibir la fuente, después de calcular el resultado y después de enviar una acción. En cada corte, exige que el total de operaciones únicas sea el mismo y que las acciones confirmadas no se repitan. La prueba termina cuando se reconstruye el cierre, no cuando el proceso vuelve a estar encendido.

Recuperar desde un punto verificable

Antes de reintentar, identifica el lote y los efectos ya producidos. La clave de una operación debe permitir reconocer el mismo evento incluso si llega en otro archivo. Distingue volver a leer datos de volver a registrar un ajuste, notificar un caso o ejecutar un movimiento.

Reprocesa primero en un alcance limitado. Compara cantidad de registros, importes y casos abiertos antes y después. Si cambió una regla, conserva su versión y explica qué población se recalculó. El historial anterior permite reconstruir por qué un resultado cambió.

Asignar un responsable y una condición de salida

Para cada tipo de falla, deja un responsable, un plazo operativo, la evidencia necesaria y la acción permitida. Tecnología puede recuperar una integración; finanzas debe validar la diferencia de negocio. Un reintento exitoso no autoriza por sí solo a cerrar el caso financiero.

La aceptación debe comprobar cobertura, ausencia de efectos duplicados y consistencia de saldos. Si el problema persiste, la cola necesita prioridad por vencimiento y exposición, no únicamente por número de errores técnicos.

Ensayar la recuperación

Prueba archivos tardíos, duplicados y corregidos, interrupciones a mitad del lote y cambios de formato. Registra el tiempo hasta recuperar un cierre utilizable, las partidas aún no evaluables y los efectos duplicados detectados.

Establece objetivos de frescura y recuperación por fuente. Si las cargas se completan rápido pero la revisión humana acumula días, el cuello de botella está en la resolución. Ajusta el procedimiento donde falla el cierre real, no solo donde aparece la alarma.

• Fuente recuperada
• Operaciones sin duplicar
• Resultado bancario verificado