Cuando una empresa extranjera empieza a vender en Latinoamérica, al principio el foco está en convertir. Después aparece el segundo problema: cerrar la operación. Y ahí, la conciliación suele ser el cuello de botella invisible.
Para entender el contexto de proveedores disponibles, podés revisar también esta guía de pasarelas de pago en Argentina.
Conciliar no es “revisar que entró el dinero”. Es poder responder, por cada transacción: qué se cobró, con qué método, en qué moneda, cuánto fue fee, cuál fue el ingreso neto, cuándo se liquidó, y cómo se relaciona con una orden o factura. Si eso no existe, el crecimiento se paga con soporte y planillas.
Esta guía está pensada para equipos de finanzas, operaciones y producto. Es práctica y orientada a empresas que cobran en varios países o desde el exterior. Si todavía estás definiendo el stack regional, conviene leer primero el hub de pasarelas de pago en Latinoamérica y el marco de pagos internacionales para neto, FX y settlement.
En mercados maduros, muchas empresas asumen que el estado “pagado” es suficiente. En LATAM, eso falla por dos motivos:
Por eso, conciliación es un sistema: datos + estados + procesos.
Si hoy estás conciliando por “capturas y planillas”, el primer paso es un mínimo de datos por transacción. Recomendación:
Con esto, ya podés responder “qué pasó” y evitar que soporte y finanzas investiguen a mano.
En tarjeta, el punto crítico suele ser la aprobación (rechazos) y las disputas. Conciliar tarjeta requiere visibilidad de autorizaciones, capturas, devoluciones y contracargos. Además, el settlement puede variar por país, tipo de tarjeta o esquema.
En transferencias locales, la conciliación depende de referencias. En México, SPEI; en Colombia, PSE. En ambos casos, el equipo necesita saber qué referencia se le mostró al cliente y cómo se confirma el pago. Si querés ver el flujo operativo, estas guías ayudan: SPEI en México y PSE en Colombia.
Cuotas suele mejorar conversión, pero aumenta complejidad: el plan (cantidad de cuotas) tiene que quedar registrado y el neto cambia. En México, MSI es una variación clave. Si tu empresa ofrece cuotas, conviene tener dos lecturas: la comercial (cuotas sin interés) y la operativa (cómo funcionan MSI).
Para conciliar sin fricción, tu sistema debería tener estados claros. Un esquema simple:
La clave es separar confirmación de liquidación. Eso reduce reclamos y mejora reporting.
En empresas en crecimiento, un síntoma de mala conciliación es que finanzas “no puede cerrar el mes” sin pedir reportes a ingeniería. Buen diseño significa que finanzas pueda:
Esto requiere que el proveedor/pasarela exponga datos consistentes y que tu backoffice registre referencias internas desde el inicio.
Una buena conciliación empieza por un modelo de datos estable. No tiene que ser complejo, pero sí consistente. Un esquema práctico (independiente del proveedor) es separar:
Separar intento, transacción y liquidación evita errores comunes: por ejemplo, contar como “cobrado” algo que todavía está pendiente, o no poder explicar diferencias entre bruto y neto.
En equipos que están armando la operación, hay dos caminos típicos:
La recomendación es tener ambos recorridos. Si solo tenés el de liquidaciones, soporte sufre. Si solo tenés el de órdenes, finanzas no puede explicar caja ni neto.
En cross-border, un problema frecuente es mezclar monedas y tiempos. Para evitarlo:
Esto se complementa con el enfoque de pagos internacionales: lo que importa no es el tipo de cambio “promedio”, sino el neto y el timing real.
Un error típico es exportar 10 reportes distintos y “unir” a mano. En su lugar, definí dos reportes canónicos:
Con esos dos reportes, finanzas puede cerrar y soporte puede investigar sin dependencia constante de ingeniería.
Cuando un cliente pregunta “pagué y no se acreditó”, la respuesta correcta no es revisar el banco del cliente. Es revisar el estado del pago y su trazabilidad. Para reducir tickets:
En métodos como PSE o SPEI, esto es especialmente importante porque el usuario sale al banco y vuelve al comercio con incertidumbre. En Brasil, lo mismo aplica cuando incorporás pagos con PIX.
Una forma útil de evitar errores es tener un mapa interno por método. Por ejemplo:
Este mapa, aunque sea simple, alinea a soporte, finanzas y producto. Y evita que cada incidente se trate como “un caso especial”.
En LATAM, los métodos locales mejoran conversión, pero también exigen operación. La conciliación bien diseñada te permite escalar sin que cada mes sea una investigación. Si tu objetivo es crecer multipaís, el stack correcto combina cobro local con conciliación centralizada.
Un dataset transaccional consistente: order_id, payment_id, método, país, monto/moneda, estado con timestamps, fees/neto y fecha de liquidación. Con eso, finanzas puede cerrar y soporte puede investigar sin depender de ingeniería.
Ambas. Conciliar contra transacciones sirve para operación diaria. Conciliar contra liquidaciones sirve para caja y contabilidad. Si solo tenés una vista, vas a tener ceguera en la otra.
Priorizá por impacto y fricción: (1) métodos con más volumen, (2) métodos con mayor tasa de reclamos, y (3) métodos donde el neto sea menos transparente (por ejemplo cuotas/MSI). Medí antes y después para confirmar que la mejora reduce trabajo manual.
Antes de sumar mercados, auditá que puedas responder estas preguntas en menos de 2 minutos por transacción: qué método usó el cliente, cuál fue el estado final, cuál fue el neto, cuándo se liquida, y dónde se ve el comprobante o identificador externo. Si no podés, primero arreglá datos y estados. Escalar países sin conciliación robusta solo multiplica el problema. Es el tipo de deuda operativa que después se paga con semanas de cierre contable.
Es el proceso de hacer coincidir cada cobro con el dinero efectivamente liquidado, sus fees, impuestos, ajustes y el settlement asociado, hasta cerrar el neto por transacción.
Se comparan órdenes, autorizaciones/capturas, reportes del proveedor y movimientos bancarios. Luego se marcan coincidencias y se investigan diferencias (rechazos, devoluciones, contracargos, ajustes).
IDs de orden y transacción, timestamps, moneda e importe bruto, fees/impuestos, importe neto, estado, referencia de settlement/payout y referencias bancarias (si aplica).
Suele fallar por IDs inconsistentes, pagos parciales o agrupados, FX, reintentos, ajustes tardíos, tiempos de settlement distintos y falta de un modelo de datos que conecte evento a evento.
.avif)
