---
id: saas/take-rate-marketplaces
industria: SaaS e tecnologia
uso: específico
esforco: médio
grao: Transação (fato); cliente (vendedor, criador, loja) x dia e x mês
---

# Take rate: volume transacionado contra receita da plataforma

Quanto passou pela plataforma, quanto disso é receita sua e de onde ela vem, por cliente e por mês, sem confundir volume com faturamento.

## Resumo executivo

**Para quem:** SaaS que cobra comissão sobre as transações dos seus clientes: plataformas de pagamento, de creators, de delivery e marketplaces B2B.

**O que resolve**

- Volume transacionado e receita da plataforma em colunas separadas, cada um com a sua regra.
- Receita aberta por fonte: comissão, juros, antecipação e tarifas.
- Take rate por cliente que bate com o que a plataforma cobra.

**Por que importa:** Em plataforma transacional, o volume impressiona e a receita paga as contas. Quem soma o volume como faturamento infla a receita muitas vezes; quem desconta estorno do volume esconde a perda. Com volume e receita separados por fonte, dá para ver quais clientes trazem volume com pouca margem e quando uma mudança de tarifa mexeu no resultado.

**Perguntas de negócio que responde**

- Qual o take rate do mês e como ele mudou contra o mês anterior?
- Quanto da receita veio de comissão, de juros de parcelamento e de antecipação?
- Quais clientes têm volume alto e take rate abaixo do contrato?
- Quanto os 10 maiores clientes transacionaram esta semana contra a anterior?
- Quanto perdemos em estorno e chargeback este mês?

**O que você precisa**

- Pedidos, cobranças e lançamentos de carteira do produto conectados na Nekt
- A tabela de tarifas e comissões com vigência, inclusive as negociadas por cliente
- A lista de contas internas, de teste e de demonstração

**O que você recebe**

- Uma tabela de transações com volume, receita por fonte, estorno e chargeback
- Take rate por cliente, produto, meio de pagamento e mês
- Alertas de queda de volume dos maiores clientes
- Um agente de IA que separa volume de receita nas respostas

## Detalhado

### O problema

A cobrança traz o valor que o comprador pagou, e é fácil chamar isso de receita. Num caso real, um campo de receita bruta era só volume menos estorno e reembolso, sem tirar a parte que fica com o cliente, e ficava praticamente igual ao volume. Tarifas mudam com o tempo e por cliente, juros e antecipação vivem em tabelas separadas, e o status da assinatura do comprador engana sobre o que foi pago.

### Regras de negócio

1. **Volume é sempre cheio.** GMV ou TPV é o valor bruto pago pelo comprador nas transações aprovadas, com os juros de parcelamento quando é o comprador quem paga. Estorno, reembolso e chargeback são eventos separados, com data própria, e não reduzem o volume. Assim o volume de um mês fechado não muda quando um estorno chega depois. (Evite: Descontar estorno e reembolso do volume.)
2. **Receita vem dos lançamentos da plataforma.** A receita da plataforma é o que entra na conta dela: os lançamentos de comissão do split na carteira da plataforma. Quando só existe o percentual, receita = percentual de comissão da transação vezes o volume, arredondada por transação. Um campo pronto de receita bruta precisa ser testado contra os lançamentos antes de ser usado. (Evite: Usar um campo de receita bruta sem conferir, ou chamar o volume de receita.)
3. **Receita aberta por fonte, cada uma com a sua data.** Separe comissão (take rate ou MDR), juros de parcelamento, taxa de antecipação, tarifa de saque e outras tarifas. Comissão e juros na data do pagamento, antecipação na data de execução, saque na data de conclusão. Receita líquida = soma das fontes menos a parte da plataforma em estornos e chargebacks. (Evite: Uma coluna única de receita, sem saber de onde vem.)
4. **Pago é o mesmo critério para volume e receita.** Use um único critério de transação paga, o status aprovado do pagamento, para volume e receita. O status da assinatura do comprador (por exemplo, período ativo) não diz se aquela cobrança foi paga, e usar um critério em cada lado fez volume e receita não conversarem. (Evite: Receita pelo status da assinatura e volume pelo status do pagamento.)
5. **Tarifas versionadas por data e por cliente.** Tarifas mudam com o tempo e podem ser negociadas. Guarde a tabela com vigência (de, até) e o plano negociado de cada cliente por meio de pagamento: cartão, boleto e Pix, com percentual e valor fixo. Nunca aplique a tarifa de hoje ao passado. Tarifa de saque só incide em saque concluído. (Evite: Calcular a receita de todos os meses com a tarifa atual.)
6. **Regra de data que muda é declarada.** Quando a regra de data de um evento muda, por exemplo o saque datado pela criação até um dia e pela conclusão depois, guarde a data de corte e aplique cada regra ao seu período. Recalcular tudo com a regra nova reescreve meses fechados. (Evite: Trocar a data do evento para todo o histórico.)
7. **A base do take rate é a do contrato.** Take rate é receita / volume, e o volume certo é o que o contrato usa: vendas atribuídas à plataforma (por cupom, link ou canal próprio), não todas as vendas do cliente. Comissão por faixa é progressiva: cada faixa aplica o seu percentual só à parte do volume dentro dela. Valide contra o que a plataforma cobrou: numa base real, com a base certa, o cálculo bateu quase 100%. (Evite: Dividir a receita por todas as vendas do cliente.)
8. **Canal próprio separado de agregador.** Plataformas que recebem pedidos de canais próprios e de agregadores (marketplaces de delivery, por exemplo) mostram o volume por canal, porque receita e valor para o cliente são diferentes em cada um. Pedido com valor fora da realidade, acima de um teto declarado, entra como zero no volume e vai para revisão. (Evite: Somar todos os canais e aceitar qualquer valor de pedido.)
9. **Moeda convertida pela média do mês.** Volume em várias moedas é fluxo: converta pela taxa média do mês, não pela de fechamento, de uma fonte oficial como a tesouraria. Congele os meses fechados e registre manualmente a taxa que faltar, com aviso. (Evite: Converter pela taxa do último dia ou somar moedas.)
10. **Estorno e contestação dos próprios objetos.** No Stripe Connect e em gateways parecidos, estorno e contestação acontecidos depois da carga não atualizam a cobrança já carregada. Leia reembolsos e disputas dos seus próprios objetos e use o maior entre o valor estornado lá e o da cobrança. Só transações em produção (livemode no Stripe). (Evite: Confiar no campo de valor estornado da cobrança.)

