7 políticas que definir antes de crear un sistema de liquidación con IA

La liquidación no es una simple función de resta. Es un sistema de libros contables que determina los derechos y obligaciones de cada pedido, separa los fondos que la plataforma debe custodiar o pagar y realiza el seguimiento de reembolsos, disputas, impuestos y transferencias fallidas.

La IA generativa puede ayudar a escribir código y pruebas, pero no puede asumir la responsabilidad de las políticas de liquidación. Si las políticas no están definidas, la IA puede crear valores predeterminados plausibles u omitir excepciones, lo que puede provocar pagos excesivos, pagos duplicados, errores fiscales o incidentes de liquidez.

Principios confirmados por la crisis de TMON y WeMakePrice de 2024

La falta de liquidación a gran escala de los pagos a vendedores de TMON y WeMakePrice en 2024 mostró hasta qué punto los retrasos en las liquidaciones pueden causar daños en cadena a vendedores y consumidores. Sin embargo, no debe concluirse que la causa de la crisis fue únicamente un ciclo de liquidación prolongado. Deben analizarse conjuntamente diversos factores, como la gestión de fondos, la liquidez, la estructura de gobierno y los controles internos.

Las principales lecciones que deben extraer los operadores son claras.

• No considerar los pagos a vendedores aún no desembolsados como efectivo de la empresa que puede utilizarse libremente.
• Cuanto más largo sea el ciclo de liquidación, mayor será el saldo pendiente expuesto a una interrupción o falta de liquidez.
• Conciliar diariamente el saldo de los pagos a vendedores con los fondos realmente custodiados.
• Comunicar de manera transparente a los vendedores las condiciones de liquidación y los motivos de los retrasos.
• Verificar por separado la normativa aplicable, la estructura contractual y el alcance de los servicios del PG.

La titularidad legal y el método de protección de los pagos a vendedores pueden variar según la estructura de la transacción. Por tanto, aunque en la actividad cotidiana debe mantenerse la cautela de considerarlos «dinero ajeno», el tratamiento contable y jurídico efectivo debe determinarse conforme a los contratos y la legislación vigente.

7 políticas de liquidación que deben definirse antes de la implementación

1. Fecha de referencia y ciclo de pago de la liquidación

Primero debe definirse cuándo un pedido pasa a un estado apto para su liquidación. Si solo se toma como referencia la fecha del pedido o del pago, pueden incluirse entre los importes pagaderos cantidades que aún estén sujetas a cancelación antes del envío o a devolución.

En una transacción habitual de productos puede diseñarse el siguiente flujo.

1. Autorización del pago
2. Entrega completada
3. Confirmación de compra o confirmación automática tras el transcurso del plazo acordado
4. Comprobación de devoluciones, disputas y transacciones anómalas
5. Determinación de los elementos sujetos a liquidación
6. Inclusión en el lote de pagos
7. Finalización de la transferencia y la conciliación

Deben decidirse necesariamente los siguientes elementos.

• Evento de referencia para la liquidación según el tipo de transacción, como productos, contenido digital o servicios
• Plazo hasta la confirmación automática de la compra y momento desde el que comienza a computarse
• Ciclo de pago diario, semanal o mensual
• Tratamiento de fines de semana y días festivos
• Hora de cierre de la liquidación y lote al que se asignan las transacciones posteriores al cierre
• Importe mínimo de pago y posibilidad de trasladar saldos pequeños
• Si se permitirán ciclos distintos según la categoría del vendedor
• Procedimiento para verificar que no se superan los plazos de pago legales o contractuales

Debe distinguirse entre la fecha en que una liquidación pasa a ser elegible y la fecha efectiva de pago. Por ejemplo, eligible_at es el momento en que se cumplen las condiciones de pago, scheduled_payout_at es el momento en que se incluye en el lote de pagos y paid_at es el momento en que se confirma que la transferencia se ha realizado correctamente.

2. Cálculo de comisiones y extracto de liquidación

Si al vendedor solo se le muestra el importe final pagado, resulta difícil verificar los cálculos y aumentan las consultas y disputas. Son necesarios tanto un desglose por pedido como los totales por período.

