Comprobantes, movements y liquidaciones

Tres conceptos que suelen confundirse al integrar por primera vez, porque hablan de "dinero" pero representan cosas distintas. Esta página los explica juntos.

Definiciones

Comprobante — un registro contable de deuda (o de su modificación). Lo crea el customer cuando emite una factura, nota de crédito, devolución, ajuste o retención. El comprobante expresa "qué se espera cobrar" o "qué ya no se debe". No es plata, es un documento.

Movement — un registro de dinero que efectivamente entró o salió de una cuenta recaudadora. Se origina cuando un cliente transfiere al CVU, o cuando se ejecuta una operación interna (impuesto, comisión, rollback). Es plata real, no un documento.

Liquidación (settlement) — un corte contable periódico que mueve los fondos acumulados en una cuenta recaudadora hacia la cuenta corriente del customer. La hace Max Pay automáticamente. Tiene un resumen con totales, impuestos, comisiones y los comprobantes que cubre.

Cómo se relacionan

El customer decide cuándo y a qué comprobante imputar cada movement entrante: Max Pay no lo hace automáticamente.

Por qué no se vinculan automáticamente

Cuando un cliente B2B con varias facturas pendientes transfiere $45.000, el sistema no puede inferir cuál factura pagó. ¿Pagó la más vieja? ¿La más nueva? ¿Una parcial? ¿Saldó dos juntas? Esa decisión es contable y depende de la política de cada customer.

Por eso Max Pay separa:

• Movements son hechos: tal monto entró tal día.
• Comprobantes son intenciones del customer: "estos avisos están pendientes".
• La imputación la hace el integrador con PATCH /v1/receivables/{id}/status (ver Imputar cobros entrantes a comprobantes).

Tabla comparativa

Aspecto	Comprobante	Movement	Liquidación
¿Qué representa?	Deuda o ajuste de deuda	Dinero efectivo entrando/saliendo	Corte contable periódico
¿Quién lo crea?	El customer (ERP)	Origen externo (cliente) o interno (impuestos, rollback)	Generada automáticamente por Max Pay
¿Cuándo?	Cuando el ERP factura	Cuando llega plata o se aplica un débito	Periódicamente, por cuenta recaudadora
¿Granularidad?	Uno por factura/nota/ajuste	Uno por transferencia	Una por cuenta y ciclo
¿Webhook?	receivable.created, receivable.paid, etc.	movement.created	settlement.completed

Ciclo de vida combinado

Un caso típico (Patrón A):

1. Day 1: ERP crea factura → POST /v1/receivables → estado PENDING. Webhook receivable.created.
2. Day 5: cliente transfiere al CVU → Max Pay registra movement.created. El comprobante sigue en PENDING hasta que el integrador decida imputar.
3. Day 5 (mismo día): ERP recibe el webhook, identifica que el cobro corresponde a esa factura, hace PATCH /receivables/{id}/status PAID. Webhook receivable.paid.
4. Day 15 (cierre): ciclo de liquidación. El movement entra al settlement; el comprobante pasa a SETTLED. Webhook settlement.completed con el resumen, y receivable.settled.

Diferencias entre lo cobrado y lo facturado

Es habitual que la suma de comprobantes PAID/SETTLED no coincida exactamente con el dinero liquidado. Causas comunes:

• Retenciones impositivas descontadas por el cliente (registradas como RETENTION hijo de la factura).
• Comisiones de Max Pay sobre el cobro.
• Impuestos que el sistema aplica antes de liquidar.
• Cobros sin comprobante (plata que entró pero el ERP no tenía factura emitida).
• Cobros parciales o pagos que cubren varios comprobantes.

El reporte de cada liquidación detalla estas diferencias para que el integrador pueda conciliar.