Liquidación entre partners en programas de coalición: ledger, neteo y conciliación
En una coalición, una empresa puede financiar la acumulación, otra aceptar la redención y una tercera operar la plataforma. El saldo del miembro no basta para determinar cuánto debe pagar o cobrar cada socio al cierre. La liquidación necesita eventos económicos trazables, un ledger separado, reglas de valoración, neteo, monedas, reversos, disputas y una conciliación compartida. KA-049 compara coalición y programa propio, KA-050 estudia quién financia los beneficios y KA-064 gobierna saldos. Esta guía se concentra en el settlement entre organizaciones para que retail, servicios y movilidad puedan diseñar el periodo de cierre sin perder el detalle necesario para explicar cada obligación.
Una coalición mueve valor entre organizaciones
En un programa propio, quien otorga y quien redime suele pertenecer a la misma entidad económica. En una coalición, un partner puede generar puntos y otro entregar la recompensa. Al final alguien financia, alguien cobra una tarifa, alguien asume devolución y alguien responde ante el miembro. Si esas responsabilidades no están modeladas por evento, el crecimiento de la red multiplica disputas y cierres manuales.
La liquidación transforma actividad de miembros en posiciones entre partners. No es el saldo visible del usuario, aunque se relaciona con él. Un ledger inter-partner registra obligaciones por acumulación, redención, expiración, ajuste y fee según contratos. El neteo resume posiciones para pago, pero nunca debe borrar el detalle que las explica.
Definir roles y evento económico
Cada evento necesita originador, financiador, operador, proveedor de recompensa y beneficiario. Una misma organización puede ocupar varios roles. También requiere moneda, valor, fecha, regla y referencia a la transacción fuente. El evento técnico de escaneo o clic no necesariamente crea una obligación; el contrato define qué hito la genera. Esa diferencia debe estar explícita para evitar facturar actividad preliminar.
La organización debe acordar quién asume puntos otorgados y cuándo. Puede ser en la compra, al vencer el periodo de devolución o al redimir. Cada opción cambia riesgo y caja. No hay una única respuesta correcta, pero el ledger debe representar el modelo elegido y permitir ajustes sin reescribir el pasado.
Separar ledger de miembro y ledger de settlement
El ledger del miembro responde cuánto valor tiene y por qué. El de settlement responde cuánto deben pagarse los partners. Un canje puede reducir puntos del miembro y crear una obligación de la coalición hacia el proveedor. Mezclarlos hace difícil conciliar porque usan unidades y momentos distintos. La relación se conserva mediante identificadores de evento y transacción.
La separación permite tratar fees, impuestos, comisiones o reservas sin alterar el saldo visible. También facilita corregir un acuerdo entre partners manteniendo intacta la historia del miembro. Los dos ledgers deben poder reconciliarse, pero no requieren la misma estructura. Finanzas y producto definen qué campos comparten.
Neteo sin perder granularidad
Durante el periodo, dos partners pueden deberse valor en direcciones opuestas. El neteo calcula una posición por moneda y entidad para reducir transferencias. Antes de netear se validan eventos, tipos de cambio, corte y disputas. Mezclar monedas o periodos sin regla puede ocultar exposición. El resultado neto conserva un detalle firmado o aprobado de componentes.
La frecuencia depende de volumen, riesgo y caja: diaria, semanal o mensual. Periodos largos reducen operación pero aumentan exposición; periodos cortos exigen automatización. Pueden existir umbrales, reservas y límites de crédito. El programa necesita alertas cuando una posición crece más allá de lo pactado.
Devoluciones, anulaciones y disputas
Una devolución después del cierre puede requerir un ajuste en el periodo siguiente. Si se reabre el periodo sin control, estados ya conciliados cambian. Es preferible registrar eventos compensatorios que referencien el original. Las disputas separan monto cuestionado de monto aceptado para no detener todo el pago. Cada razón tiene código, evidencia, propietario y vencimiento.
El miembro no debería quedar atrapado en una disputa inter-partner cuando ya recibió una promesa válida, salvo reglas comunicadas. El contrato determina responsabilidad. La plataforma registra estado operativo; las partes resuelven la obligación. Este límite protege experiencia y evita que soporte improvise decisiones financieras.
Monedas y tipos de cambio
Una coalición multipaís necesita moneda de transacción, unidad de puntos, moneda de liquidación, fuente de tipo de cambio y fecha aplicable. KA-109 aborda puntos y moneda desde el programa; settlement agrega una obligación entre entidades. Usar el tipo vigente al cierre puede diferir del tipo del evento. El contrato define la regla y el ledger guarda ambas referencias cuando sea necesario.
La precisión y redondeo también generan diferencias. Redondear cada evento no produce siempre el mismo total que redondear al final. La política debe ser uniforme y probada con volúmenes grandes. Las pequeñas diferencias se manejan con tolerancias y cuentas identificadas, no desaparecen en ajustes genéricos.
Conciliación de tres lados
Una conciliación robusta compara evento del programa, transacción fuente del partner y registro financiero. Para redención física puede añadirse evidencia de fulfillment. Las diferencias se clasifican como faltante, duplicado, valor, moneda, estado o corte. Cada clase tiene ruta de resolución. Forzar totales sin identificar causas hace que el mismo error reaparezca.
El cierre produce conteos, montos, excepciones, posición neta y aprobación. Después se congela el periodo y cualquier cambio entra como ajuste posterior. Los responsables deben poder rastrear desde una línea de pago hasta eventos individuales y volver al resumen. Esa bidireccionalidad es la base de confianza entre socios.
Gobierno, acceso y continuidad
Los contratos definen calendarios, monedas, fees, evidencia, disputas, reservas y salida. La tecnología implementa esas reglas con versiones y segregación. Quien configura tasas no debería aprobar el pago sin control adicional. Los reportes compartidos limitan datos personales y muestran solo lo necesario para liquidar. La retención se alinea con auditoría y privacidad.
También se planifica la salida de un partner: corte de nuevas acumulaciones, vigencia de puntos, redenciones pendientes, saldo neto y acceso a evidencia. Un programa de coalición no está preparado si solo sabe incorporar socios. Continuidad y portabilidad deben probarse antes de depender de la red.
Cómo evaluar la capacidad operativa
La prueba debe simular acumulación en un partner, redención en otro, devolución, disputa, fee, moneda diferente y cierre. El sistema demuestra ledgers separados, vínculos, neteo y conciliación. También exporta un estado entendible por cada parte y evita que una corrección duplique valor. Una presentación de catálogo no prueba settlement.
Lealto publica capacidades B2B, de incentivos e integración. El mecanismo exacto de liquidación depende del proyecto, acuerdos y sistemas financieros; no debe atribuirse sin verificación. La oportunidad comercial está en diseñar una red que pueda crecer sin convertir cada cierre en una negociación manual.
Preguntas frecuentes
¿El saldo de puntos sirve como cuenta por pagar entre partners? No por sí solo; la obligación depende de roles, reglas y eventos económicos.
¿Netear elimina la necesidad de detalle? No. Reduce transferencias, pero cada posición debe explicarse con eventos.
¿Qué ocurre con ajustes tardíos? Se registran como eventos compensatorios en un periodo controlado, referenciando el original.
Diseñar un estado de cuenta entendible por cada partner
El partner necesita un estado que muestre saldo inicial, cargos, créditos, ajustes, pagos y saldo final por moneda y periodo. Cada línea agregada debe permitir drill-down a eventos y referencias sin exponer datos de otros socios. Las definiciones de corte y estado se comparten: pendiente, elegible, aprobado, disputado, liquidado o revertido. Un PDF final puede apoyar, pero el dato estructurado permite conciliación automatizada.
La aprobación debe registrar identidad, fecha y versión. Si un partner no responde, el contrato define escalamiento; el sistema no asume aprobación silenciosa salvo regla expresa. Los pagos se vinculan con el estado y las diferencias quedan abiertas hasta resolución. Al comparar estados consecutivos, ajustes tardíos aparecen claramente. Este diseño reduce conversaciones manuales y crea confianza para incorporar más socios sin perder control financiero.
Escalar la red sin multiplicar excepciones
Cada nuevo partner debería incorporarse a un contrato de eventos, monedas, fees, cortes y disputas ya definido. Las excepciones comerciales pueden existir, pero se representan como versiones o parámetros, no como procesos manuales invisibles. Antes de habilitarlo se ejecuta un ciclo completo de prueba y cierre. También se valida que su volumen no supere límites de crédito, procesamiento o conciliación.
La red necesita indicadores de salud: partidas abiertas, antigüedad de disputas, diferencias por fuente, exposición neta y puntualidad de pago. Estos indicadores no sustituyen métricas de miembros; protegen la operación que las sostiene. Cuando crece la coalición, un modelo estandarizado permite negociar diferencias reales sin reconstruir la contabilidad para cada socio. Esa capacidad es un requisito de escala, no una mejora posterior.
Cerrar el periodo sin perder la trazabilidad
Antes de incorporar partners, la coalición debe acordar qué eventos generan obligaciones, cómo se valoran, cuándo se netean y qué evidencia acompaña cada diferencia. El piloto debe simular acumulaciones, redenciones cruzadas, devoluciones, tipos de cambio, saldos negativos y una disputa que atraviese el cierre. Finanzas, operaciones y tecnología deben poder reconstruir el neto desde transacciones inmutables, sin editar el historial para forzar coincidencias. Lealto y los componentes de pago o ERP se evalúan sobre responsabilidades y capacidades verificadas para el alcance acordado. Un settlement confiable permite pagar menos movimientos, pero nunca a costa de perder la explicación de quién debe qué y por qué.
Fuentes
- Stripe Docs — Separate charges and transfers
- GS1 — Traceability Standard
- Lealto — programas B2B e integración
- Atlas — KA-049, KA-050 y KA-064 como frontera canónica
Contáctenos
Construyamos su estrategia de lealtad