Reconciliar no es cuadrar números: cuando una transferencia queda a medias

Una transferencia puede aparecer como «enviada» en un sistema y seguir sin resolverse en otro. No es una paradoja: cada sistema observa una parte distinta del recorrido. El proveedor conoce su propia operación; el libro interno conoce la intención y el estado que hemos registrado; el extracto bancario confirma —o todavía no confirma— lo que ha ocurrido en la cuenta.

Reconciliar no consiste en elegir el número que más nos gusta. Consiste en nombrar la discrepancia, conservar la evidencia y asignar a una persona el siguiente paso.

Las tres versiones de una misma operación

Cuando una operación se queda a medias, suelo poner estas tres fuentes una al lado de la otra:

• Estado del proveedor: qué recibió, qué procesó y qué referencia externa asignó.
• Libro interno: qué operación creíamos estar ejecutando, por qué importe y con qué estado local.
• Extracto bancario: qué movimiento aparece realmente, con fecha valor, referencia e importe.

Ninguna fuente es universalmente suficiente. La fuente autorizada depende del momento y de la función que se está comprobando. Lo importante es dejar escrita esa decisión, no resolverla de memoria en un chat.

El registro mínimo que evita volver a empezar

Un runbook útil no necesita una novela, pero sí un registro que otra persona pueda continuar. Para cada operación guardaría:

• identificador interno y referencia externa;
• importe y moneda, con su precisión original;
• timestamps y zona horaria de cada cambio;
• último estado confirmado y fuente que lo confirma;
• cuenta o destino enmascarado según la política de privacidad;
• responsable actual, siguiente acción y hora de la próxima actualización;
• enlace a la evidencia, con acceso restringido cuando corresponda.

El objetivo no es acumular datos. Es que una incidencia pueda pasar de operaciones a soporte, cumplimiento o un proveedor sin perder contexto.

Qué hacer cuando llega un timeout

El error más caro es reintentar porque la interfaz no sabe si el primer intento terminó. Ante un timeout, primero congelo cualquier reintento ambiguo. Después correlaciono las referencias y clasifico el caso como pending, partial, returned o unknown. «Unknown» no significa que el dinero se haya perdido; significa que todavía no hay evidencia suficiente para afirmar dónde está.

La idempotencia es la protección técnica para que una misma intención no se convierta en dos movimientos. La cola de excepciones es la protección operativa para que ningún caso se cierre sólo porque dejó de aparecer en la pantalla.

Comunicar hechos, incertidumbre y siguiente paso

Un buen mensaje a un usuario o a un partner tiene tres capas: lo que sabemos (referencia, importe, último estado), lo que aún no sabemos (por ejemplo, si el banco ha abonado) y qué ocurrirá después (responsable y próxima actualización). Evito prometer una hora de liquidación que depende de terceros; sí puedo comprometer una hora de respuesta útil.

El cierre necesita evidencia

Una operación se cierra cuando existe evidencia de abono, devolución o reversión, y el libro interno refleja esa misma conclusión. Un correo diciendo «debería estar hecho» es una pista, no un cierre. Esa disciplina parece lenta hasta que se compara con el coste de duplicar un pago o explicar una cifra que nadie puede demostrar.

En la documentación pública de cumplimiento intento aplicar la misma idea: separar hechos, declaraciones y documentos originales. En productos que dependen de proveedores, la interfaz puede ser sencilla; la responsabilidad no puede ser ambigua.

Nota: contenido informativo basado en experiencia de producto. No constituye asesoramiento legal, regulatorio, fiscal o financiero ni una oferta de servicios. Las obligaciones concretas dependen de la entidad, el proveedor y la jurisdicción aplicables.

Fuentes

• BIS · CPMI — trabajo sobre pagos transfronterizos.
• Financial Stability Board — hoja de ruta del G20.
• ISO 20022 — mensajería financiera y referencias estructuradas.