Fluxo de Contabilidade para Marketplaces com o Stripe Connect

A maioria dos problemas de contabilidade em marketplaces tem origem num único erro: tratar a transferência bancária da Stripe como se fosse receita. A transferência é o saldo líquido de dezenas de eventos económicos distintos e registá-la como uma única linha de proveitos elimina a comissão da plataforma, a responsabilidade perante o vendedor e todas as comissões e litígios subjacentes. Um fluxo de trabalho correto desagrega a transferência antes de qualquer lançamento no razão (ledger).

Este guia acompanha cada categoria de transação de saldo da Stripe até ao respetivo destino contabilístico: contas a receber, proveitos de comissões, responsabilidades perante vendedores, gastos com processamento e contas transitórias (suspense). Utiliza os endpoints documentados de importação e liquidação da Nordlet como mecanismo de lançamento, inclui um exemplo prático de liquidação e termina com uma lista de verificação de reconciliação que pode executar antes de cada fecho.

Identifique o modelo de cobrança do Connect antes de desenhar o processo

Não é possível definir regras contabilísticas sem saber que modelo de cobrança cada fluxo de pagamentos utiliza. O modelo determina em que saldo da Stripe a cobrança é criada, quem suporta as comissões e onde os reembolsos e litígios incidem primeiro.

Modelo do Connect	Cobrança criada em	Suporta as comissões da Stripe	Reembolsos/litígios reduzem	Consequência contabilística
Cobranças diretas (Direct charges)	Conta associada (Connected account)	Configurável por parte	O saldo da conta associada	A plataforma regista a respetiva comissão de aplicação como proveito; a atividade de pagamento do vendedor reside maioritariamente no razão da conta associada
Cobranças de destino (Destination charges)	Plataforma, com transferência imediata para uma conta associada	Plataforma	Plataforma	A plataforma regista a conta a receber do cliente e a comissão da Stripe; a quota-parte do vendedor é uma conta a pagar, não um proveito
Cobranças e transferências separadas (Separate charges and transfers)	Cobrança na plataforma, seguida de uma ou mais transferências separadas	Plataforma	Plataforma	A cobrança e as transferências para o vendedor são eventos distintos; a responsabilidade perante o vendedor é acompanhada de forma independente da cobrança ao cliente

As orientações da própria Stripe sobre como funcionam as cobranças numa integração do Connect confirmam que, nas cobranças de destino e nas cobranças e transferências separadas, o saldo da plataforma suporta as comissões de pagamento, os reembolsos e as reversões de cobrança (chargebacks). No caso das cobranças diretas, a conta associada recebe a cobrança e as comissões podem ser debitadas a qualquer uma das partes.

A regra prática: não assuma que "a transferência da Stripe é receita do vendedor" ou que "o vendedor paga as comissões" sem antes registar o modelo de cobrança de cada fluxo. Guarde esse modelo juntamente com cada transação. Misturar cobranças diretas e de destino sob uma única regra de lançamento é a forma mais rápida de empolar incorretamente tanto os proveitos como as responsabilidades.

Este guia assume cobranças de destino ou cobranças e transferências separadas, uma vez que é nesses casos que o saldo da plataforma assume o peso contabilístico e onde a maioria dos razões de marketplace é construída.

Mapeie o fluxo de fundos antes de importar uma única linha

Antes de efetuar qualquer importação, desenhe um mapa de transações de uma página para cada fluxo:

Pagamento do cliente
  -> Transação de saldo de cobrança / pagamento da Stripe
  -> Comissão da Stripe
  -> Comissão de aplicação da plataforma (comissão)
  -> Transferência para a conta associada
  -> Reembolso ou litígio (se aplicável)
  -> Transferência (payout) da Stripe
  -> Recebimento bancário

Cada seta é uma transação de saldo distinta com o seu próprio ID, categoria, montante e datas. Trate o saldo da Stripe como uma conta de compensação do tipo bancário: as cobranças entram, as comissões e transferências saem, e o payout transfere o remanescente para o banco real. A documentação de importações bancárias e de pagamentos da Nordlet recomenda exatamente este tratamento para a atividade comum da Stripe.

Escolha o relatório de origem correto da Stripe

