---
title: "7 políticas a definir antes de criar um sistema de liquidação com AI"
locale: pt
category: how_to
category_name: "Como Fazer"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/seven-policies-before-building-ai-settlement-system
published_at: 2026-07-27T00:58:06+09:00
---

# 7 políticas a definir antes de criar um sistema de liquidação com AI

> A liquidação não é apenas uma função que subtrai comissões do valor das vendas, mas um sistema de operações financeiras que controla a destinação dos valores, as condições de pagamento, os reembolsos, os tributos e o tratamento de falhas. Antes de delegar a implementação à AI, as pessoas devem definir primeiro sete políticas, desde a data de referência da liquidação até os logs de auditoria.

## Key Points

- Os valores das vendas devem ser administrados como recursos restritos vinculados à obrigação de pagamento a vendedores e outros destinatários, e não como capital operacional de livre uso da plataforma.
- O status do pedido e o status da liquidação devem ser separados, e a confirmação da compra, o reembolso, a disputa e a falha no pagamento devem ser registrados individualmente no livro-razão.
- Nem sempre se deve reter 3.3% na fonte de vendedores pessoas físicas; a decisão deve considerar a natureza jurídica da renda e a condição do vendedor.
- Mesmo utilizando PG ou escrow, a plataforma deve definir o ciclo de liquidação, as comissões, as retenções, o transporte de saldo negativo e as políticas tributárias.
- O código de liquidação gerado por AI só deve entrar em operação após a conciliação do livro-razão contábil, a prevenção de pagamentos duplicados, o controle de permissões e a análise de especialistas.

A liquidação não é uma simples função de subtração. É um sistema contábil que determina os direitos e as obrigações de cada pedido, separa os fundos que a plataforma deve custodiar ou pagar e acompanha até mesmo reembolsos, disputas, impostos e falhas de transferência.

A IA generativa pode ajudar a escrever código e testes, mas não pode ser responsável pela política de liquidação. Se a política estiver incompleta, a IA poderá criar padrões plausíveis ou omitir exceções, e isso poderá resultar em pagamentos excessivos, pagamentos duplicados, erros fiscais ou crises de liquidez.

## Princípios confirmados pelo caso da TMON e da WeMakePrice em 2024

A falta de liquidação em larga escala dos valores de vendas da TMON e da WeMakePrice em 2024 mostrou como atrasos na liquidação podem causar grandes danos em cadeia a vendedores e consumidores. No entanto, a causa do caso não deve ser atribuída apenas a um ciclo de liquidação longo. Vários fatores, como gestão de recursos, liquidez, governança e controles internos, devem ser analisados em conjunto.

As principais lições para os operadores são claras.

- Não considerar os valores de vendas ainda não pagos como caixa da empresa disponível para uso livre.
- Quanto mais longo for o ciclo de liquidação, maior será o saldo não pago exposto a uma única falha ou falta de liquidez.
- Conciliar diariamente o saldo dos valores de vendas com os fundos efetivamente custodiados.
- Divulgar de forma transparente aos vendedores as condições de liquidação e os motivos de atrasos.
- Verificar separadamente a legislação aplicável, a estrutura contratual e o escopo dos serviços de PG.

A titularidade jurídica e a forma de proteção dos valores de vendas podem variar conforme a estrutura da transação. Portanto, no dia a dia, deve-se manter a cautela de que se trata de “dinheiro de terceiros”, mas o tratamento contábil e jurídico efetivo deve ser determinado de acordo com os contratos e a legislação vigente.

## 7 políticas de liquidação que devem ser definidas antes da implementação

### 1. Data-base da liquidação e ciclo de pagamento

Primeiro, deve-se definir quando um pedido se torna elegível para liquidação. Se apenas a data do pedido ou do pagamento for usada como referência, valores sujeitos a cancelamento antes da entrega ou a devolução poderão ser incluídos no pagamento.

Em transações comuns de produtos, pode-se projetar o seguinte fluxo.