La política de comisiones también debe especificar la base de cálculo. Debe determinarse si se utiliza como base el precio de venta anterior al descuento o el importe pagado después del descuento, si se incluyen los gastos de envío y el IVA, y cómo se revierte la comisión en caso de reembolso parcial.

Es más seguro no calcular los importes con tipos de datos de coma flotante. En monedas como el won, cuya unidad monetaria mínima es un número entero, deben almacenarse como enteros; si se necesitan divisas extranjeras o cálculos con decimales, deben utilizarse tipos de datos de punto fijo y reglas de redondeo específicas para cada moneda.

3. Reembolsos y liquidaciones negativas

Un pedido ya pagado al vendedor puede ser reembolsado posteriormente. En ese caso, el importe del reembolso y la comisión que debe devolverse deben registrarse en el libro de ajustes y deducirse del siguiente pago.

Por ejemplo, si el importe previsto para esta liquidación es de 300.000 wones y la deducción relacionada con el reembolso de un pedido anterior es de 400.000 wones, puede procesarse del siguiente modo.

• Importe de este pago: 0 wones
• Saldo no recuperado: menos 100.000 wones
• Importe trasladado a la siguiente liquidación: deducción de 100.000 wones

La política debe incluir los siguientes elementos.

• Método de distribución del precio del producto, los gastos de envío y las comisiones en caso de reembolso parcial
• Período de traslado y orden de compensación de los saldos negativos
• Método de recuperación frente a vendedores sin ventas durante un período prolongado
• Fundamento contractual para establecer un depósito de garantía o una reserva para pagos
• Procedimiento para comprobar las obligaciones pendientes antes de la baja del vendedor
• Método de realizar asientos inversos cuando se cancela un reembolso o cambia el resultado de una disputa

Los registros de transacciones existentes no deben sobrescribirse; deben vincularse la transacción original y la transacción de ajuste. Solo así puede reconstruirse qué reembolso modificó cada liquidación.

4. Retención y liberación de pagos

En lugar de suspender incondicionalmente los pagos de toda la cuenta de un vendedor, debe ser posible retenerlos por pedido, importe o motivo. Los motivos representativos de retención son los siguientes.

• Disputa del consumidor o devolución en curso
• Sospecha de transacciones ficticias, apropiación de la cuenta o pagos anómalos
• Fallo en la verificación de la identidad, la empresa o la cuenta bancaria del vendedor
• Solicitud legítima de un tribunal, organismo de investigación o autoridad competente
• Falta de presentación de documentos de liquidación exigidos contractualmente

En cada registro de retención deben almacenarse el importe afectado, el código del motivo, la documentación justificativa, la hora de inicio, la fecha límite de revisión, el responsable y las condiciones de liberación. En la pantalla del vendedor deben mostrarse, dentro de los límites de lo que pueda divulgarse, el importe retenido, el motivo, las acciones necesarias y el canal de consulta.

Para impedir que los operadores repitan retenciones arbitrariamente, conviene separar los permisos de creación y liberación, y aplicar una doble aprobación a la liberación de retenciones por importes elevados.

5. Gestión separada de los pagos a vendedores y estructura de PG y depósito en garantía

Si los pagos pendientes a vendedores y los gastos operativos de la empresa se gestionan como si fueran el mismo efectivo disponible, una falta de liquidez puede convertirse inmediatamente en una falta de liquidación. Como mínimo, en los libros internos y en la gestión de las cuentas deben distinguirse claramente los fondos relacionados con los pagos a vendedores y los fondos operativos, y sus saldos deben conciliarse diariamente.

Sin embargo, la mera creación de una cuenta separada no establece automáticamente una separación jurídica en caso de insolvencia ni una protección total de los fondos. Deben revisarse la eficacia y las obligaciones de métodos de protección como los fideicomisos, los depósitos y las garantías de pago conforme a la legislación aplicable y la estructura contractual.

Dependiendo del papel que desempeñe la plataforma en el proceso de pago y desembolso, pueden surgir obligaciones de registro conforme a la Ley de Transacciones Financieras Electrónicas, como las aplicables a las empresas de pasarela de pagos electrónicos. No todas las plataformas están sujetas de igual manera al registro como PG, ni el mero hecho de calcular datos de liquidación implica siempre dicha obligación. La determinación debe basarse en la forma efectiva de recepción, custodia y transmisión de los fondos, así como en las relaciones contractuales.