Para lotes de liquidação de transferências automáticas, utilize o relatório Reconciliação de transferências, detalhado (Payout reconciliation, itemized) da Stripe. Fornece uma linha por transação de saldo, agrupa as linhas por reporting_category, associa cada uma a um automatic_payout_id e disponibiliza os totais brutos, de comissões e líquidos. O guia de seleção de relatórios da Stripe documenta este relatório e confirma charge_id, connected_account_id e destination_payment_id como campos disponíveis no Connect.

Caso as transferências automáticas não estejam ativadas (em determinados acordos de transferência manual), utilize o relatório de Saldo (Balance) em alternativa. Não considere um resumo de transferências do Dashboard como prova suficiente para efeitos de lançamento. O resumo comprova o total do lote; apenas o relatório detalhado explica os componentes.

A Stripe recomenda a classificação por reporting_category em detrimento do campo mais antigo type, sendo que cada linha transporta um ID de source que se liga ao objeto subjacente. Tenha em atenção a restrição temporal: a Stripe refere que os dados dos relatórios diários ficam normalmente disponíveis até ao meio-dia do dia seguinte e as transferências instantâneas não podem ser atribuídas de forma limpa a transações individuais, pelo que exigem uma reconciliação do histórico de transações em separado.

Classifique cada transação de saldo por categoria

Utilize reporting_category como o classificador principal e, em seguida, inspecione source_id, charge_id e as descrições. O mapeamento relevante é o seguinte:

Atividade da Stripe	Categoria de relatório (reporting_category)	Interpretação contabilística
Cobrança de cliente, cartão ou método de pagamento local	charge	Conta a receber financiada pelo cliente ou liquidação de venda
Reembolso	refund	Anulação do pagamento original do cliente
Comissão de processamento retida pela Stripe	fee	Gasto com o processamento de pagamentos
Comissão de aplicação da plataforma	platform_earning	Proveito de comissões
Comissão de aplicação reembolsada	platform_earning_refund	Redução dos proveitos de comissões
Transferência para conta associada	transfer	Redução da responsabilidade perante o vendedor
Transferência revertida	transfer_reversal	Recuperação junto da conta associada
Reversão de cobrança (Chargeback)	dispute	Perda por chargeback; inspecione o objeto de litígio de origem
Chargeback ganho ou revertido	dispute_reversal	Recuperação de um chargeback anteriormente contabilizado
Transferência para o banco (Payout)	payout	Movimento bancário, não um proveito
Transferência revertida (Payout reversal)	payout_reversal	Retorno de fundos ao saldo da Stripe
Reserva retida	connect_reserved_funds / risk_reserved_funds	Fundos restritos, não constituindo um gasto por predefinição
Cobrança de saldo negativo de longa data	connect_collection_transfer	Evento de financiamento ou recuperação que requer uma política de risco

Uma nota de cautela em termos de terminologia: o campo de tipo de transação de saldo mais antigo (type) utiliza rótulos diferentes para os mesmos eventos, entre os quais payment, application_fee e adjustment. A documentação de tipos de transações de saldo da Stripe enumera ambos os vocabulários. Não misture um valor de type numa regra baseada em reporting_category, nem crie categorias como dispute_loss que a Stripe não exporta. Se uma exportação contiver um rótulo que não reconhece, preserve o valor exportado e verifique-o face ao objeto de origem.

Lance a atividade normal de marketplace no razão

Para uma plataforma sujeita a cobranças de destino ou a cobranças e transferências separadas, os lançamentos conceptuais são os seguintes.

Cobrança de cliente (o dinheiro do cliente entra no saldo de compensação da Stripe):

Débito: Conta de compensação da Stripe    Cobrança bruta do cliente
    Crédito: Clientes (Contas a receber)    Cobrança bruta do cliente

Comissão de processamento da Stripe:

Débito: Gastos com comissões da Stripe     Comissão da Stripe
    Crédito: Conta de compensação Stripe   Comissão da Stripe

Não efetue a compensação líquida da comissão da Stripe face aos proveitos, a menos que a sua política contabilística exija e suporte expressamente a apresentação por valores líquidos.

Comissão da plataforma (o seu proveito, deduzido daquilo que seria de outro modo devido ao vendedor):

Débito: Contas a pagar a vendedores       Montante da comissão
    Crédito: Proveitos de comissões        Montante da comissão