1. Aprovação do pagamento
2. Conclusão da entrega
3. Confirmação da compra ou confirmação automática após o período acordado
4. Verificação de devoluções, disputas e transações anômalas
5. Confirmação da elegibilidade para liquidação
6. Inclusão no lote de pagamento
7. Conclusão da transferência e da conciliação

Os seguintes itens devem ser obrigatoriamente definidos.

- Evento de referência para liquidação por tipo de transação, como produtos, conteúdo digital e serviços
- Período até a confirmação automática da compra e seu momento inicial de contagem
- Ciclo de pagamento diário, semanal ou mensal
- Forma de tratamento de fins de semana e feriados
- Horário de fechamento da liquidação e lote ao qual serão atribuídas as transações posteriores ao fechamento
- Valor mínimo de pagamento e possibilidade de transportar pequenos saldos
- Possibilidade de permitir ciclos diferentes conforme a categoria do vendedor
- Procedimento para verificar se os prazos legais ou contratuais de pagamento não são excedidos

A data de elegibilidade para liquidação deve ser distinguida da data efetiva de pagamento. Por exemplo, `eligible_at` é o momento em que as condições de pagamento foram atendidas, `scheduled_payout_at` é o momento em que o pagamento foi incluído no lote e `paid_at` é o momento em que o sucesso da transferência foi confirmado.

### 2. Cálculo de comissões e demonstrativo de liquidação

Se apenas o valor final do pagamento for mostrado ao vendedor, será difícil conferir os cálculos, aumentando as consultas e disputas. São necessários tanto demonstrativos por pedido quanto totais por período.

| Item do demonstrativo | Descrição |
|---|---|
| Valor bruto da transação | Composição do valor contratual da venda, como preço do produto, preço das opções e frete |
| Descontos assumidos | Descontos assumidos respectivamente pela plataforma, pelo vendedor e por parceiros |
| Cancelamentos e reembolsos | Reembolsos totais e parciais, além de ajustes de frete |
| Comissão da plataforma | Alíquota da comissão, tarifa fixa e incidência ou não de tributos |
| Custos relacionados ao pagamento | Indicação de que os custos de PG são deduzidos separadamente ou incluídos na comissão |
| Ajustes tributários | Indicação de imposto sobre valor agregado, retenção na fonte e outros itens aplicáveis |
| Outros ajustes | Compensações, despesas de publicidade, penalidades e outros ajustes com fundamento contratual |
| Valor final do pagamento | Valor previsto para transferência após todos os acréscimos e deduções |

A política de comissões também deve especificar a base de cálculo. Deve-se definir se a referência será o preço de venda antes do desconto ou o valor pago após o desconto, se o frete e o imposto sobre valor agregado serão incluídos e como a comissão será estornada em caso de reembolso parcial.

É mais seguro não calcular valores monetários com tipos de dados de ponto flutuante. Quando a menor unidade monetária for inteira, como no caso do won, os valores devem ser armazenados como inteiros. Se forem necessários cálculos com moedas estrangeiras ou casas decimais, devem ser usados tipos de dados de ponto fixo e regras de arredondamento específicas para cada moeda.

### 3. Reembolsos e liquidações negativas

Um pedido já pago ao vendedor poderá ser reembolsado posteriormente. Nesse caso, o valor do reembolso e a comissão a ser restituída devem ser registrados no livro-razão de ajustes e deduzidos do próximo pagamento.

Por exemplo, se o valor previsto para a liquidação atual for de 300 mil won e a dedução relacionada ao reembolso de um pedido anterior for de 400 mil won, o tratamento poderá ser o seguinte.

- Valor do pagamento atual: 0 won
- Saldo não recuperado: 100 mil won negativos
- Valor transferido para a próxima liquidação: dedução de 100 mil won

A política deve incluir os seguintes itens.

- Forma de alocação do preço do produto, do frete e da comissão em caso de reembolso parcial
- Período de transporte do saldo negativo e ordem de compensação
- Método de recuperação junto a vendedores sem vendas por um longo período
- Fundamento contratual para a exigência de caução ou reserva de pagamento
- Procedimento para verificar obrigações pendentes antes do encerramento da conta do vendedor
- Forma de efetuar lançamentos de estorno em caso de cancelamento do reembolso ou alteração do resultado de uma disputa