### De onde vem cada parte da receita

Cada fonte tem sua tabela e sua data; nenhuma reduz o volume.

- **comissão sobre a venda** → Take rate ou MDR (`lançamento de split da plataforma`)
- **juros pagos pelo comprador no parcelado** → Juros de parcelamento (`data do pagamento`)
- **cliente adiantou recebíveis** → Taxa de antecipação (`data de execução`)
- **cliente sacou o saldo** → Tarifa de saque (`só saque concluído`)
- **estorno ou reembolso** → Redutor da receita (`evento à parte`)
- **chargeback** → Redutor e risco (`data da contestação`)

### Definições

| Métrica | Definição |
|---|---|
| GMV ou TPV | soma do valor pago pelo comprador nas transações aprovadas, com juros quando cobrados do comprador, pela data de pagamento |
| Receita bruta da plataforma | soma das fontes de receita da plataforma (comissão, juros, antecipação, tarifas), cada uma pela data do seu evento |
| Receita líquida | receita bruta - parte da plataforma nos estornos, reembolsos e chargebacks do período |
| Take rate | receita de comissão / volume da base contratual, por cliente e mês |
| Take rate efetivo | receita bruta total / GMV, por cliente e mês |
| Taxa de chargeback | valor em chargeback / GMV, pela data da contestação |
| Cliente transacionando | cliente com pelo menos uma transação aprovada no mês |

### Armadilhas

- **Receita bruta igual ao volume.** Um campo de receita bruta era volume menos chargeback e reembolso, sem descontar a parte do cliente. O valor ficou quase igual ao volume e distorceu todos os painéis que o usavam. Como evitar: Remova o campo e leia a receita dos lançamentos de comissão.
- **Período ativo não é pago.** A receita usava o status da assinatura do comprador, e assinaturas em período ativo entravam como pagas. Volume e receita não fechavam entre si. Como evitar: Use o status do pagamento nos dois lados.
- **Tarifa de hoje no passado.** A tarifa de saque mudou várias vezes em poucos anos, e um cálculo com a tarifa atual reescreveu a receita dos meses antigos. Como evitar: Tabela de tarifas com vigência, aplicada pela data do evento.
- **Base errada no take rate.** O take rate era calculado sobre todas as vendas do cliente, não só as atribuídas à plataforma, e o percentual parecia bem menor do que o contrato. Como evitar: Use a base contratual e valide contra o que foi cobrado.
- **Pedidos irreais no volume.** Pedidos de teste e valores digitados errados inflavam o volume de lojas pequenas e distorciam o ranking. Como evitar: Teto declarado por pedido, com o excedente em revisão.
- **Contas da casa no volume.** Lojas e contas de demonstração da própria empresa somavam volume e puxavam a média de take rate. Como evitar: Lista de contas internas e de teste aplicada na primeira camada.

### Teste de aceitação

- [ ] A receita de comissão do mês bate com a soma dos lançamentos de split da plataforma (diferença abaixo de 0,5%).
- [ ] O GMV de um mês fechado não muda quando chega um estorno ou chargeback depois.
- [ ] Para uma amostra de clientes, o take rate calculado bate com o percentual do plano vigente na data de cada transação.
- [ ] Nenhuma conta interna, de teste ou de demonstração aparece no volume.
- [ ] Receita bruta = soma das fontes, e receita líquida = bruta - redutores, para cada cliente e mês.

### Context document

```text
Take rate e receita da plataforma
- GMV/TPV = valor bruto pago pelo comprador em transações aprovadas. Nunca chame volume de receita.
- Estorno, reembolso e chargeback são eventos separados. Não reduzem o volume.
- Receita da plataforma vem dos lançamentos de comissão (split) na carteira da plataforma, mais juros, antecipação e tarifas, cada um na data do seu evento.
- Pago = status aprovado do pagamento, para volume e receita. Status da assinatura do comprador não diz se foi pago.
- Tarifas têm vigência e podem ser negociadas por cliente. Use a tarifa vigente na data da transação.
- Take rate = receita de comissão / volume da base contratual. Take rate efetivo = receita bruta / GMV. Diga qual está usando.
- Tarifa de saque só em saque concluído.
- Moedas convertidas pela taxa média do mês. Moeda de reporte: <moeda>.
- Contas internas, de teste e de demonstração ficam fora.
Exceções por cliente:
- <cliente>: comissão negociada de <percentual>% no cartão e <valor> por boleto.
- <cliente>: base do take rate = vendas com cupom da plataforma, não vendas totais.
```

### Variações

- **Resultado da venda:** Ciclos de 30, 60 e 90 dias de volume e receita a partir do fechamento do cliente, contra os 30 dias anteriores, para medir o resultado real do time comercial.
- **Marketplace com repasse:** No Stripe Connect, monte o livro por movimento de saldo: venda, repasse ao vendedor, estorno e contestação, cada um pelo seu tipo de objeto.
- **Volume como sinal de saúde:** Queda de volume transacionado do cliente entra no health score antes do cancelamento da assinatura.