Split

Divida cada cobrança entre vários recebedores, com regras que você controla.

Split nativo no ledger — não em planilha. Por valor fixo ou percentual (bps), com templates reutilizáveis e condições avançadas por operação.

1 cobrança PAID

3 recebedores

Total

R$ 1.280,00

Loja (seller)

7000 bps

R$ 896,00
Marketplaceliable

2500 bps

R$ 320,00
Parceiro logístico

valor fixo

R$ 64,00
Soma das fatiasR$ 1.280,00

cada fatia = recebível + lançamento no mesmo ledger (idempotente)

O que a Bunne entrega

01

Nativo no ledger

Cada fatia vira recebível + lançamento no mesmo ledger auditável, por seller e ambiente. Nada mora em planilha paralela.

02

Templates reutilizáveis (SplitRule)

Regras nomeadas e versionadas por whitelabel, aplicáveis por public id na cobrança.

03

Condições avançadas

Split condicional por método de pagamento (na regra e por recebedor), janela de vigência e prioridade entre regras que valem para a mesma cobrança.

04

Ciclos mensais e reforço adaptativo

Teto de TPV pago total (encerra a regra ao atingir) ou mensal, que reinicia a cada ciclo por N meses. Com reforço opcional: se o ciclo estiver abaixo da meta até o dia definido, o percentual sobe temporariamente e volta ao base quando a meta é atingida.

05

Chargeback roteado (liable)

Cada recebedor marcado como responsável devolve a fatia proporcional via lançamento compensatório; a tela de chargebacks mostra quem foi responsabilizado.

Split por valor e percentual, templates (SplitRule), teto de TPV total ou mensal com reforço adaptativo, e chargeback liable: Disponível.

Como funciona

  1. 01

    Defina a regra

    Crie um SplitRule nomeado e versionado por whitelabel (ou um split inline na cobrança), com recebedores por valor fixo ou percentual (bps).

  2. 02

    Condicione (opcional)

    Escopo por método de pagamento, janela de vigência, prioridade entre regras e teto de TPV pago — total (encerra a regra) ou mensal, reiniciando a cada ciclo por N meses, com reforço adaptativo opcional.

  3. 03

    Aplique na cobrança

    Referencie a regra por public id ao criar a cobrança; os recebedores são resolvidos por public id, estritamente escopados ao whitelabel e ambiente.

  4. 04

    Materialize quando pagar

    Quando a cobrança fica PAID, cada fatia vira recebível + lançamento no mesmo ledger. Idempotente: reprocessar não duplica os lançamentos.

  5. 05

    Chargeback roteado

    Recebedor marcado como liable devolve a fatia proporcional via lançamento compensatório; a tela de chargebacks mostra quem foi responsabilizado.

Perguntas frequentes

O split mora em planilha?

Não. Cada fatia é um recebível mais um lançamento no mesmo ledger auditável, por seller e ambiente — não há planilha paralela.

Posso dividir por valor e por percentual?

Sim. Por valor fixo (centavos) ou percentual em bps, e você pode combinar recebedores dos dois tipos na mesma regra.

Dá para reutilizar a mesma divisão?

Sim. O SplitRule é um template nomeado e versionado por whitelabel, aplicável por public id na cobrança.

Como funcionam as condições avançadas?

Escopo por método de pagamento, janela de vigência, prioridade entre regras e teto de TPV pago que auto-desativa a regra ao atingir o limite.

O teto de TPV pode reiniciar todo mês?

Sim. Além do teto total (que encerra a regra ao atingir), há o teto mensal: reinicia a cada ciclo UTC, por um número definido de meses a partir da vigência. O contador de cada ciclo é atômico no banco (fonte de verdade no Postgres), não no cache.

O que é o reforço adaptativo (catch-up)?

Um ajuste opcional para regras percentuais com teto mensal: se, até um dia definido do ciclo, o TPV pago estiver abaixo da meta, o percentual sobe temporariamente para acelerar — e volta ao valor base assim que a meta é atingida. Útil para metas mensais de recebedores sem intervenção manual.

Quem assume o chargeback de uma fatia?

O recebedor marcado como liable devolve a fatia proporcional via lançamento compensatório; a responsabilização aparece na tela de chargebacks.

Um recebedor pode ser de outro whitelabel?

Não. Recebedores são resolvidos por public id, estritamente escopados ao whitelabel e ambiente — um id nunca cruza a fronteira de tenant.

Quer transformar isso em operação?