Os registros das transações existentes não devem ser sobrescritos; a transação original e a transação de ajuste devem ser vinculadas. Dessa forma, será possível reproduzir qual reembolso alterou qual liquidação.

### 4. Retenção e liberação de pagamentos

Em vez de suspender incondicionalmente os pagamentos de toda a conta do vendedor, deve ser possível retê-los por pedido, valor ou motivo. Os principais motivos de retenção incluem:

- Disputa com consumidor ou devolução em andamento
- Suspeita de autonegociação, tomada de conta ou pagamento anômalo
- Falha na verificação da identidade, da empresa ou da conta bancária do vendedor
- Solicitação legítima de tribunal, autoridade investigativa ou órgão competente
- Não apresentação de documentos de liquidação exigidos contratualmente

Cada registro de retenção deve armazenar o valor afetado, código do motivo, documentos comprobatórios, momento de início, prazo de revisão, responsável e condições de liberação. Na tela do vendedor, dentro dos limites permitidos para divulgação, devem ser exibidos o valor retido, o motivo, as ações necessárias e o canal de atendimento.

Para impedir que um operador aplique retenções arbitrárias repetidamente, é recomendável separar as permissões de criação e liberação e aplicar aprovação dupla à liberação de retenções de valores elevados.

### 5. Gestão separada dos valores de vendas e estrutura de PG e escrow

Se os valores de vendas não pagos e as despesas operacionais da empresa forem administrados como se fossem o mesmo caixa disponível, uma falta de liquidez poderá se transformar imediatamente em falta de liquidação. No mínimo, os fundos relacionados aos valores de vendas e os recursos operacionais devem ser claramente separados nos livros internos e na gestão das contas, com conciliação diária dos saldos.

No entanto, o simples fato de criar uma conta separada não estabelece automaticamente uma segregação jurídica em caso de insolvência nem uma proteção integral dos fundos. A eficácia e as obrigações de mecanismos de proteção, como trust, depósito e garantia de pagamento, devem ser analisadas conforme a legislação aplicável e a estrutura contratual.

Dependendo do papel desempenhado pela plataforma nos processos de pagamento e repasse, poderão surgir questões de registro nos termos da Lei de Transações Financeiras Eletrônicas, inclusive como prestadora de serviços de intermediação de pagamentos eletrônicos. Nem todas as plataformas estão igualmente sujeitas ao registro como PG, e o simples fato de calcular dados de liquidação também não implica necessariamente essa obrigação. A avaliação deve considerar a forma efetiva de recebimento, custódia e transferência dos fundos, além das relações contratuais.

Plataformas em estágio inicial podem avaliar serviços de pagamento, escrow ou liquidação dividida por vendedor oferecidos por um PG registrado. Contudo, o uso de um PG não elimina as seguintes responsabilidades.

- Decidir quais pedidos serão encaminhados para pagamento e quando
- Calcular comissões e valores de ajuste
- Gerenciar reembolsos e transporte de saldos negativos
- Verificar informações e contas bancárias dos vendedores
- Conciliar os resultados do PG com o livro-razão interno
- Responder a falhas e insucessos de pagamento

As obrigações e exceções relacionadas ao escrow também variam conforme o tipo de transação e a forma de pagamento, entre outros fatores, portanto é necessário consultar a legislação de comércio eletrônico e seus regulamentos subordinados.

### 6. Retenção na fonte, imposto sobre valor agregado e comprovantes

A regra de que “vendedores individuais estão sempre sujeitos à retenção de 3,3%” não é exata. Em geral, 3,3% é a expressão usada para a soma de 3% de imposto de renda sobre rendimentos empresariais e 0,3% de imposto de renda individual local. A incidência efetiva de retenção na fonte depende não apenas de o vendedor possuir ou não registro empresarial, mas também da natureza da renda, da relação contratual, do item pago e das regras de exceção.

As seguintes informações devem ser coletadas nas etapas de cadastro e contratação.

