Payouts de marketplaces sin caos de conciliación

Por qué importa

Un marketplace corre dos sistemas financieros a la vez: la vista del PSP sobre la plata que entra y sale, y la vista del marketplace sobre quién le debe a quién. Estas dos vistas no son naturalmente consistentes, y la brecha entre ellas es donde vive el caos de conciliación.

En los primeros meses del marketplace, la brecha es chica y un líder de finanzas la cierra con un CSV y un sábado. Para el mes 18, el marketplace procesa pagos por dos o tres PSPs entre Bre-B, PSE, tarjetas, Pix, SPEI y billeteras, parte ingresos entre miles de vendedores, maneja devoluciones y contracargos por vendedor, y concilia ciclos de liquidación que no alinean con ciclos de payout. El sábado del CSV ya no alcanza. Para el mes 36, finanzas es un equipo de seis personas cuya semana está estructurada alrededor de exports de PSP, y los vendedores llaman a soporte por demoras de payout que nadie sabe explicar.

La solución es arquitectónica, no de proceso. Un marketplace que tiene su propio libro mayor, un sistema de registro para cada centavo que se mueve, conectado a cuentas de balance de vendedor, convierte la conciliación de un incendio mensual en un proceso continuo y automático. Los equipos que hacen esto temprano crecen sin que finanzas escale linealmente. Los que no, eventualmente tienen que hacer esta migración bajo presión.

Qué sale mal

Los modos de falla estándar son predecibles:

• Tratar la verdad a nivel PSP como verdad a nivel marketplace. El PSP sabe que entraron USD 100. No sabe que USD 70 son del Vendedor A, USD 25 del Vendedor B y USD 5 de la plataforma. Codificar ese split en código en vez de en un libro mayor significa que cada devolución, contracargo o ajuste tiene que re-derivar el split desde cero.
• Lógica de split en el checkout, no en el libro mayor. Cuando el split vive solo en el flujo de pago, no podés contestar fácilmente “cuál es el balance del Vendedor A ahora mismo”. Solo lo respondes replayando cada transacción.
• Ciclos de liquidación ignorados. Los PSPs liquidan en T+1 a T+14 según el riel. Los marketplaces suelen prometer payouts en un ciclo fijo (semanal, quincenal). Cuando esos ciclos no alinean, el marketplace o financia capital o demora a los vendedores, y ninguno es sostenible.
• Devoluciones y contracargos manejados en la capa del PSP. Cuando entra una devolución o contracargo, el PSP descuenta el monto bruto. Si al vendedor ya se le pagó su parte, el marketplace come la brecha. Sin un libro mayor de balance de vendedor, no hay forma limpia de netear esto contra ganancias futuras.
• Multi-PSP sin libro mayor unificado. Sumar un segundo PSP duplica el trabajo de conciliación. Sumar un tercero lo triplica. El costo crece superlineal porque cada PSP tiene formatos de export, mecánica de devolución y timing de liquidación distintos.
• Payouts manuales a vendedores. Finanzas generando a mano CSVs de “a quién pagar” es el patrón estándar en marketplaces bajo USD 5M de GMV. No escala y es donde se esconden los errores.
• Sin fuente de verdad para impuestos y retenciones. Los marketplaces de LATAM cargan cada vez más responsabilidades de recaudación tributaria (IVA, retenciones, percepciones). Sin un libro mayor, computar esto correctamente por vendedor por período es casi imposible.

Modelo operativo

El modelo operativo para payouts de marketplace es un solo principio: el libro mayor es la fuente de verdad. El PSP es una fuente de eventos, no una fuente de verdad.

Un marketplace que opera así puede crecer de USD 1M a USD 100M de GMV sin escalar la cantidad de gente de finanzas linealmente. Uno que no, contrata a una persona de finanzas cada USD 5M de GMV y sigue quedando atrás.

Enfoque recomendado

Los principios que se sostienen en marketplaces de LATAM:

Construye el libro mayor antes de sumar el segundo PSP. El dolor de conciliación multi-PSP sin libro mayor alcanza solo para justificar la construcción. Hacer el libro primero significa que la integración del segundo PSP es mecánica, no caótica.

Usa partida doble desde el día uno. Los libros de partida única se sienten más simples pero hacen la conciliación más difícil y las auditorías dolorosas. Cada evento es un par de entradas: crédito en un lado, débito en otro.

Los balances de vendedor tienen que ser consultables en tiempo real. Los vendedores preguntando “cuál es mi balance” deberían recibir respuesta actual, no “te respondemos después del cierre mensual”. Esto también es lo que habilita dashboards para vendedores.

Concilia diariamente, no mensualmente. Una pipeline de conciliación diaria que saca excepciones a la luz inmediatamente es la diferencia entre cazar errores el día uno y cazarlos a fin de mes cuando el volumen es inmanejable.

Maneja devoluciones y contracargos en la capa del vendedor. Cuando entra una devolución, debita el balance del vendedor inmediatamente. Si el vendedor tiene balance positivo, la devolución se netea. Si no, el marketplace pone la plata y el balance del vendedor queda negativo hasta que las ganancias alcancen.

Planea capital de trabajo deliberadamente. La brecha entre liquidación del PSP y payout al vendedor es un costo real. Los marketplaces que pretenden que no, terminan demorando vendedores o corriendo en negativo en caja. El capital de trabajo debería ser una línea presupuestaria, dimensionada al GMV esperado.

Impuestos y retenciones como entradas del libro. Lo que sea que el régimen local exija, codifícalo en el libro como entradas separadas. Así la posición tributaria está siempre actualizada y es auditable.

Arquitectura de ejemplo

Una arquitectura de referencia para un stack de payouts y conciliación de marketplace:

Pago del comprador (PSP A / PSP B / Bre-B / Pix / SPEI)
    ↓
Webhook del PSP → entradas en libro mayor
    → crédito: balance del vendedor (neto de comisión)
    → crédito: balance de plataforma (comisión)
    → crédito: cuenta de impuesto / retención (si aplica)
    ↓
Cuentas de balance de vendedor (tiempo real, consultables)
    ↓
Programador de payouts (por ciclo de vendedor: semanal / quincenal)
    → lee balance del vendedor
    → debita balance del vendedor
    → debita compensación de plataforma
    → dispara payout vía riel local (Bre-B / Pix / SPEI / ACH)
    ↓
Eventos de devolución / contracargo
    → débito: balance del vendedor
    → débito: balance de plataforma (reverso de comisión)
    → débito: cuenta de impuesto (reverso)
    ↓
Conciliación diaria
    → archivo de liquidación del PSP vs libro
    → excepciones para revisión
    ↓
Reportes: GMV, take rate, balances de vendedor, posición de capital de trabajo

Las dos piezas que más importan: la cuenta de balance de vendedor (porque hace que toda otra operación sea respondible en tiempo real) y la pipeline de conciliación diaria (porque la conciliación mensual siempre queda atrás).

Métricas a observar

El ciclo de conciliación es la métrica de higiene operativa. Cualquier cosa más larga que 24 horas significa que las excepciones se acumulan más rápido de lo que el equipo las resuelve.

El balance no resuelto % es la métrica de confianza: la fracción de GMV que en este momento no se puede atribuir limpiamente entre plataforma, vendedor y cuentas de impuestos. Por encima del 0.5%, finanzas pierde confianza en los libros.

Las horas de finanzas por millón de GMV es la métrica que te dice si la arquitectura de libro mayor está pagando. En un marketplace sin libro mayor, este número crece con el GMV. En uno con libro mayor, se achica.

Qué leer después