Transferência para o vendedor (liquidação de fundos devidos, não constituindo um gasto):

Débito: Contas a pagar a vendedores       Montante da transferência
    Crédito: Conta de compensação Stripe   Montante da transferência

Uma transferência nunca constitui automaticamente um gasto. A quota-parte do vendedor torna-se uma responsabilidade no momento em que a cobrança se concretiza, e a transferência extingue essa responsabilidade. As regras de lançamento de liquidações da Nordlet seguem este princípio: as linhas platform_earning são lançadas em proveitos de comissões, enquanto as linhas transfer reduzem a responsabilidade perante o vendedor. As chaves de lançamento predefinidas documentadas são settlements.commissionRevenue (predefinição 5001), settlements.sellerPayable (predefinição 4499), settlements.fees (predefinição 6800) e settlements.suspense (predefinição 4440), sendo cada uma delas passível de substituição por empresa através das regras de lançamento na API da Nordlet.

Trate os reembolsos face à venda original, e não como itens bancários avulsos

Um reembolso está associado à cobrança ou fatura original. Conceitualmente:

Débito: Reembolsos / anulações de vendas   Montante do reembolso
    Crédito: Clientes (Contas a receber)   Montante do reembolso

O lançamento real depende de ter sido reconhecido o proveito, de o IVA ter de ser anulado e de ter sido reembolsada a comissão de aplicação da plataforma. Um único reembolso pode gerar uma anulação de conta a receber, uma anulação de imposto, um reembolso de comissão de aplicação, uma reversão de transferência ou redução da conta a pagar ao vendedor, bem como um impacto de comissão da Stripe que deve ser validado em vez de assumido.

A armadilha temporal: um reembolso é frequentemente liquidado numa transferência posterior à da cobrança original. Dê preferência ao relatório detalhado de reconciliação de transferências em detrimento de um reembolso sintetizado a partir de uma exportação ao nível da cobrança. A documentação da Nordlet adverte expressamente que um reembolso sintetizado a partir de uma exportação de Pagamentos constitui apenas uma aproximação quando o reembolso é liquidado mais tarde. O importador de liquidações consegue ingerir a linha de reembolso, associá-la à venda original e anular a conta a receber quando o lote for lançado.

Trate os litígios de forma separada dos reembolsos

Um litígio é uma reclamação apresentada pelo titular do cartão ou pelo banco emissor, sendo que a Stripe pode debitar tanto o montante contestado como uma comissão de litígio antes da resolução. No caso de cobranças de destino e de cobranças e transferências separadas, a Stripe debita ambos ao saldo da plataforma, de acordo com as respetivas orientações sobre reembolsos e litígios. A plataforma pode tentar a recuperação mediante a reversão da transferência para o vendedor.

Um litígio perdido, na perspetiva da plataforma:

Débito: Perdas por chargeback / conta a receber reaberta   Montante contestado
Débito: Gastos com comissões de litígio                    Comissão de litígio
    Crédito: Conta de compensação Stripe                   Montante combinado

Caso o vendedor suporte a perda e a recuperação esteja confirmada:

Débito: Contas a pagar a vendedores / conta de recuperação  Montante recuperável
    Crédito: Recuperação de chargebacks                     Montante recuperável

Não contabilize a recuperação junto do vendedor apenas por ter sido solicitada uma reversão de transferência. Certifique-se de que a reversão foi criada, executada com sucesso e que aparece refletida no saldo da Stripe. Se o litígio for ganho, a Stripe devolve o montante contestado através de uma linha dispute_reversal; anule a perda por chargeback e trate em separado qualquer comissão de litígio que a Stripe não devolva. A Nordlet efetua a correspondência das linhas de chargeback utilizando o charge_id de uma cobrança anteriormente associada, seja a partir do mesmo ficheiro ou de uma importação anterior.

Um exemplo prático de liquidação

Considere um lote de transferência automática. O relatório detalhado contém:

• Uma linha de charge: valor bruto 100,00, comissão da Stripe 3,20, líquido 96,80
• Uma linha de platform_earning: 15,00, correspondente à comissão da plataforma
• Uma linha de transfer: 81,80 para o vendedor associado
• Uma linha de refund relativa a uma venda anterior: valor bruto 20,00, liquidada neste lote
• Uma linha de payout: o total do lote transferido para o banco

A composição da transferência, seguindo a identidade de liquidação da Stripe:

Cobranças brutas               100,00
- reembolsos                    20,00
- comissões da Stripe            3,20
- transferências                81,80
= líquido para o saldo da plat. -5,00

A linha platform_earning não movimenta dinheiro uma segunda vez. Identifica os 15,00 que permanecem no saldo da plataforma após a extração da comissão e da transferência para o vendedor, permitindo assim que a plataforma reconheça proveitos de comissões em vez de os inferir.

Neste caso, a transferência para o vendedor somada ao reembolso excede a atividade líquida de cobranças, pelo que o lote apresenta um saldo líquido ligeiramente negativo, reduzindo a transferência seguinte ou recorrendo ao saldo. O diário lançado anula a conta a receber reembolsada, reconhece 15,00 de proveitos de comissões, regista 3,20 de gastos com comissões, reduz a conta a pagar ao vendedor pelo montante da transferência e contabiliza a anulação do reembolso. A linha bancária corresponde ao montante líquido que entra na conta. Nenhum valor isolado equivale à "receita", e esse é precisamente o objetivo.

Importar e lançar através do endpoint de liquidações da Nordlet

Para a reconciliação ao nível das transferências, utilize:

POST /v1/bank/settlements/import

fornecendo o fornecedor Stripe e o ficheiro CSV detalhado. A Nordlet agrupa as linhas por automatic_payout_id, converte cada transferência num lote de liquidação com totais brutos, de comissões e líquidos, ignora reimportações de uma transferência já lançada, ignora as linhas payout da composição da liquidação e efetua a correspondência automática de linhas de cobrança, reembolso e litígio recorrendo a referências de encomendas, faturas, PaymentIntent, cobrança, origem ou metadados. A Stripe divide o relatório detalhado num ficheiro por secção, pelo que deve importar em conjunto os ficheiros de cobranças, reembolsos e comissões: as linhas pertencentes a uma transferência que já foi importada mas ainda não foi lançada são agregadas ao lote existente. Trata-se de um fluxo de trabalho de importação e lançamento impulsionado por ficheiros e endpoints de liquidação, e não de um conector Stripe em tempo real; a página de funcionalidades enumera os aspetos cobertos pela vertente bancária e de liquidações.

Faça a correspondência pela seguinte ordem: cobranças a faturas, reembolsos a cobranças originais, litígios a cobranças originais, linhas de comissão ao tratamento de comissões. Mantenha as comissões da Stripe, ajustamentos, reservas e linhas de transferência fora da correspondência de faturas. O glossário de reconciliação de pagamentos da Nordlet indica que as linhas de comissões e ajustamentos não são passíveis de correspondência com faturas por conceção; encaminhe os itens monetários não resolvidos para contas transitórias (suspense). A correção manual é efetuada através de bank/settlements/match { lineId, invoiceId }, utilizando um invoiceId com valor null para anular a correspondência.

Em seguida, lance um único lote equilibrado:

POST /v1/bank/settlements/post

Este procedimento cria um diário equilibrado, liquida as faturas correspondidas, debita a conta do razão da conta bancária pelo montante líquido da transferência, debita as comissões, credita as contas a receber pelas cobranças, anula as contas a receber relativas a reembolsos e chargebacks, divide as cobranças de marketplace sem correspondência entre proveitos de comissões e contas a pagar a vendedores quando é fornecido o parâmetro commissionPercent, e envia os montantes não resolvidos para contas transitórias. Qualquer categoria que o sistema não reconheça é igualmente encaminhada para a conta transitória, sendo que a resposta enumera essas categorias num aviso em vez de as absorver silenciosamente.

Lista de verificação de reconciliação

Execute estas asserções antes de cada fecho:

• Ausência de balance_transaction_id duplicados
• Ausência de lotes de liquidação (provider, payout_id) duplicados
• A soma do valor net das linhas é igual ao valor líquido do lote
• O valor líquido do lote é igual à transferência bancária, salvaguardando a política de prazos e de moeda
• Cada reembolso possui uma cobrança original ou uma exceção registada
• Cada litígio possui uma referência de litígio ou de cobrança
• Cada transferência possui um ID de conta associada
• Cada linha platform_earning possui um tratamento de comissões definido
• A conta transitória (suspense) apresenta saldo zero ou foi totalmente revista, incluindo quaisquer categorias não reconhecidas indicadas no aviso de lançamento
• A conta a pagar a vendedores não apresenta saldo negativo, exceto se existir uma política aprovada de adiantamento ou recuperação
• Os lotes lançados não podem ser reimportados ou relançados silenciosamente
• Uma transferência numa moeda diferente da moeda base da empresa é convertida à taxa da data da transferência, sendo a diferença face à taxa própria de cada fatura contabilizada como um ganho ou perda de câmbio realizado; uma transferência que misture moedas é rejeitada no momento da importação

Reconcilie a três níveis: linha (cada transação possui um ID, categoria, montante, moeda e origem preservados), transferência (os valores líquidos detalhados coincidem com a transferência da Stripe e o recebimento bancário) e razão (o diário lançado equilibra-se e produz as posições pretendidas de proveitos, comissões, contas a receber, responsabilidades perante vendedores e contas transitórias). No que respeita especificamente aos saldos dos vendedores, certifique-se de que o saldo inicial a pagar a vendedores, somado à nova quota-parte do vendedor, deduzido das transferências e reversões válidas, é igual ao saldo final a pagar a vendedores.

A falha recorrente em qualquer razão de marketplace é a mesma que esteve na origem: comprimir uma transferência estruturada num único número. Mantenha os componentes separados, ancore cada um a um identificador estável da Stripe e utilize a conta transitória para reter tudo o que ainda não consegue explicar. Um fecho limpo é aquilo em que um auditor confiará.

FAQ

A transferência da Stripe é a receita da plataforma?

Não. A transferência é o montante líquido resultante de cobranças, reembolsos, comissões de processamento, transferências para vendedores, litígios e ajustamentos que coincidiram no mesmo lote. Registá-la como uma única linha de proveitos elimina a responsabilidade perante o vendedor e os gastos com o processamento nela contidos. No caso de um marketplace de mediação, a receita corresponde à comissão, que é identificada pelas linhas platform_earning.

Contra que relatório da Stripe devo efetuar a reconciliação?

Contra o relatório de Reconciliação de transferências, detalhado (Payout reconciliation, itemized), uma vez que fornece uma linha por transação de saldo com uma reporting_category, um automatic_payout_id e os montantes brutos, de comissões e líquidos. Um resumo de transferências do Dashboard comprova apenas o total do lote. Caso as transferências automáticas não estejam ativadas, utilize o relatório de Saldo (Balance) em alternativa.

Uma transferência para um vendedor deve ser contabilizada como um gasto?

Não. A quota-parte do vendedor transforma-se numa responsabilidade no momento em que a cobrança do cliente se concretiza, e a transferência extingue essa responsabilidade. Contabilizar as transferências como gastos duplica o registo de custos e deixa a conta a pagar ao vendedor permanentemente empolada.

O que acontece a uma linha da Stripe cuja categoria não é reconhecida pelo importador?

É lançada na conta transitória de liquidação (suspense, predefinição 4440), e a resposta ao lançamento devolve um aviso que enumera as categorias que aí foram alojadas. As reservas e os ajustamentos atípicos terminam habitualmente desta forma, o que é deliberado: o dinheiro permanece visível e o diário mantém-se equilibrado até que alguém decida a que conta pertence.

Como são tratados os reembolsos que são liquidados numa transferência posterior?

Chegam sob a forma de uma linha refund no relatório detalhado da transferência posterior e são associados à cobrança original através do charge_id da cobrança correspondida anteriormente. Um reembolso sintetizado a partir de uma exportação de Pagamentos ao nível da cobrança constitui apenas uma aproximação nestes casos, pelo que o relatório detalhado é a fonte mais segura.

Leitura complementar

• Importações bancárias e de pagamentos, incluindo a reconciliação de liquidações da Stripe
• Reconciliação de pagamentos: correspondência entre transferências de PSP e o razão
• Subrazões de vendedores de marketplace: proveitos vs. contas a pagar
• Como funcionam as cobranças numa integração do Connect (Stripe)