Subcontas de Vendedores em Marketplaces: Receitas vs Contas a Pagar
Um guia prático para separar o dinheiro dos clientes, a comissão da plataforma, as contas a pagar a vendedores, as reservas e os pagamentos com lançamentos contabilísticos equilibrados e um modelo de dados operacional de encomenda a pagamento.
O erro mais comum na contabilidade de marketplaces é tratar o pagamento bruto do comprador como receita da plataforma. Um cliente paga 100 €, esses 100 € entram na conta do processador de pagamentos e alguém regista a totalidade como vendas. Os livros balancem durante algum tempo, a receita parece excelente e, depois, um auditor pergunta onde está a responsabilidade perante o vendedor. Não existe nenhuma, porque os 90 € do vendedor nunca foram registados como um valor em dívida.
A solução é estrutural, não cosmética. Um marketplace precisa de um modelo de livro-razão (ledger) que separe cinco grupos distintos desde o primeiro lançamento: dinheiro de clientes detido em trânsito, receita de comissões da plataforma, contas a pagar a vendedores, comissões de processamento e reservas. Os pagamentos aos vendedores (payouts) constituem um sexto evento que liquida a conta a pagar, e não um evento de receita ou gasto por si só. Este guia mostra os lançamentos equilibrados e o modelo de dados que mantêm esses grupos distintos.
Comece pela conclusão sobre principal versus agente
Antes de qualquer estrutura de contas importar, a plataforma tem de decidir o que está a vender. Ao abrigo da norma ASC 606, isto é avaliado por cada bem ou serviço especificado, e a resposta determina se a receita é registada pelo valor bruto ou líquido. Uma plataforma pode atuar como principal num fluxo e como agente noutrou.
numa venda típica de marketplace de produtos de um vendedor, a plataforma atua habitualmente como agente. Encarrega-se de fazer chegar o produto do vendedor ao comprador, não assume o risco de inventário e a sua remuneração é uma comissão. A orientação da Deloitte sobre a dualidade principal versus agente ao abrigo da ASC 606 enquadra a análise em torno do controlo: a responsabilidade pelo cumprimento da promessa, o risco de inventário e a discricionariedade na fixação de preços são indicadores, e não uma lista de verificação que se sobreponha à avaliação subjacente do controlo.
A razão pela qual isto deve constar na conceção do livro-razão (ledger), e não apenas numa nota interna, é que a conclusão determina cada lançamento subsequente. Se a plataforma for um agente, a parte do vendedor constitui um passivo no momento em que é gerada. Se for principal num serviço de logística ou de garantia, essa parte constitui receita da plataforma. Guarde a conclusão como dado estruturado:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Um revisor oficial de contas que analise uma linha de comissão líquida dois anos mais tarde deve conseguir perceber porque é que o valor bruto não foi utilizado. Como a BillingPlatform refere sobre a ASC 606 entre principal e agente, o rótulo "marketplace" não resolve a questão. A análise do controlo sim.
Defina o saldo do vendedor antes de escrever uma única regra de diário
O "saldo do vendedor" não é um número único. Um vendedor pode ter um saldo histórico saudável e nada disponível para pagamento, porque o dinheiro ainda está pendente ou retido em reserva. Se agrupar estes estados num só, reportará incorretamente o que o vendedor pode retirar e o que a plataforma ainda deve.
No mínimo, deve monitorizar:
- Pendente: gerado ou cobrado, mas ainda não elegível para pagamento
- Disponível: elegível para pagamento ao abrigo das regras da plataforma
- Reservado: retido para fazer face a potenciais reembolsos, litígios ou reversões de pagamento (chargebacks)
- Pago: transferido ou submetido para liquidação
- Negativo: montante em dívida pelo vendedor, recuperável a partir de receitas futuras
- Em suspenso: recebido, mas com o vendedor ou tratamento ainda por apurar
Os fornecedores de pagamentos já modelam esta distinção. O Stripe separa cada conta ligada em saldos pendentes e disponíveis, e mantém um saldo de reserva ao nível da plataforma para determinados saldos negativos de vendedores. Se o processador separa estes estados, o livro-razão (ledger) também tem de o fazer, caso contrário a reconciliação nunca baterá certo.
O plano de contas e as dimensões relevantes
Uma estrutura inicial viável mantém separadas as contas de compensação (clearing), os passivos e as receitas, e transporta uma dimensão de vendedor em cada lançamento material.
| Finalidade | Conta ou dimensão | Tratamento |
|---|---|---|
| Fundos do processador a aguardar liquidação | Compensação do processador de pagamentos | Ativo de compensação |
| Pagamento do processador depositado no banco | Banco | Ativo |
| Valor do vendedor gerado mas não pago | Contas a pagar a vendedores | Passivo |
| Detalhe ao nível do vendedor | Dimensão seller_id |
Detalhe de passivo, não receita |
| Comissão da plataforma | Receita de comissões | Receita |
| IVA ou imposto sobre vendas | Impostos a pagar | Passivo |
| Comissões do processador | Gastos de processamento de pagamentos | Gasto |
| Reservas de vendedores | Passivo de reserva | Dependente do contrato |
| Reembolsos | Contrareceita ou reembolsos | Anula o tratamento original |
| Reversões de pagamento (chargebacks) | Perda, conta a receber ou recuperação do vendedor | Depende de quem suporta a perda |
| Pagamentos a aguardar confirmação bancária | Compensação de pagamentos a vendedores | Conta de compensação |
| Montantes não atribuídos | Suspenso | Exceção temporária |
Cada lançamento material deve conter o vendedor, a encomenda, o lote de pagamento, o processador, a moeda, a entidade legal, o tratamento fiscal, o tipo de evento, a referência externa e qualquer hiperligação de anulação. Sem estes elementos, a subconta do vendedor não consegue comprovar um saldo individual e o razão geral não consegue comprovar o total.
Pode implementar a subconta como uma conta de passivo por vendedor, uma conta agregada de contas a pagar com seller_id como dimensão, ou uma divisão entre contas a pagar, reservas e compensação de pagamentos. A abordagem de agregado com dimensão escala melhor assim que ultrapassa algumas dezenas de vendedores. Escolha o modelo em conjunto com o seu contabilista, uma vez que as regras de salvaguarda de fundos e a regulamentação de pagamentos local podem afetar a forma como os fundos devem ser apresentados. Para conhecer a mecânica subjacente aos lançamentos, o nosso artigo sobre APIs de livros-razão de partidas dobradas para a contabilidade de marketplaces aborda as primitivas do razão sobre as quais este modelo assenta.
Registe a venda com linhas separadas para o vendedor e para a plataforma
Considere uma venda em regime de agente: o cliente paga 100 €, a comissão da plataforma é de 10 € e o vendedor ganha 90 €. No momento em que a comissão e o direito do vendedor são gerados:
| Conta | Débito | Crédito |
|---|---|---|
| Compensação do processador de pagamentos | 100 € | |
| Contas a pagar a vendedores - Vendedor A | 90 € | |
| Receita de comissões | 10 € |
O controlo fundamental: os 90 € são creditados numa conta de passivo, e não de receita. A plataforma reconhece 10 €. Este é o resultado a que o exemplo de marketplace da norma ASC 606 chega para um agente, onde a plataforma reconhece a respetiva comissão em vez do valor total de vendas do vendedor.
Se o imposto for cobrado separadamente, adicione a linha de imposto a pagar e reduza o montante do vendedor ou da plataforma de acordo com a conclusão fiscal. Não misture o imposto na comissão ou nas contas a pagar ao vendedor por conveniência.
Mantenha as comissões do processador fora dos cálculos de receitas e contas a pagar
Três conceitos são constantemente confundidos: comissão da plataforma, comissão do processador e montante do pagamento. São distintos e afetam contas diferentes.
O cliente paga 100 €, a comissão é de 10 €, o processador retém 3 €.
- A receita da comissão mantém-se em 10 €, caso seja esse o contrato.
- A comissão do processador de 3 € constitui um gasto.
- A conta a pagar ao vendedor é de 90 €, a menos que o contrato estipule que o vendedor suporta a comissão de processamento. Só nesse caso é que desce para 87 €, com um encargo correspondente de 3 € debitado ao vendedor.
Registar apenas o valor líquido de 97 € que entra no banco elimina a venda bruta, a comissão e a comissão de processamento num único passo. A nossa referência de reconciliação de pagamentos defende o mesmo princípio: decomponha a liquidação, trate as comissões do processador como gastos e nunca permita que o depósito líquido substitua a receita.
Modele a disponibilidade, as reservas e os pagamentos como eventos separados
O dinheiro muda de estatuto várias vezes entre a captura e a liquidação em numerário. Cada transação merece o seu próprio lançamento, e uma reserva nunca deve ser uma redução inexplicada da receita.
Quando os fundos disponíveis passam a reserva:
| Conta | Débito | Crédito |
|---|---|---|
| Contas a pagar a vendedores - Vendedor A | 15 € | |
| Passivo de reserva de vendedores | 15 € |
Quando a reserva é libertada, anule o lançamento. A obrigação total do vendedor não se alterou; o seu estatuto sim. O Stripe documenta transações de reserva que aumentam e libertam reservas, além de transferências de cobrança para saldos negativos de longa data, razão pela qual estas operações exigem contas identificáveis em vez de um único lançamento de compensação líquida.
Os pagamentos aos vendedores (payouts) seguem um tratamento em duas etapas. Na aprovação:
| Conta | Débito | Crédito |
|---|---|---|
| Contas a pagar a vendedores - Vendedor A | 90 € | |
| Compensação de pagamentos a vendedores | 90 € |
Na liquidação bancária confirmada:
| Conta | Débito | Crédito |
|---|---|---|
| Compensação de pagamentos a vendedores | 90 € | |
| Banco | 90 € |
Se o pagamento falhar, reverta a compensação de volta para a conta a pagar ao vendedor. Um pagamento é a liquidação de um passivo, e não um gasto. Tratá-lo como um gasto duplicaria o registo face à venda que já tinha contabilizado a conta a pagar. O Stripe separa o estado do pagamento (pending, in_transit, paid, failed, canceled) e a data prevista de chegada a partir do momento da iniciação, e essas datas não devem ser fundidas num único carimbo temporal.
O modelo de dados de encomenda a pagamento
A subconta funciona com base em eventos, e não no estado atual da encomenda na aplicação. Cada evento que afeta um vendedor transporta a mesma estrutura de dados (envelope):
seller_id,event_id,order_idevent_type(sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
A partir desses eventos, calcula-se o saldo de fecho em vez de se armazenar um campo mutável:
Saldo de fecho do vendedor
= saldo de abertura
+ créditos ao vendedor
− débitos ao vendedor
− pagamentos efetuados
± movimentos de reservas
± correções
Cada evento externo requer uma chave de idempotência durável para que as tentativas repetidas (retries) e os webhooks duplicados não creditem o vendedor duas vezes nem efetuem um pagamento em duplicado. Padrões eficazes:
- Evento de diário do vendedor:
seller_id:order_id:event_type:version - Lote de pagamento:
processor:payout_id - Evento do processador:
processor:event_type:processor_event_id
As orientações da própria Stripe sobre webhooks advertem que ocorrem eventos duplicados, pelo que a deteção de duplicados não é opcional. Os lançamentos registados mantêm-se imutáveis. As correções passam por um lançamento de anulação seguido de um lançamento corrigido, sendo o seu próprio envelope de eventos a transportar a hiperligação reversal_of e o motivo. O livro-razão guarda os lançamentos e não essa ligação: o Nordlet disponibiliza operações de criação, consulta e listagem de transações de diário na sua documentação da API e não permite atualizações ou eliminações, pelo que uma correção constitui sempre uma nova transação em vez de uma edição.
Os reembolsos e as reversões remetem para a origem, nunca flutuam
Um reembolso que surja no pagamento da semana seguinte nunca deve transformar-se numa nova venda negativa associada a esse pagamento. Associe-o à transação original e preserve a afetação original do vendedor. Dependendo do contrato:
- Anule a comissão se o contrato estipular que esta é reembolsável
- Debite a conta a pagar ao vendedor se este suportar o reembolso
- Debite uma conta de perdas da plataforma se esta o suportar
- Aumente uma reserva enquanto um litígio estiver aberto, libertando-a ou utilizando-a upon resolução
As reversões de pagamento (chargebacks) efetuadas após o pagamento ao vendedor dão origem a saldos negativos. O dinheiro do vendedor já saiu, pelo que a plataforma o recupera em receitas futuras ou absorve a perda. O modelo tem de permitir saldos negativos de vendedores e definir a regra de recuperação. Os relatórios de marketplaces da Adyen mostram reembolsos e chargebacks a produzir linhas de débito separadas por titular de conta, que é o nível de granularidade a atingir.
Reconcilie por pagamento, e não por mês
Decomponha cada liquidação do processador antes de efetuar o lançamento e reconcilie cada pagamento em vez de agregar um mês inteiro:
Cobranças brutas
− reembolsos
− comissões do processador
− reversões de pagamento (chargebacks)
± reservas e ajustes
= pagamento líquido do processador
De seguida, comprove que quatro saldos coincidem para cada vendedor e moeda: a subconta do vendedor, o saldo de vendedor no processador, o relatório de pagamentos e a compensação bancária. Quando diferirem, classifique a diferença (desfasamento temporal, evento em falta, duplicado, atribuição incorreta, moeda errada, pagamento falhado, chargeback lançado na parte incorreta). Compensar as diferenças por via líquida faz com que os erros se anulem mutuamente e sobrevivam até ao fecho seguinte.
Agregar um mês completo permite que os desfasamentos temporais se cancelem e oculta quebras reais. A reconciliação por pagamento, indexada ao ID de pagamento e à referência da transação em vez do montante e da data, deteta essas ocorrências.
Modos de falha comuns
| Modo de falha | Porque prejudica | Controlo |
|---|---|---|
| Pagamento bruto do cliente registado como receita | Empola a receita, oculta o passivo perante o vendedor | Separar as contas a pagar e a comissão no momento em que são geradas |
| Registo exclusivo de depósitos líquidos | Perde o valor bruto, as comissões, os reembolsos e as reservas | Decompor cada liquidação |
| Pagamento contabilizado como gasto | Representa incorretamente a liquidação de um passivo | Debitar a conta a pagar ao vendedor no pagamento |
| Um único campo de saldo de vendedor | Mistura saldos pendentes, disponíveis, reservados e pagos | Monitorizar explicitamente os estados do saldo |
| Comissão calculada no momento do pagamento | A receita fica dependente do agendamento dos pagamentos | Reconhecer a comissão quando é gerada |
| Reserva tratada como redução de receita | Oculta o desfasamento temporal e o risco | Monitorizar a retenção, a libertação e a utilização separadamente |
| Reembolso aplicado ao pagamento mais recente | Quebra a atribuição à encomenda | Associar o reembolso à transação original |
| Edição de lançamentos já registados | Destrói a pista de auditoria | Anular e voltar a registar |
| Webhooks retransmitidos | Créditos e pagamentos duplicados | Chaves de idempotência, deteção de duplicados |
| Cruzamento apenas por montante e data | Itens diferentes entram em colisão | Cruzar por ID de pagamento, ID de transação, vendedor e moeda |
O que faria em primeiro lugar
Mapeie o fluxo de dinheiro antes de tocar no plano de contas. Anote todos os eventos, desde a captura do pagamento até à libertação da reserva, e assinale quais geram receita, quais criam um passivo e quais apenas alteram o estado.
Em seguida, construa um fluxo completo de ponta a ponta e comprove que equilibra: uma venda normal, um reembolso parcial, um chargeback após o pagamento, uma reserva retida e libertada, e um pagamento falhado. Execute estes passos com saldos esperados conhecidos. Se a conta de controlo de contas a pagar a vendedores for igual à soma das subcontas, a compensação do processador bater certo com o relatório de liquidação e o depósito bancário bater certo com o ID de pagamento, terá uma espinha dorsal funcional.
Ative o fecho de períodos apenas após o primeiro mês fechar limpidamente com um saldo em suspenso a zero. Fechar demasiado cedo apenas congela erros.
O Nordlet regista liquidações com base nestes princípios de origem: a comissão da plataforma vai para a receita de comissões, a parte do vendedor para as contas a pagar a vendedores, as comissões do processador para os gastos de processamento de pagamentos, e tudo o que ainda não esteja atribuído vai para uma conta suspensa. Os períodos do livro-razão mantêm-se abertos até que os feche explicitamente, permitindo que o primeiro mês seja fechado assim que a conta suspensa estiver a zero. A página de funcionalidades lista o que está incluído.
FAQ
O pagamento do comprador é alguma vez considerado receita da plataforma?
Apenas para os bens ou serviços específicos em que a plataforma atua como principal. Numa venda de marketplace em regime de agente de produtos de um vendedor, a receita é a comissão e a parte do vendedor constitui um passivo. Uma plataforma pode atuar como principal num serviço de logística e como agente para os bens subjacentes na mesma encomenda, pelo que a avaliação é feita por bem ou serviço especificado, e não por empresa.
As reservas devem reduzir a receita?
Não. Uma reserva representa uma alocação temporal e de risco, e não um ajuste de receita. Transfira fundos da conta a pagar ao vendedor para um passivo de reserva quando os reter, e reverta a operação quando os libertar. A receita e a comissão não são afetadas pelo facto de o dinheiro do vendedor se encontrar atualmente retido em reserva.
Como posso evitar pagamentos duplicados resultantes de tentativas repetidas de webhooks?
Associe uma chave de idempotência a cada evento externo, tal como processor:payout_id para lotes de pagamentos, e detete eventos duplicados no momento da escrita. Os fornecedores avisam explicitamente que ocorrem entregas duplicadas de webhooks, pelo que o livro-razão tem de rejeitar a segunda tentativa em vez de a registar novamente.
O saldo de um vendedor pode ficar negativo?
Sim, e o modelo tem de o permitir. Um chargeback que surge após o pagamento ter sido efetuado ao vendedor deixa a plataforma com um direito a receber face ao vendedor ou com uma perda que esta absorve. Suprimir saldos negativos apenas oculta uma obrigação não registada.
Porque devo reconciliar cada pagamento em vez do total mensal?
Porque os desfasamentos temporais e os erros cancelam-se quando agrega um mês, fazendo com que os totais pareçam bater certo enquanto as transações individuais estão incorretas. A reconciliação por pagamento, cruzada por IDs de pagamento e de transação, revela eventos em falta, duplicados e chargebacks incorretamente atribuídos antes do fecho.