O que é a reconciliação de pagamentos? Como associar transferências de PSP ao razão

A reconciliação de pagamentos consiste em comparar o valor efetivamente pago por um prestador de serviços de pagamento (PSP) com o montante devido pelos seus clientes. Trata-se de um processo diferente da reconciliação bancária e mais complexo, uma vez que uma transferência de um PSP nunca corresponde a um único pagamento para uma única fatura.

O sintoma típico: vendeu 10.000,00 € e chegaram ao banco 9.712,40 €. Ambos os valores estão certos. O que acontece pelo meio é exatamente o que esta reconciliação explica.

Porque é que a transferência nunca coincide com as vendas

Uma única transferência da Stripe, Adyen ou PayPal constitui um lote líquido (net batch). Entre o momento em que o cliente paga e o dinheiro chega à conta, o PSP:

• agregou vários cobranças ao longo de um período de liquidação,
• deduziu as respetivas comissões por transação,
• deduziu os reembolsos e reversões ocorridos no mesmo período,
• reteve eventualmente uma reserva,
• e pagou o remanescente dias mais tarde, numa única transferência.

Deste modo, o extrato bancário apresenta uma única linha - 9.712,40 € - ao passo que o razão regista dezenas de faturas, nenhuma das quais coincide com esse valor. Associar diretamente a transferência às faturas é impossível; primeiro, a transferência tem de ser decomposta.

A decomposição

Um lote de liquidação divide-se em várias categorias e cada categoria tem um significado contabilístico próprio no razão:

Categoria	O que é	Efeito no razão
Cobranças (Charges)	Pagamentos de clientes	Liquida saldos a receber
Reembolsos (Refunds)	Dinheiro devolvido a clientes	Anula um saldo a receber previamente liquidado
Comissões (Fees)	Comissão do PSP	Um gasto
Reversões (Chargebacks)	Pagamentos contestados e retirados	Reabre um saldo a receber, acrescido de uma comissão
Ajustamentos / reservas	Retenções por motivos temporais ou de risco	Um saldo em dívida pelo PSP

A identidade matemática que tem de se verificar:

Cobranças brutas − reembolsos − comissões − reversões ± ajustamentos = Transferência líquida

Caso não se verifique, o lote foi importado de forma incompleta. Esta validação é mais importante do que qualquer correspondência individual, pois prova que nenhum valor foi omitido silenciosamente.

Os lançamentos

Para contabilizar um lote de liquidação com 10.000,00 € de cobranças brutas, 250,00 € de comissões e 37,60 € de reembolsos:

Conta	Débito	Crédito
2710 Banco	9.712,40
6800 Gastos financeiros (comissões PSP)	250,00
5000 Proveitos / anulação de saldos a receber (reembolsos)	37,60
2410 Clientes		10.000,00

A leitura correta é a seguinte: as dívidas dos clientes no valor de 10.000,00 € são regularizadas, o PSP reteve 250,00 €, 37.60 € foram devolvidos aos clientes e 9.712,40 € entraram no banco. A comissão constitui um gasto real que nunca consta em nenhuma fatura de cliente, razão pela qual o volume de negócios bruto e os depósitos bancários diferem, e o motivo pelo qual reconciliar apenas a linha do banco subestima silenciosamente tanto os proveitos como os custos.

No caso de plataformas de comércio eletrónico (marketplaces), existe um nível adicional. Se a transferência incluir fundos pertencentes a vendedores, os proveitos da plataforma resumem-se à respetiva comissão, sendo o restante considerado um passivo. As regras de lançamento da Nordlet gerem esta situação através de chaves dedicadas (settlements.fees, settlements.commissionRevenue, settlements.sellerPayable e settlements.suspense), permitindo que uma transferência repartida registe a comissão como proveito e a quota-parte do vendedor como passivo, em vez de inflacionar os proveitos da plataforma.

Como a Nordlet executa o processo

O fluxo compreende três endpoints:

1. Importar. POST /v1/bank/settlements/import lê o relatório de reconciliação de uma transferência da Stripe e cria um lote de liquidação (indicando o prestador, o ID da transferência, a moeda, o valor bruto, as comissões e o valor líquido), contendo uma linha por cada transação subjacente, cada uma com a respetiva categoria. Os lotes são únicos por prestador e ID de transferência, pelo que reimportar o mesmo relatório nunca resulta numa duplicação.
2. Associar (Match). POST /v1/bank/settlements/match associa as linhas de cobrança e reembolso às respetivas faturas de venda. As linhas apresentam um estado de correspondência (unmatched, matched, resolvido automaticamente através da referência da encomenda ou fatura no relatório, ou manual, definido por intervenção humana). Por definição, as linhas de comissão e ajustamento não admitem associação a faturas, pelo que qualquer tentativa nesse sentido é rejeitada em vez de ser estimada.
3. Contabilizar (Post). POST /v1/bank/settlements/post gera os lançamentos no razão para a totalidade do lote através das regras de lançamento mencionadas anteriormente, alterando o estado do lote de imported para posted. Os recebimentos não associados são alocados a uma conta de pendentes em vez de serem forçados numa fatura, mantendo-se visíveis e intencionalmente pendentes até serem resolvidos.

Uma transferência numa moeda diferente da moeda funcional da empresa é processada sem necessidade de intervenção manual. O diário é escriturado na moeda funcional: o lote é convertido à taxa de câmbio da data do lançamento, os saldos a receber são baixados à taxa de câmbio aplicável à data de emissão de cada fatura, e a diferença cambial resultante é registada como proveito ou custo financeiro realizado. A única situação que continua a ser rejeitada é a de uma transferência cujas linhas combinem várias moedas.

O lote contabilizado fica associado à respetiva linha do extrato bancário na conta bancária real. Na secção Banco → Regras de correspondência (Match rules), define-se o aspeto de uma transferência no extrato: o texto que a linha inclui obrigatoriamente e, opcionalmente, o prefixo do ID da transferência contido na mesma. Quando se importa um extrato, uma linha que obedeça a uma regra é associada ao respetivo lote através do ID da transferência, ou mediante a correspondência com o total líquido do lote dentro de um intervalo de datas configurado. Desse modo, a linha bancária passa a conter o lançamento de diário da liquidação sem aguardar por um segundo lançamento duplicado, permitindo que os endpoints POST /v1/bank/settlements/link e /unlink definam ou corrijam a associação manualmente.

Boas práticas

• Reconcilie por transferência e não por mês. A transferência constitui a unidade natural; agregar um mês de transferências antes de proceder à reconciliação destrói a identidade de controlo que facilita a deteção de erros.
• Nunca contabilize o valor líquido como proveito. Este é o erro mais frequente na contabilidade de plataformas: registar 9.712,40 € de proveitos subestima as vendas e os gastos, distorce a margem bruta e, regra geral, subestima o IVA, uma vez que o imposto é devido sobre o valor bruto pago pelo cliente e não sobre o montante reencaminhado pelo PSP.
• Atente no desfasamento temporal. Um pagamento efetuado a 30 de junho e transferido a 3 de julho pertence aos proveitos de junho e à tesouraria de julho. No final do período, a diferença reflete-se num valor a receber do PSP, que corresponde a dinheiro real depositado noutra conta.
• Reconcilie os reembolsos com a venda original. Um reembolso que não seja associado à origem deixa uma fatura liquidada com aparência de paga e com os proveitos sobreavaliados.

FAQ

Qual é a diferença entre a reconciliação de pagamentos e a reconciliação bancária?

A reconciliação bancária compara o razão com o extrato bancário, linha a linha. A reconciliação de pagamentos situa-se um nível antes: decompõe uma única transferência de um PSP nas múltiplas cobranças, reembolsos e comissões subjacentes, permitindo assim explicar essas linhas bancárias.

Porque é que a minha transferência da Stripe não coincide com as minhas vendas?

Porque uma transferência constitui um lote líquido: cobranças brutas deduzidas de comissões, reembolsos, reversões e eventuais reservas, liquidadas de acordo com o calendário do PSP e não com o vencimento da fatura. Cada um destes componentes deve ser contabilizado separadamente para que ambos os valores coincidam.

As comissões dos PSP devem ser deduzidas dos proveitos?

Não. Os proveitos correspondem ao montante bruto pago pelo cliente, enquanto a comissão do PSP constitui um gasto associado à sua cobrança. Deduzir a comissão aos proveitos subestima simultaneamente os proveitos e os custos, distorce as margens e, por norma, resulta num tratamento incorreto do IVA.

Como são tratadas as repartições de pagamentos em marketplaces?

Os proveitos da plataforma correspondem apenas à sua comissão, ao passo que a quota-parte do vendedor representa um passivo até ser transferida. Contabilizar a transferência total como proveito sobreavalia excessivamente os rendimentos da plataforma, existindo regras de lançamento específicas para os proveitos de comissão e para o passivo perante os vendedores exatamente para os manter separados.

O que acontece às linhas de liquidação não associadas?

São lançadas numa conta de pendentes em vez de serem associadas forçadamente a uma fatura. Desta forma, o razão mantém-se equilibrado e o problema visível; o saldo de pendentes constitui uma lista de trabalho que deve estar zerada antes do encerramento do período.