- Tipo de vendedor, como pessoa física, empresário individual ou pessoa jurídica
- Condição de residente ou pessoa jurídica nacional ou estrangeira
- Situação tributária, como tributação, isenção ou regime simplificado
- Informações necessárias às declarações legais, como número de registro empresarial e número de registro de residente
- Natureza da renda e motivo do pagamento
- Comprovantes necessários, como nota fiscal tributária, fatura ou comprovante de retenção na fonte

Também não se deve generalizar que vendedores empresariais “sempre recebem 100% sem qualquer dedução tributária”. Se o contrato prevê a dedução da comissão da plataforma, o valor bruto da transação, a comissão, o imposto sobre valor agregado e o valor efetivamente transferido devem ser discriminados. A entidade responsável pela emissão da nota fiscal tributária referente à comissão pelo serviço de intermediação prestado pela plataforma, assim como o momento da emissão, também devem ser definidos de acordo com o contrato e a relação de fornecimento prevista na legislação tributária.

Em geral, aplica-se aos tributos retidos na fonte uma estrutura de declaração e recolhimento até o dia 10 do mês seguinte ao mês do pagamento. No entanto, como podem existir exceções ou alterações de prazo, devem ser verificadas as regras vigentes no momento efetivo da declaração. Em vez de fixar as regras tributárias diretamente no código, é mais seguro gerenciá-las como políticas versionadas, com datas de início e término de vigência.

### 7. Falhas de pagamento, administração da liquidação e logs de auditoria

Mesmo pagamentos gerados corretamente podem falhar por erro na conta bancária, divergência do titular, restrições de transação, manutenção bancária ou falha do PG. Em vez de indicar a falha simplesmente como “não pago”, os estados e as regras de reprocessamento devem ser detalhados.

Exemplos de estados recomendados:

- `scheduled`: pagamento agendado
- `submitted`: solicitação enviada ao banco ou PG
- `processing`: processamento por instituição externa
- `paid`: sucesso confirmado
- `failed_retryable`: falha que permite nova tentativa
- `failed_final`: falha definitiva que exige correção de informações ou outra ação
- `reversed`: cancelamento ou devolução após o sucesso

As novas tentativas devem usar uma chave de idempotência que identifique o mesmo pagamento. Como um atraso na resposta poderá ser interpretado erroneamente como falha e causar um pagamento duplicado, deve-se primeiro consultar o número da transação externa para verificar o resultado da solicitação existente.

Os seguintes dados devem ser mantidos no log de auditoria.

- Autor da ação e conta de operador utilizada
- Momento da execução e informações de segurança, como o local de acesso
- Valores anteriores e posteriores à alteração
- Motivo da retenção, liberação ou ajuste manual
- Aprovador e executor
- Pedido relacionado, lote de liquidação e número da transação externa
- Código da falha e histórico de novas tentativas

Os logs de auditoria devem ser protegidos para que operadores comuns não possam alterá-los nem excluí-los. Para dados pessoais e financeiros, devem ser aplicadas políticas de coleta mínima, controle de acesso, criptografia e período de retenção.

## Composição mínima do modelo de dados de liquidação

Em vez de pedir à IA que comece pelas telas, é recomendável definir primeiro os seguintes livros-razão.

| Objeto de dados | Função |
|---|---|
| Livro-razão de pedidos | Registrar os estados do pedido, pagamento, entrega e confirmação da compra |
| Item de liquidação | Registrar o valor bruto, a comissão, os tributos, os ajustes e o vendedor correspondente a cada pedido |
| Livro-razão de ajustes | Registrar reembolsos, compensações, penalidades e ajustes manuais |
| Livro-razão de retenções | Registrar valores retidos, motivos, prazos e histórico de liberações |
| Lote de liquidação | Agrupar os pagamentos devidos a um vendedor em determinado período |
| Livro-razão de pagamentos | Registrar solicitações de transferência, sucessos, falhas e números de transações externas |
| Livro-razão fiscal | Registrar retenções na fonte e estados de emissão e declaração de comprovantes |
| Log de auditoria | Registrar todas as alterações importantes realizadas por operadores e pelo sistema |