Las plataformas en fase inicial pueden considerar los servicios de pago, depósito en garantía o liquidación dividida por vendedor ofrecidos por un PG registrado. No obstante, utilizar un PG no elimina las siguientes responsabilidades.

• Decidir qué pedidos se remiten para su pago y cuándo
• Calcular las comisiones y los importes de ajuste
• Gestionar los reembolsos y el traslado de saldos negativos
• Verificar la información y las cuentas bancarias de los vendedores
• Conciliar los resultados del PG con los libros internos
• Responder a interrupciones y pagos fallidos

Las obligaciones y excepciones del depósito en garantía también varían según el tipo de transacción y el método de pago, por lo que deben consultarse la legislación de comercio electrónico y sus normas subordinadas.

6. Retenciones fiscales, IVA y justificantes

La regla de que «a los vendedores particulares siempre se les deduce un 3,3%» no es exacta. Por lo general, el 3,3% es una expresión que combina el 3% del impuesto sobre la renta correspondiente a ingresos empresariales y el 0,3% del impuesto local sobre la renta de las personas físicas. La aplicación efectiva de la retención no depende únicamente de si el vendedor está registrado como empresa, sino también de la naturaleza de los ingresos, la relación contractual, el concepto del pago y las disposiciones de excepción.

Durante las etapas de registro y contratación debe recopilarse la siguiente información.

• Tipo de vendedor: particular, empresario individual, sociedad, etc.
• Si se trata de un residente o una persona jurídica nacional o extranjera
• Situación fiscal, como sujeto a impuestos, exento o contribuyente simplificado
• Información necesaria para las declaraciones legales, como el número de registro empresarial y el número de registro de residente
• Naturaleza de los ingresos y motivo del pago
• Justificantes necesarios, como facturas fiscales, facturas o certificados de retención

Tampoco debe generalizarse que a los vendedores empresariales «siempre se les paga el 100% sin deducir ningún impuesto». Si el contrato contempla la deducción de la comisión de la plataforma, deben diferenciarse el importe bruto de la transacción, la comisión, el IVA y el importe efectivamente transferido. La entidad responsable y el momento de emisión de la factura fiscal correspondiente a la comisión por el servicio de intermediación prestado por la plataforma también deben determinarse de acuerdo con el contrato y la relación de suministro conforme a la legislación fiscal.

Por lo general, a las retenciones fiscales se les aplica una estructura de declaración y pago hasta el día 10 del mes siguiente al mes en que se realizó el pago, pero deben comprobarse las normas vigentes en el momento efectivo de la declaración, ya que puede haber excepciones o cambios en los plazos. En lugar de fijar las reglas fiscales directamente en el código, es más seguro gestionarlas como políticas versionadas con fechas de inicio y finalización de su aplicación.

7. Fallos de pago, administración de liquidaciones y registros de auditoría

Incluso un pago generado correctamente puede fallar por errores en la cuenta, discrepancias en el nombre del titular, restricciones de transacción, mantenimiento bancario o interrupciones del PG. En lugar de marcar un fallo simplemente como «impagado», deben detallarse sus estados y reglas de reprocesamiento.

Estos son algunos ejemplos de estados recomendados.

• scheduled: pago programado
• submitted: solicitud enviada al banco o al PG
• processing: procesamiento por una entidad externa
• paid: éxito confirmado
• failed_retryable: fallo que permite un nuevo intento
• failed_final: fallo definitivo que requiere la corrección de información u otras acciones
• reversed: cancelación o devolución después del éxito

Para los reintentos debe utilizarse una clave de idempotencia que identifique el mismo pago. Dado que confundir un retraso en la respuesta con un fallo y volver a transferir puede producir un pago duplicado, primero debe consultarse el número de transacción externo para confirmar el resultado de la solicitud existente.

En el registro de auditoría debe conservarse lo siguiente.

• Actor y cuenta de operador utilizada
• Información de seguridad, como hora de ejecución y ubicación de acceso
• Valores anteriores y posteriores al cambio
• Motivos de la retención, liberación y ajuste manual
• Aprobador y ejecutor
• Pedidos relacionados, lote de liquidación y número de transacción externo
• Código del fallo e historial de reintentos

