7 políticas que definir antes de crear un sistema de liquidación con IA ======================================================================= La liquidación no es una función que se limita a restar comisiones al importe de las ventas, sino un sistema de operaciones financieras que controla la atribución de los ingresos de ventas, las condiciones de pago, los reembolsos, los impuestos y la gestión de fallos. Antes de encargar su implementación a la IA, las personas deben definir primero siete políticas, desde la fecha de referencia de la liquidación hasta los registros de auditoría. - Los ingresos de ventas no deben gestionarse como fondos operativos de libre disposición de la plataforma, sino como fondos restringidos vinculados a obligaciones de pago a los vendedores y otras partes. - Los estados de los pedidos y de las liquidaciones deben mantenerse separados, y la confirmación de compra, los reembolsos, las disputas y los fallos de pago deben registrarse individualmente en los libros contables. - No siempre se debe retener un 3,3 % a los vendedores particulares; debe determinarse según la naturaleza jurídica de los ingresos y la condición del vendedor. - Aunque se utilicen un PG o un servicio de depósito en garantía, la plataforma debe decidir el ciclo de liquidación, las comisiones, las retenciones, el arrastre de saldos negativos y las políticas fiscales. - El código de liquidación generado por la IA solo debe ponerse en funcionamiento después de conciliarse con el libro mayor, aplicar medidas para evitar pagos duplicados y controles de acceso, y someterse a una revisión profesional. 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. Autorización del pago Entrega completada Confirmación de compra o confirmación automática tras el transcurso del plazo acordado Comprobación de devoluciones, disputas y transacciones anómalas Determinación de los elementos sujetos a liquidación Inclusión en el lote de pagos 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. Elemento del extracto Descripción Importe bruto de la transacción Composición contractual del importe de venta, como precio del producto, precio de las opciones y gastos de envío Descuento asumido Descuentos asumidos respectivamente por la plataforma, el vendedor y los socios Importe de cancelaciones y reembolsos Reembolsos totales y parciales, y ajustes de gastos de envío Comisión de la plataforma Porcentaje de comisión, comisión fija y condición de sujeción a impuestos Costes relacionados con el pago Indicación de si los costes del PG se deducen por separado o están incluidos en la comisión Ajustes fiscales Elementos aplicables, como indicación del IVA y retenciones Otros ajustes Ajustes con fundamento contractual, como compensaciones, gastos publicitarios y penalizaciones Importe final pagadero Importe previsto para la transferencia después de aplicar todas las sumas y deducciones 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. Objeto de datos Función Libro de pedidos Registro de los estados de pedido, pago, entrega y confirmación de compra Elemento de liquidación Registro del importe bruto, las comisiones, los impuestos, los ajustes y el vendedor correspondiente de cada pedido Libro de ajustes Registro de reembolsos, compensaciones, penalizaciones y ajustes manuales Libro de retenciones Registro del importe retenido, el motivo, el plazo y el historial de liberación Lote de liquidación Conjunto de elementos pagaderos a un vendedor durante un período determinado Libro de pagos Registro de solicitudes de transferencia, éxitos, fallos y números de transacción externos Libro fiscal Registro de retenciones fiscales y del estado de emisión y declaración de justificantes Registro de auditoría Registro de todos los cambios importantes realizados por operadores y sistemas 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. FAQ Q. ¿La liquidación es una función en la que basta con restar la comisión del importe de la venta? A. No. La liquidación incluye la confirmación de compra, los reembolsos parciales, la retención de pagos, el arrastre de saldos negativos, los impuestos, los fallos en las transferencias, la prevención de pagos duplicados y la conciliación del libro mayor. No solo se necesita una fórmula de cálculo, sino también transiciones de estado y control de fondos. Q. ¿La fecha de referencia para la liquidación debe ser necesariamente la fecha de confirmación de compra? A. No se puede aplicar de manera uniforme un único criterio a todas las transacciones. Para los productos físicos se puede utilizar la confirmación de compra o la confirmación automática, pero los servicios, los contenidos digitales y los productos con reserva tienen diferentes condiciones de cumplimiento. Deben establecerse conjuntamente, para cada tipo de transacción, el evento de referencia y el plazo de pago legal o contractual. Q. ¿Cuanto más corto sea el ciclo de liquidación, siempre es mejor? A. Un ciclo corto reduce el saldo pendiente de pago y la carga de liquidez del vendedor, pero deben tenerse en cuenta las devoluciones, las transacciones anómalas y los costes operativos. En lugar de prolongarlo innecesariamente por motivos de riesgo, es importante establecer un periodo mínimo de verificación adecuado a las características de la transacción y una fecha de pago predecible. Q. Si se utiliza un PG, ¿la plataforma no necesita crear una política de liquidación? A. No. Un PG puede ofrecer funciones de pago, transferencia de fondos, depósito en garantía o pagos divididos, pero la decisión de qué pedidos pagar y cuándo, cómo calcular las comisiones y los importes de los reembolsos, y a quién retenerle los pagos depende de la política de la plataforma. Q. ¿Se debe retener un 3.3% a todos los vendedores particulares? A. No. El 3.3% es una expresión que normalmente engloba la retención del impuesto sobre los ingresos empresariales y el impuesto local sobre la renta de las personas físicas. La obligación de retener y el tipo aplicable deben determinarse no solo según la forma de registro del vendedor, sino también según la naturaleza de los ingresos, la relación contractual, la condición de residente y las disposiciones de excepción. Q. ¿Guardar los ingresos de las ventas en una cuenta separada garantiza una seguridad total? A. Una cuenta separada es un control básico para distinguir los fondos operativos de los ingresos de las ventas, pero por sí sola no garantiza el aislamiento frente a la insolvencia ni la protección jurídica. Deben verificarse, de acuerdo con el contrato y la legislación vigente, los mecanismos de protección necesarios, como un fideicomiso, un depósito o una garantía de pago, así como la naturaleza jurídica de la cuenta. Q. ¿Cómo se debe registrar una liquidación negativa? A. El importe reembolsado de un pedido ya pagado se registra como una transacción de ajuste separada y se descuenta del siguiente pago. Si el importe que debe descontarse es superior al pago previsto, el pago se fija en 0 wones y el saldo restante se arrastra a la siguiente liquidación. No se debe eliminar la transacción original ni sobrescribir una liquidación anterior. Q. Si no se recibe respuesta a una solicitud de transferencia, ¿se puede volver a solicitar de inmediato? A. No. Es posible que la primera solicitud se haya procesado correctamente y que solo se haya perdido la respuesta. Para evitar pagos duplicados, se deben utilizar una clave de idempotencia y un número de transacción externo para el mismo pago, consultar el resultado del procesamiento existente en el PG o el banco y, después, volver a intentarlo. Q. ¿Se puede poner directamente en producción el código de liquidación generado por la AI? A. No se recomienda. Se deben probar las transiciones de estado, la concordancia del libro mayor, la concurrencia, las solicitudes duplicadas, los reembolsos parciales, la recuperación ante fallos y el control de permisos. Los aspectos de finanzas electrónicas y fiscales también deben someterse a la revisión de expertos en función de la estructura real del negocio. Sources - Ley de Transacciones Financieras Electrónicas: https://www.law.go.kr/법령/전자금융거래법 - Ley de Protección de los Consumidores en el Comercio Electrónico, etc.: https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률 - Ley del Impuesto sobre la Renta: https://www.law.go.kr/법령/소득세법 - Ley de Impuestos Locales: https://www.law.go.kr/법령/지방세법 - Ley del Impuesto sobre el Valor Añadido: https://www.law.go.kr/법령/부가가치세법 Images - Flujo de automatización con IA entre tiendas, liquidación, seguridad y verificación: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp - Sistema de liquidación con IA conectado a controles, bóvedas de fondos, un banco y servidores: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp --- Category: Cómo hacer Source: https://injoys.com/es/articles/seven-policies-before-building-ai-settlement-system License: cc_by Translation-Status: reviewed