Cada livro-razão deve conter a moeda, a versão da política, o momento de criação e uma chave de vínculo com a transação original. Uma simples mudança no estado do pedido não pode alterar silenciosamente os valores de liquidações passadas.

## Regras de controle que devem ser obrigatoriamente mantidas

O sistema de liquidação deve verificar automaticamente as seguintes condições invariáveis.

- Cada item de liquidação está vinculado a exatamente um vendedor e uma transação original.
- Não efetuar duas transferências com a mesma chave de pagamento.
- A soma dos valores pagos, não pagos, retidos e ajustados corresponde ao livro-razão.
- Todo ajuste manual possui um motivo e um aprovador.
- Liquidações já fechadas não são alteradas; as correções são feitas por lançamentos de estorno e novos ajustes.
- As diferenças entre os saldos internos relacionados aos valores de vendas e os saldos do PG e do banco são investigadas diariamente.
- A versão da política aplicada é registrada nos cálculos de tributos e comissões.

## Exemplo de especificação de política a ser fornecida à IA

Estruturar os requisitos da seguinte forma pode reduzir omissões.

> Projete separadamente os estados do pedido e da liquidação. Implemente condições de confirmação da compra por tipo de transação, lote de pagamento toda quarta-feira, tratamento de feriados, base de cálculo de comissões, alocação de reembolsos parciais, transporte de saldos negativos, retenção de pagamento por item, versão da política de retenção na fonte, chave de idempotência do pagamento e log de auditoria imutável. Trate os valores como inteiros ou números de ponto fixo. Todos os ajustes manuais exigem aprovação dupla e justificativa. Antes da implementação, apresente como lista de perguntas as políticas ainda não definidas, como valor mínimo de pagamento, período para confirmação automática da compra, recuperação de saldos negativos de longo prazo, prazo de retenção e número de novas tentativas.

Além do código, os seguintes entregáveis também devem ser solicitados à IA.

- Diagrama de transição de estados e lista de exceções
- Esquema de banco de dados e restrições
- Sistema de permissões e aprovações
- Testes de fluxo normal, valores-limite, falhas e solicitações duplicadas
- Formato do relatório diário de conciliação
- Procedimentos de recuperação de falhas e processamento manual
- Checklist de proteção de dados pessoais e financeiros

## Checklist antes do lançamento

- [ ] A data-base da liquidação está documentada para cada tipo de transação.
- [ ] O vendedor consegue conferir o demonstrativo de liquidação por pedido.
- [ ] Os testes de reembolso parcial e transporte de saldo negativo foram aprovados.
- [ ] Os motivos, prazos e permissões de liberação das retenções estão definidos.
- [ ] Os critérios de gestão dos fundos relacionados aos valores de vendas estão separados dos recursos operacionais.
- [ ] A aplicabilidade das regras de PG, escrow e atividades financeiras eletrônicas foi confirmada com especialistas.
- [ ] O tratamento tributário por tipo de vendedor e de renda foi analisado.
- [ ] Os testes de prevenção de pagamentos duplicados e de novas tentativas após falhas foram concluídos.
- [ ] É possível realizar a conciliação diária entre banco, PG e livro-razão interno.
- [ ] As alterações manuais dos operadores são registradas no log de auditoria.
- [ ] Há procedimentos para avisar os vendedores e atender consultas em caso de falha na liquidação.

## Conclusão

O ponto de partida de um sistema de liquidação seguro não é um prompt de IA, mas políticas explícitas e livros-razão separados. A IA deve ser usada como ferramenta para transformar regras definidas em código, testes e documentação, enquanto a estrutura de custódia dos fundos e as decisões sobre finanças eletrônicas e tributação devem ser validadas em conjunto com PG, especialistas contábeis e fiscais e profissionais jurídicos.

## FAQ

### A liquidação consiste apenas em subtrair a comissão do valor da venda?
Não. A liquidação inclui confirmação da compra, reembolso parcial, retenção de pagamento, saldo negativo transferido para o período seguinte, impostos, falha na transferência, prevenção de pagamentos duplicados e conciliação do livro-razão. Além da fórmula de cálculo, são necessários transições de estado e controle de fundos.