Los registros de auditoría deben protegerse para que los operadores habituales no puedan modificarlos ni eliminarlos, y a los datos personales y financieros deben aplicarse políticas de minimización de la recopilación, control de acceso, cifrado y períodos de conservación.

Composición mínima del modelo de datos de liquidación

En lugar de pedir a la IA que comience por las pantallas, conviene definir primero los siguientes libros.

Cada libro debe incluir la moneda, la versión de la política, la hora de creación y la clave de vinculación con la transacción original. Un simple cambio en el estado de un pedido no debe modificar silenciosamente los importes de liquidaciones anteriores.

Reglas de control que deben mantenerse obligatoriamente

El sistema de liquidación debe comprobar automáticamente las siguientes condiciones invariantes.

• Cada elemento de liquidación está vinculado exactamente a un vendedor y a una transacción original.
• No se realiza dos veces una transferencia con la misma clave de pago.
• La suma del importe pagado, el importe pendiente, el importe retenido y los ajustes coincide con el libro.
• Cada ajuste manual cuenta con un motivo y un aprobador.
• Las liquidaciones ya cerradas no se modifican, sino que se corrigen mediante un asiento inverso y un nuevo ajuste.
• Cualquier diferencia entre los saldos internos relacionados con los pagos a vendedores y los saldos del PG y del banco se investiga diariamente.
• En los cálculos de impuestos y comisiones se registra la versión de la política aplicada.

Ejemplo de especificación de políticas para proporcionar a la IA

Estructurar los requisitos de la siguiente manera puede reducir las omisiones.

Diseña por separado el estado del pedido y el estado de la liquidación. Implementa las condiciones de confirmación de compra para cada tipo de transacción, un lote de pagos cada miércoles, el tratamiento de días festivos, la base de las comisiones, la distribución de reembolsos parciales, el traslado de saldos negativos, la retención de pagos por transacción, versiones de la política de retenciones fiscales, claves de idempotencia para pagos y registros de auditoría inmutables. Procesa los importes como enteros o con punto fijo. Todos los ajustes manuales requieren doble aprobación y un motivo. Antes de la implementación, presenta como lista de preguntas las políticas aún no definidas, como el importe mínimo de pago, el plazo de confirmación automática de la compra, la recuperación de saldos negativos a largo plazo, el plazo de retención y el número de reintentos.

No debe pedirse a la IA únicamente código, sino también los siguientes entregables.

• Diagrama de transición de estados y lista de excepciones
• Esquema de la base de datos y restricciones
• Sistema de permisos y aprobaciones
• Pruebas de funcionamiento normal, valores límite, fallos y solicitudes duplicadas
• Formato del informe diario de conciliación
• Procedimientos de recuperación ante fallos y procesamiento manual
• Lista de comprobación para proteger datos personales y financieros

Lista de comprobación previa al lanzamiento

• La fecha de referencia de la liquidación está documentada para cada tipo de transacción.
• El vendedor puede verificar el extracto de liquidación por pedido.
• Se han superado las pruebas de reembolsos parciales y traslado de saldos negativos.
• Están definidos los motivos, los plazos y los permisos de liberación de las retenciones.
• Están diferenciados los criterios de gestión de los fondos relacionados con los pagos a vendedores y de los fondos operativos.
• Se ha consultado con especialistas si son aplicables las normas sobre PG, depósito en garantía y actividades financieras electrónicas.
• Se ha revisado el tratamiento fiscal según el tipo de vendedor y de ingresos.
• Se han completado las pruebas de prevención de pagos duplicados y reintentos tras fallos.
• Es posible realizar una conciliación diaria entre el banco, el PG y los libros internos.
• Los cambios manuales de los operadores quedan registrados en el registro de auditoría.
• Existen procedimientos para notificar a los vendedores y responder a consultas en caso de fallos en la liquidación.

Conclusión

El punto de partida de un sistema de liquidación seguro no es un prompt para IA, sino políticas explícitas y libros separados. La IA debe utilizarse como herramienta para convertir reglas ya definidas en código, pruebas y documentación, mientras que la estructura de custodia de fondos y las decisiones sobre finanzas electrónicas y fiscalidad deben verificarse junto con el PG y especialistas contables, fiscales y jurídicos.