O que você vai aprender: Como um pedido percorre o caminho da autorização até a captura, liquidação e depósito, com cada dedução identificada, e por que os valores autorizado, liquidado e depositado são sempre números diferentes: na maioria das vezes por razões esperadas, e ocasionalmente porque algo deu errado.
A suposição comum é que a reconciliação é uma formalidade contábil: combinar o depósito com a nota fiscal e seguir em frente. Essa suposição funciona no fluxo padrão. Ela falha no momento em que você encontra uma captura parcial, um reembolso dividido, uma liquidação em moeda estrangeira ou um chargeback que chega três semanas após a liquidação da transação original. Essas exceções não são casos raros. Elas são a realidade operacional normal de qualquer merchant que processa volume em escala com múltiplos provedores. A tese aqui é direta: a reconciliação falha nas exceções, não no fluxo padrão. Construa sua lógica de conciliação em torno delas primeiro, e o restante se resolve facilmente.
Principais conclusões
- Autorização, captura, liquidação e depósito são quatro eventos distintos que produzem valores diferentes por design.
- Tarifas, reembolsos, chargebacks, reservas rotativas e conversão cambial reduzem o depósito abaixo do valor autorizado de formas previsíveis.
- Capturas parciais e reembolsos divididos criam relacionamentos de um para muitos entre pedidos e registros de liquidação, o que quebra a lógica de conciliação simples.
- Chargebacks aparecem em um feed de dados separado da liquidação, muitas vezes semanas depois, e devem ser conciliados de forma independente.
- Operar com múltiplos PSPs multiplica cada exceção: cada provedor tem seu próprio cronograma de tarifas, ciclo de liquidação e formato de relatório.
Os quatro eventos pelos quais todo pagamento passa
Autorização, captura, liquidação e depósito são etapas distintas, não sinônimos. Confundi-las é a principal causa da confusão na reconciliação.
De acordo com o Guia de Integração da Mastercard, a autorização reserva o valor total do pedido sem debitar a conta do cliente. A captura é a ação separada que debita o cartão e transfere os fundos para a conta do merchant. A autorização é uma reserva. A captura é o débito efetivo.
A liquidação vem após a captura. O adquirente liquida suas transações capturadas descontando tarifas, reembolsos e chargebacks e, em seguida, agenda uma transferência. A transferência para sua conta bancária é o depósito. Esses quatro eventos podem ocorrer em horas, dias ou semanas, dependendo do provedor, do método de pagamento e do corredor de moedas.
Por que a diferença entre autorização e captura importa
Muitos merchants autorizam no momento da compra e capturam depois, quando os produtos são enviados. Se o valor capturado diferir do valor autorizado, por exemplo, porque um item estava fora de estoque, a liquidação reflete o valor de captura menor.
Suponha que o registro de autorização mostre EUR 1.000 e o relatório de liquidação mostre um valor capturado menor. Ambos estão corretos. Nenhum é um erro. Um sistema de reconciliação que compara autorização e depósito diretamente sinalizará isso como discrepância toda vez. A captura parcial é a primeira exceção a ser contemplada. Ela é comum no varejo, em viagens e em negócios de assinatura, onde o valor final do pedido é confirmado após a autorização inicial.
Do bruto ao líquido: rastreando cada dedução
O depósito é o valor autorizado menos todas as deduções aplicadas entre a captura e a transferência bancária. Existem cinco categorias de dedução, e cada uma deve ser rastreada separadamente.
As cinco categorias de dedução são:
- Tarifas do provedor: intercâmbio, taxas de bandeira e tarifas de processamento do adquirente, deduzidas na liquidação
- Reembolsos: totais ou parciais, reduzindo a liquidação líquida do período em que são processados
- Chargebacks: disputas iniciadas pelo titular do cartão, mais uma tarifa de disputa do adquirente, que aparecem em um relatório separado
- Reservas rotativas: um percentual do volume bruto retido pelo adquirente como proteção contra riscos, liberado em um cronograma diferido
- Conversão cambial: a diferença entre a taxa de câmbio no momento da autorização e a taxa aplicada na liquidação
Exemplo prático: um pedido de EUR 1.000, totalmente rastreado
Esta empresa é hipotética. Todas as premissas estão declaradas abaixo. O objetivo é mostrar cada dedução em sequência para que o cálculo possa ser reproduzido em um quadro branco.
Premissas: valor bruto autorizado EUR 1.000; tarifa de intercâmbio de 1,5% sobre o bruto; taxa de bandeira de 0,3% sobre o bruto; tarifa de processamento do adquirente de 0,4% sobre o bruto; um reembolso parcial de EUR 120 (um item devolvido); um chargeback de EUR 200 com uma tarifa de disputa de EUR 25; reserva rotativa de 10% sobre o bruto; taxa EUR/USD na autorização: 1,085; taxa EUR/USD na liquidação: 1,078.
A Documentação da API Mastercard confirma que reembolsos podem ser parciais e estão vinculados ao pedido original pelo orderId, com o valor específico a reembolsar declarado. O Guia de Integração da Mastercard confirma que a captura é o que efetivamente debita o cartão e transfere os fundos. Esses dois fatos fundamentam a sequência de deduções abaixo.
Passo um: aplicar as tarifas do provedor sobre o valor bruto capturado.
- Intercâmbio: EUR 1.000 × 1,5% = EUR 15,00
- Taxa de bandeira: EUR 1.000 × 0,3% = EUR 3,00
- Processamento do adquirente: EUR 1.000 × 0,4% = EUR 4,00
- Total de tarifas: EUR 22,00
- Após tarifas: EUR 1.000 − EUR 22,00 = EUR 978,00
Passo dois: deduzir o reembolso parcial. De acordo com a Documentação da API Mastercard, um reembolso está vinculado ao pedido original pelo orderId e pode ser de qualquer valor parcial. EUR 978,00 − EUR 120,00 = EUR 858,00.
Passo três: deduzir o chargeback e sua tarifa de disputa. O chargeback de EUR 200 chega em um relatório de disputas separado, não no arquivo de liquidação padrão. O adquirente também cobra EUR 25 como tarifa de processamento da disputa. EUR 858,00 − EUR 200,00 − EUR 25,00 = EUR 633,00.
Passo quatro: aplicar a reserva rotativa. O adquirente retém 10% do bruto: EUR 1.000 × 10% = EUR 100,00. EUR 633,00 − EUR 100,00 = EUR 533,00.
Passo cinco: aplicar a conversão cambial. A autorização foi registrada a EUR/USD 1,085. Na liquidação, a taxa havia mudado para 1,078. O depósito em USD é EUR 533,00 × 1,078 = USD 574,57. Se a taxa de autorização tivesse se mantido, o depósito seria EUR 533,00 × 1,085 = USD 578,31. A diferença cambial é USD 3,73. Isso não é um erro. É uma exposição conhecida que deve ser registrada por transação.
Resumo: um pedido autorizado em EUR 1.000 gera um depósito em USD de aproximadamente USD 574,57. A diferença é totalmente explicada por cinco deduções aplicadas em sequência. Nenhuma delas é um erro. Todas devem constar em sua lógica de reconciliação, caso contrário a diferença parecerá uma discrepância.
Onde a reconciliação realmente falha
O fluxo padrão se reconcilia sozinho. Uma captura total, sem reembolso, na mesma moeda, sem chargeback: o depósito é o valor bruto menos um cronograma fixo de tarifas, e qualquer ferramenta de conciliação resolve isso em segundos.
As falhas se acumulam nas exceções. Veja onde concentrar seus testes:
Capturas parciais
Uma única autorização pode gerar múltiplos registros de captura se o pedido for cumprido em etapas. Cada captura é liquidada separadamente.
Seu registro de pedidos mostra um ID de autorização. Seu relatório de liquidação mostra dois ou três registros de captura. Uma conciliação simples de um para um marcará todos os três como não conciliados. A solução é agrupar as capturas pelo referência de autorização original antes de fazer a conciliação.
Reembolsos divididos
A Documentação da API Mastercard confirma que um reembolso está vinculado ao pedido original pelo orderId, e o valor pode ser qualquer valor parcial. Um cliente que devolve dois itens em remessas separadas gera dois registros de reembolso vinculados a um único ID de pedido.
Ambos reduzem a liquidação do período em que são processados, o que pode ocorrer em ciclos de liquidação diferentes. Sua lógica de conciliação deve somar todos os reembolsos em relação ao pedido original antes de comparar com o depósito.
Chargebacks entre provedores
Quando um merchant opera com múltiplos PSPs, um chargeback pode chegar por um canal de relatório diferente do da liquidação original. O PSP A liquidou a transação. O PSP B processa a disputa.
O débito do chargeback aparece no relatório do PSP B sem nenhum link direto com o registro de liquidação do PSP A. Sem um identificador de pedido normalizado que abranja ambos os provedores, essa discrepância é quase impossível de conciliar automaticamente. Esta é a fonte mais comum de itens não conciliados em ambientes com múltiplos PSPs, e ela se agrava em escala. Para mais informações sobre esse problema específico, veja como plataformas SaaS enterprise devem pensar na reconciliação de pagamentos ao operar com múltiplos PSPs.
Incompatibilidades de timing cambial
Cada transação em moeda estrangeira carrega uma taxa na autorização e uma taxa diferente na liquidação. A diferença é esperada, mas deve ser rastreada por transação.
Merchants que processam volume em múltiplas moedas podem acumular diferenças cambiais em centenas de transações por ciclo de liquidação. Sem registros de câmbio por transação, a diferença agregada parecerá um erro do provedor. Não é.
Liberações de reserva rotativa
As reservas retidas em um período são liberadas em um cronograma diferido em um período posterior. O depósito do mês quatro inclui tanto a liquidação líquida do período atual quanto uma liberação de reserva do mês um.
Se o modelo de reconciliação não contabilizar os movimentos de reserva separadamente, o depósito nunca vai coincidir com o relatório de liquidação do período. Construa um registro de reservas junto com seu registro principal de reconciliação.
Conciliando relatórios de três provedores com um registro de pedidos
A reconciliação com múltiplos PSPs exige uma camada normalizada entre os relatórios dos provedores e o registro de pedidos. Cada PSP entrega dados em seu próprio formato, em seu próprio ciclo, com suas próprias convenções de nomenclatura de tarifas.
A abordagem prática é normalizar todos os relatórios de provedores em um esquema comum antes de tentar qualquer conciliação. O esquema comum precisa ter no mínimo: um ID de pedido canônico, um ID de transação do provedor, um valor bruto, uma moeda, uma data de liquidação, um detalhamento itemizado de tarifas, um indicador e valor de reembolso, e um indicador e valor de chargeback. Uma vez normalizado, a conciliação é executada em relação ao registro de pedidos pelo ID de pedido canônico.
A tabela abaixo resume quais diferenças entre os valores autorizado, liquidado e depositado são esperadas versus quais sinalizam um possível erro.
| Diferença observada | Esperado ou erro | O que verificar |
|---|---|---|
| Depósito abaixo da autorização pelo percentual de tarifa | Esperado | Confirmar se o cronograma de tarifas corresponde ao contrato |
| Liquidação abaixo da captura por reembolso parcial | Esperado | Vincular registros de reembolso ao orderId original |
| Depósito abaixo da liquidação pelo valor do chargeback | Esperado | Vincular relatório de chargeback à transação original |
| Depósito reduzido por reserva rotativa | Esperado | Verificar se a taxa de reserva corresponde ao contrato; acompanhar cronograma de liberação |
| Diferença cambial entre autorização e depósito | Esperado | Registrar a taxa em ambos os eventos; sinalizar se a diferença exceder a tolerância |
| Registro de liquidação sem ID de pedido correspondente | Erro | Investigar relatório do provedor para transação duplicada ou fantasma |
| Valor de tarifa excede a taxa contratada | Erro | Acionar o provedor; solicitar nota de crédito |
| Chargeback em uma transação já reembolsada | Erro ou fraude | Apresentar contestação; alertar a equipe de fraude |
Onde o Yuno se encaixa
O módulo de Reconciliações do Yuno normaliza os dados de liquidação de todos os provedores conectados em um único registro, automaticamente. Esse é o problema estrutural que ele resolve: cada provedor tem seu próprio formato de relatório, ciclo de liquidação e estrutura de tarifas, e a área financeira não deveria precisar fazer essa fusão manualmente.
O Yuno é o sistema de inteligência nativo em IA para pagamentos globais e serviços financeiros. Ele processou mais de um bilhão de pagamentos em mais de 150 moedas desde janeiro de 2025. Como o Yuno fica fora do fluxo de fundos e não movimenta o dinheiro, os dados de reconciliação que ele apresenta são uma leitura neutra do que cada provedor conectado reporta, sem incentivo para favorecer os números de um provedor em detrimento de outro.
Heads of payments em empresas como Rappi e inDrive operam em muitos mercados com muitos provedores locais. O desafio de reconciliação nesses ambientes escala diretamente com o número de provedores e moedas. Um registro normalizado e independente de provedor é a única resposta prática. Para uma análise mais profunda sobre o que automatizar primeiro, veja software de reconciliação de pagamentos para empresas com vários PSPs: o que automatizar primeiro.
A questão de qual plataforma de pagamentos melhor unifica configurações com múltiplos PSPs em um único dashboard financeiro se resume a uma capacidade: a plataforma normaliza os relatórios dos provedores no nível de transação antes da conciliação, ou deixa isso para a área financeira? A normalização é o trabalho. O dashboard é apenas o resultado.
Reconciliação não é um problema de relatórios. É um problema de qualidade de dados que aparece nos relatórios. Os merchants que resolvem isso primeiro constroem sua lógica de conciliação em torno das exceções: capturas parciais, reembolsos divididos, chargebacks em múltiplas moedas e liberações de reserva rotativa. Teste esses cenários antes de testar o fluxo padrão. O fluxo padrão nunca foi o problema.