### A data de referência da liquidação deve ser obrigatoriamente a data de confirmação da compra?
Não é possível aplicar uniformemente um único critério a todas as transações. Para produtos físicos, pode-se usar a confirmação da compra ou a confirmação automática, mas serviços, conteúdo digital e produtos de reserva têm condições diferentes para a conclusão da prestação. É necessário definir, para cada tipo de transação, o evento de referência juntamente com os prazos legais e contratuais de pagamento.

### Quanto mais curto o ciclo de liquidação, melhor?
Um ciclo curto reduz o saldo pendente de pagamento e a pressão sobre o fluxo de caixa do vendedor, mas é preciso considerar devoluções, transações suspeitas e custos operacionais. Em vez de prolongá-lo desnecessariamente sob a justificativa de risco, é importante estabelecer um período mínimo de verificação adequado às características da transação e uma data de pagamento previsível.

### Ao usar um PG, a plataforma não precisa criar uma política de liquidação?
Não. Um PG pode fornecer funções de pagamento, transferência de fundos, escrow ou pagamento dividido, mas cabe à política da plataforma determinar quais pedidos serão pagos e quando, como serão calculadas as comissões e os valores de reembolso e quais pagamentos serão retidos.

### É necessário reter 3,3% na fonte de todos os vendedores pessoa física?
Não. Os 3,3% normalmente se referem à soma da retenção na fonte sobre rendimentos empresariais e do imposto de renda local da pessoa física. A necessidade de retenção na fonte e a alíquota devem ser determinadas não apenas pela forma de registro do vendedor, mas também pela natureza da renda, pela relação contratual, pela condição de residente e pelas regras de exceção.

### Manter os valores das vendas em uma conta separada é totalmente seguro?
Uma conta separada é um controle básico para distinguir os recursos operacionais dos valores das vendas, mas, por si só, não garante segregação em caso de insolvência nem proteção jurídica. É necessário verificar, de acordo com o contrato e a legislação vigente, as formas de proteção exigidas, como fideicomisso, depósito ou garantia de pagamento, bem como a natureza jurídica da conta.

### Como deve ser registrada uma liquidação negativa?
Registre o valor do reembolso de um pedido já pago como uma transação de ajuste separada e desconte-o do próximo pagamento. Se o valor a descontar for maior que o valor previsto para pagamento, o pagamento deve ser de 0 won, e o saldo restante deve ser transferido para a próxima liquidação. Não se deve excluir a transação original nem sobrescrever demonstrativos de liquidação anteriores.

### Se não houver resposta à solicitação de transferência, posso solicitá-la novamente imediatamente?
Não. A primeira solicitação pode ter sido concluída com sucesso, mas apenas a resposta pode ter sido perdida. Para evitar pagamentos duplicados, é necessário usar uma chave de idempotência e um número de transação externo para o mesmo pagamento, consultar o resultado do processamento anterior junto ao PG ou ao banco e só então tentar novamente.

### O código de liquidação gerado por AI pode ser colocado em operação imediatamente?
Não é recomendável. É necessário testar transições de estado, consistência do livro-razão, concorrência, solicitações duplicadas, reembolsos parciais, recuperação de falhas e controle de acesso. Questões relacionadas a transações financeiras eletrônicas e tributação também devem ser analisadas por especialistas com base na estrutura real do negócio.

## Sources

- [Lei de Transações Financeiras Eletrônicas](https://www.law.go.kr/법령/전자금융거래법)
- [Lei de Proteção ao Consumidor no Comércio Eletrônico e Similares](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Lei do Imposto de Renda](https://www.law.go.kr/법령/소득세법)
- [Lei de Impostos Locais](https://www.law.go.kr/법령/지방세법)
- [Lei do Imposto sobre Valor Agregado](https://www.law.go.kr/법령/부가가치세법)

## Images

![Fluxo de automação com IA ligando lojas, liquidação, segurança e verificação](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp)
![Sistema de liquidação com IA ligado a controles, cofres de fundos, banco e servidores](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp)