La conciliación se está volviendo una función de ingeniería, no de finanzas

El enfoque está mal planteado. La industria viene debatiendo si las herramientas de conciliación pertenecen al presupuesto de software del CFO o a la hoja de ruta de la plataforma de pagos, como si fuera una cuestión de compras. No lo es. La pregunta es arquitectónica: si la conciliación se trata como una capa de reporting montada sobre un stack de pagos, o como una garantía de consistencia de datos integrada en el stack mismo. Los equipos que entienden la diferencia están construyendo una infraestructura muy distinta de la de quienes no la entienden.

El catalizador de este cambio no es el volumen de transacciones. Los comercios de alto volumen siempre tuvieron flujos de conciliación complejos. El catalizador es la fragmentación de métodos de pago, y específicamente lo que esa fragmentación le hace al comportamiento de liquidación en un stack moderno multicanal y multi-PSP. Cuando un comercio opera con tarjetas, BNPL, transferencias bancarias locales, pagos en tiempo real, billeteras digitales y POS en tienda física, no está simplemente agregando más columnas a la misma hoja de cálculo. Está heredando modelos de tiempos de liquidación, esquemas de datos, secuencias de eventos de ciclo de vida y ventanas de exposición cambiaria (FX) fundamentalmente distintos, cada uno con sus propios modos de falla. Las hojas de cálculo no fallan en ese problema por ser poco potentes. Fallan porque el problema no es de cálculo. Es de consistencia de datos.

‍

¿Por qué la complejidad de la liquidación escala de forma no lineal?

Los pagos con tarjeta se liquidan en base D+1 o D+2 a través de la adquirencia. Los rieles de pago instantáneo se liquidan en segundos, pero reportan en lotes de forma distinta según el esquema. Los proveedores de BNPL liquidan neto de costos de financiación, en cronogramas negociados por comercio. Las transferencias bancarias locales en mercados como iDEAL en los Países Bajos, SEPA Instant en la eurozona o Faster Payments en el Reino Unido tienen cada una sus propios tiempos de notificación, mecánicas de reversa y representaciones de estados intermedios. Los contracargos en tarjetas tienen un ciclo de vida de 120 días. Los reembolsos en billeteras digitales pueden mantener estados intermedios que los PSP comunican de forma inconsistente.

A esto se le suma el omnicanal. Una terminal POS en una ubicación de retail físico suele liquidar en lotes al cierre del día. Un checkout de e-commerce conectado al mismo adquirente puede liquidar individualmente por transacción. Si una sola transacción de un cliente se inicia en tienda pero se completa por una app móvil (click-and-collect, flujo BNPL, QR de pago diferido), el sistema de origen y el de liquidación pueden no coincidir en qué canal es dueño del evento. El mismo adquirente, la misma red de tarjetas, el mismo comercio, pero el archivo de liquidación mapea a un centro de costos interno distinto, cae en una moneda distinta y llega en un cronograma distinto.

La consecuencia operativa es que cada método de pago agregado multiplica la cantidad de tipos de evento que hay que rastrear, la cantidad de estados terminales que una transacción puede ocupar y la cantidad de variantes de esquema que hay que normalizar antes de que pueda ocurrir cualquier emparejamiento. Los equipos de finanzas viven esto como una carga manual creciente en el cierre de fin de mes. Lo que en realidad está pasando es que la superficie de conciliación crece de forma combinatoria mientras las herramientas subyacentes siguen siendo lineales.

‍

El modo de falla de la hoja de cálculo es estructural, no operativo

El diagnóstico estándar para la falla de conciliación es el volumen: demasiadas transacciones para que los procesos manuales las absorban. Eso es cierto hasta cierto punto, pero se pierde la falla estructural, que es que la conciliación basada en hojas de cálculo asume una visión estática y sincrónica del estado del pago. Una transacción ocurrió o no ocurrió. La liquidación llegó o no llegó.

Un stack de pagos moderno no se ve así. Los ciclos de vida de los pagos son asincrónicos. Un pago autorizado no necesariamente está capturado. Un pago capturado no necesariamente está liquidado. Una liquidación que llega no necesariamente es conciliable contra la transacción original sin una cadena de eventos intermedios: algunos entregados por webhook, otros por archivo en lote, otros por consulta a la API, otros que llegan fuera de orden. El archivo de liquidación del PSP y el archivo de intercambio de la red de tarjetas representan la misma transacción desde perspectivas distintas, en cronogramas distintos, con identificadores distintos.

Este es el problema de ingeniería con el que se topan los equipos de finanzas cuando sus hojas de cálculo se rompen. El problema no es que la hoja de cálculo tenga el tamaño equivocado. Es que el modelo de datos detrás de ella no puede representar el estado real de un pago en un momento dado. Una fila en una hoja de cálculo es una instantánea. Un pago es una máquina de estados. La conciliación es el proceso de confirmar que todas las transiciones de estado que debían ocurrir, ocurrieron, en el orden correcto, contra los montos correctos.

Eso es un problema de ingeniería de software. Requiere rastreo de eventos, gestión de estados, normalización de esquemas entre fuentes heterogéneas, garantías de idempotencia en la ingesta de webhooks y un modelo de datos canónico que sobreviva a que los rieles de liquidación subyacentes cambien por debajo.

‍

La fragmentación de esquemas de los PSP es el impuesto invisible

Cada PSP que un comercio integra envía datos de liquidación en su propio esquema. Los identificadores de transacción no cruzan las fronteras entre PSP. Los eventos de reembolso se representan de forma distinta: algunos PSP envían un evento de reembolso separado, otros modifican el registro de la transacción original, otros envían ambos y esperan que el comercio elimine los duplicados. Los eventos del ciclo de vida del contracargo son aún más inconsistentes: la cantidad de estados, las convenciones de nombres y los tiempos de las notificaciones de ventana de disputa varían por PSP, por red de tarjetas y por región.

Cuando un comercio corre tres PSP, está manteniendo tres representaciones independientes de la realidad del pago. Sin una capa de normalización que preceda a la lógica de conciliación, el emparejamiento se hace de forma heurística: identificadores aproximados, cotejo difuso de marcas de tiempo, colas manuales de excepciones. La tasa de coincidencia suena aceptable hasta que el CFO pregunta por qué la variación de ganancia/pérdida cambiaria no puede atribuirse a nivel de transacción, o hasta que se pierde una fecha límite de respuesta a una disputa porque el evento de contracargo llegó en un formato de archivo de liquidación que las herramientas del equipo de finanzas no parsean correctamente.

La solución que está surgiendo es un modelo de eventos en la capa de orquestación: una representación interna canónica de los eventos de pago que normaliza entre los esquemas de los PSP antes de que algo toque los sistemas financieros. Los productos de conciliación que hoy se empaquetan dentro de infraestructura de pagos unificada se construyen sobre exactamente esta premisa: traer los datos de liquidación de los PSP, normalizarlos en un único libro mayor y exponer las discrepancias antes de que se conviertan en problemas de cierre de fin de mes. La conciliación se vuelve confiable no porque las herramientas de finanzas sean mejores, sino porque los datos de eventos que fluyen hacia ellas fueron estandarizados aguas arriba.

‍

¿Qué requiere realmente la conciliación como infraestructura?

El cambio organizativo hacia que ingeniería sea dueña de la conciliación no es principalmente una decisión estructural sobre quién es dueño de qué línea de presupuesto. Es una consecuencia de lo que la conciliación moderna realmente requiere: una capa de datos en tiempo real, basada en eventos, que capture cada transición de estado en el ciclo de vida de un pago, enriquecida con los datos necesarios para emparejarla aguas abajo.

Eso es infraestructura. Requiere las mismas disciplinas de ingeniería que cualquier otro sistema crítico para la confiabilidad: ingesta idempotente de eventos (para que un webhook entregado dos veces no cuente una liquidación por duplicado), máquinas de estado deterministas (para que una transacción en “liquidación pendiente” pueda distinguirse sin ambigüedad de una en “liquidada con contracargo pendiente”) y almacenamiento durable que preserve el historial completo de eventos en lugar de un estado actual colapsado.

Esta no es una postura barata de adoptar. Construir una capa de eventos canónica es más ingeniería inicial que licenciar una herramienta de reporting que lee los archivos de liquidación de los PSP, y tarda más en mostrar resultados: la herramienta de reporting se demuestra en una semana, el modelo de eventos lleva un trimestre. La razón por la que la matemática se invirtió es que el costo de la herramienta de reporting se acumula. Cada nuevo método de pago, cada nuevo PSP, cada nuevo cronograma de liquidación agrega otra ruta de conciliación manual que alguien mantiene a mano, y esa carga de mantenimiento crece de forma combinatoria, mientras que la inversión en el modelo de eventos se paga una vez y se amortiza en cada riel agregado después.

Nada de esto puede acoplarse encima de la exportación de archivos de liquidación de un PSP. Tiene que diseñarse dentro de la plataforma de pagos desde el punto donde los eventos se observan por primera vez. Un pago que se liquida a través de un puente de stablecoin después de originarse en un riel instantáneo doméstico y de ser capturado por un adquirente de tarjetas (una ruta de liquidación que no es especulativa en 2026) produce eventos en tres sistemas distintos, en tres esquemas distintos, con tres latencias distintas. El modelo de conciliación tiene que tratar eso como una única transacción con eventos anotados a nivel de riel, no como tres registros de liquidación separados que un analista de finanzas ensambla manualmente en una fila.

El trabajo reciente de la industria sobre conciliación multicanal plantea lo mismo desde el ángulo omnicanal: el desafío de unificar los pagos de POS, e-commerce y app no se trata principalmente de conectarse a más PSP. Se trata de crear una única capa de eventos normalizada que se sitúe por encima de los comportamientos de liquidación específicos de cada canal y los haga legibles como una sola operación. La idea es la misma ya sea que lo abordes desde la infraestructura de orquestación o desde las herramientas financieras omnicanal. La capa de abstracción tiene que existir a nivel de evento, no a nivel de reporting.

‍

¿Qué significa esto para tesorería y capital de trabajo?

Las consecuencias de hacer esto bien o mal no se limitan a la precisión del cierre de fin de mes. Una conciliación que corre sobre infraestructura de eventos confiable cambia lo que las operaciones financieras pueden ver de verdad.

La visibilidad del estado de liquidación en tiempo real cambia las decisiones de tesorería. Si un comercio sabe que 2,4 millones de dólares en liquidaciones de e-commerce están confirmadas y en tránsito mientras 600.000 dólares en liquidaciones de POS siguen en una ventana D+1 en lote, esas son posiciones de liquidez distintas. La implicancia de capital de trabajo de saber, frente a aproximar, es significativa a escala. La cifra del Payments Outlook 2026 de J.P. Morgan, según la cual solo el 39% de las organizaciones de tesorería describe sus sistemas como mayormente o totalmente automatizados frente a un 87% que afirma tener algo de automatización, es una medida de la brecha entre tener datos y tener datos lo suficientemente confiables para actuar sin un paso de confirmación manual.

La gestión de la exposición cambiaria tiene la misma dependencia. Cuando una liquidación llega de un PSP europeo en euros, convertida a una tasa que el PSP eligió en un momento que el comercio no controló, la brecha de exposición no es visible hasta que llega el archivo de liquidación, a menudo días después de la transacción. Un comercio con una capa de conciliación basada en eventos puede observar el evento de conversión cambiaria casi en tiempo real, atribuir la exposición a nivel de transacción y tomar decisiones de cobertura contra datos de liquidación reales en lugar de estimaciones. Eso es una capacidad de tesorería, no una capacidad de reporting, y solo existe si la infraestructura por debajo captura los eventos cambiarios con la granularidad correcta.

Los plazos de respuesta a disputas también se ven afectados directamente. La ventana para responder a un contracargo se mide en días o semanas según la red de tarjetas y el código de motivo. Un sistema de conciliación que ingiere los eventos de disputa en tiempo real y los expone con el contexto de la transacción original lleva las disputas a resolución más rápido que uno que las expone en una exportación semanal en lote. A volumen suficiente, el impacto en los ingresos es material.

‍

La transición organizativa que ya está ocurriendo

La señal de productización que dan los proveedores de orquestación que hoy empaquetan la conciliación como infraestructura en lugar de reporting refleja algo que los equipos de pagos enterprise reportan desde el lado operativo: los flujos de conciliación cruzaron un umbral de complejidad que las operaciones financieras no pueden ser dueñas por sí solas. La inversión en herramientas está siguiendo a donde la carga operativa ya migró.

Lo que eso significa en la práctica es que los equipos de ingeniería de plataforma cada vez más son dueños de las garantías de integridad del libro mayor (el modelo de eventos, la capa de normalización, la infraestructura de idempotencia), mientras que los equipos de finanzas son dueños de las políticas que se sitúan por encima: lógica de exenciones, estrategia cambiaria, criterios de escalamiento de disputas. La frontera entre ambos es el flujo de eventos canónico. Ingeniería garantiza su confiabilidad. Finanzas lo consume.

Los equipos que postergaron esta decisión arquitectónica no la están evitando. La están tomando por defecto, en la dirección del manejo manual de excepciones, backlogs de conciliación crecientes y un proceso de cierre de fin de mes que consume más horas a medida que crece el volumen, en lugar de menos. La elección de infraestructura por debajo de la conciliación es la misma clase de decisión que la elección de arquitectura de smart routing descrita en las discusiones sobre la capa de orquestación que dominaron las conversaciones de pagos enterprise este año. Ambas tratan de si la capa de abstracción se construye de forma deliberada o se hereda en pedazos.

La conciliación no se está volviendo una función de ingeniería porque los ingenieros quieran ser dueños de más del stack. Se está volviendo una porque el stack ahora genera una clase de problema de consistencia de datos que solo la ingeniería puede resolver. El rol del equipo de finanzas no disminuye. Pero su efectividad ahora depende de si la infraestructura de pagos aguas arriba fue diseñada para darles datos confiables, o quedó librada a darles lo que cada PSP decidió enviar.

Esa decisión de diseño ya se está tomando, en cada plataforma de pagos en producción. La pregunta es si se está tomando de forma consciente.

‍