--- id: financeiros/conciliacao-recebimentos industria: Serviços financeiros uso: comum esforco: médio grao: Recebimento liquidado x parcela ou contrato, com status; dia de liquidação para a cobertura --- # Conciliação de recebimentos Cada pagamento que o processador, o banco ou o gateway liquidou casado com a parcela baixada no core ou no ERP, com duplicidade, status divergente e dia faltando à vista antes do fechamento. ## Resumo executivo **Para quem:** Fintechs de crédito, cooperativas, plataformas de funding e BPO financeiro que recebem por processador, boleto ou gateway e precisam fechar o dia. **O que resolve** - Todo recebimento liquidado tem par no core ou no ERP, ou aparece numa lista com o motivo. - Pagamento cobrado duas vezes e status que o sistema gravou errado são achados no dia, não na reclamação do cliente. - Dia que faltou no relatório do processador dispara alerta antes de distorcer receita e custo. **Por que importa:** Em crédito, o dinheiro que entrou e não foi baixado deixa o contrato atrasado no core, alimenta a régua de cobrança e a PDD por engano. Pagamento duplicado vira estorno, chargeback e reclamação. E quando o relatório do processador chega sem um dia, receita e custo do mês ficam menores que a fatura sem ninguém perceber. **Perguntas de negócio que responde** - Quais recebimentos de ontem ainda não foram baixados no core ou no ERP? - Quantos clientes foram cobrados duas vezes nesta semana e quanto precisamos devolver? - Faltou algum dia no relatório do processador neste mês? - Os aportes e recompras deste mês batem entre os dois sistemas? - Quanto pagamos de tarifa ao processador por dia de liquidação? - Quais pagamentos o sistema marcou como sucesso e o processador recusou? **O que você precisa** - O relatório de liquidação do processador, do banco ou do gateway conectado na Nekt (arquivo, planilha ou API) - Pagamentos do core de crédito ou parcelas do ERP com as baixas - A tolerância de diferença e a chave de cruzamento combinadas com o financeiro **O que você recebe** - Uma tabela por recebimento com status de conciliação, os dois valores e a diferença - Listas diárias de não baixados, duplicados e status inconsistentes - Histórico de cobertura do relatório por dia de liquidação, com alerta - Um agente de IA que responde mostrando os dois lados ## Detalhado ### O problema O processador liquida por data de liquidação, o core registra por data de pagamento e o ERP baixa por conta financeira, cada um com seu identificador. Quem soma os três lados por mês acha uma diferença que ninguém explica. Quem cruza por valor sem travar o par casa a mesma linha duas vezes. E quando o arquivo de um dia não chega, ou duas plataformas de cobrança rodam em paralelo, o número parece certo e está errado. ### Regras de negócio 1. **A chave é o identificador da transação.** Cruze pelo id que existe nos dois lados: id da transação no processador, id do boleto na plataforma de cobrança, número do pedido no gateway. Quando o ERP não guarda esse id, faça em duas etapas: primeiro data de liquidação e valor bruto, pareando 1 para 1 (cada linha do extrato casa com uma única parcela); depois, para o que sobrou, nome normalizado e valor com até 3 dias de diferença. Nome diferente com valor e data iguais não é baixado sozinho: vai para revisão manual. (Evite: Cruzar por valor e deixar a mesma parcela casar com duas linhas do extrato.) 2. **Status com quatro valores e tolerância declarada.** Cada par recebe um status: igual (diferença dentro da tolerância, por exemplo até R$ 1,00), divergente (os dois valores e a diferença lado a lado), só no extrato e só no core ou ERP. Divergência não é erro do pipeline: é discordância real entre sistemas, e a tabela existe para mostrá-la. Se a conferência for exata, sem tolerância, arredondamento também aparece como divergência, e isso precisa estar escrito. (Evite: Mostrar só o número de um dos lados ou esconder as linhas sem par.) 3. **Data de liquidação, no fuso de Brasília.** O que move o saldo é a data em que o dinheiro foi liquidado ou repassado, não a data do pagamento ou do pedido. Converta a data para America/Sao_Paulo antes de cruzar: o ERP costuma baixar o cartão no dia anterior ao que a planilha em UTC mostra. Mantenha a data exibida para o usuário e use a data convertida só no cruzamento. (Evite: Cruzar pela data do pedido ou pela data em UTC.) 4. **Pagamento duplicado tem definição fechada.** Duplicado é o mesmo cliente, com o mesmo id de transação e o mesmo valor, com dois ou mais pagamentos concluídos. Em cobrança recorrente de tarifa ou assinatura, conta como duplicada a segunda cobrança em até 2 dias da primeira. Estornos ficam fora, e lançamentos de teste ou validação de valor simbólico (até R$ 1) também. (Evite: Chamar de duplicado qualquer cliente com dois pagamentos no mês.) 5. **Status interno contra a resposta do processador.** O core grava sucesso ou falha numa coluna própria, mas a resposta bruta do processador traz o status real. Leia o status da resposta, normalize (falha dura e falha leve viram erro; sucesso vira concluído) e liste diariamente os pagamentos em que os dois discordam. É ali que aparece o contrato baixado sem dinheiro ou cobrado de novo. (Evite: Confiar só no status gravado pelo core.) 6. **Todo dia de liquidação precisa ter arquivo.** Gere a lista de dias esperados numa janela móvel (por exemplo, os últimos 35 dias, ignorando os 2 mais recentes, que ainda podem chegar) e marque cada dia como presente ou faltando, com a contagem de linhas e de arquivos. Grave o resultado em modo de acumulação e alerte quando faltar dia. Dia sem arquivo deixa receita e custo do processador abaixo da fatura. (Evite: Supor que o relatório chegou completo porque o pipeline rodou sem erro.) 7. **Componentes do pagamento fecham com o valor pago.** No core de crédito, cada pagamento se divide em principal, juros, multa e tarifas. A soma dos componentes tem que ser igual ao valor pago; quando o arquivo traz um resíduo, aloque-o num componente declarado (por exemplo, principal) e marque a linha. Concilie o total com o processador e os componentes com a carteira. (Evite: Conciliar o total e deixar os componentes somarem outro valor.) 8. **Duas fontes do mesmo recebimento não se empilham.** Durante migração de processador ou de plataforma de cobrança, o mesmo pagamento aparece nas duas fontes. Empilhar as duas conta a cobrança duas vezes. Deduplique pelo id da transação preferindo o registro pago, e corte por data: a fonte antiga até o dia anterior à virada, a nova a partir dela, excluindo o dia processado nas duas. (Evite: Unir as duas fontes de cobrança e somar.) 9. **No ERP, conta da baixa, receita e tarifa separadas.** O título traz a conta esperada e a baixa traz a conta em que o dinheiro entrou; filtre pela conta da baixa. Some só a categoria de receita: tarifas do meio de pagamento, estornos e taxa de transferência são lançamentos próprios. Estorno e contestação usam o valor líquido lido direto da linha do extrato, nunca recalculado a partir do bruto. (Evite: Somar todas as categorias da conta cadastrada no título.) 10. **Baixa de volta no ERP é idempotente.** Antes de criar ou baixar qualquer lançamento pelo conector, liste o dia no ERP e compare descrição e valor contando ocorrências. Crie só o que falta; o que existe em aberto, apenas baixe. A criação costuma ser assíncrona e o conector não tem exclusão: um lançamento duplicado só sai à mão. Depois, confira o dia: pago a receber igual à soma do extrato, aberto igual a zero. (Evite: Reexecutar a criação de lançamentos depois de um erro de limite de requisições.) ### Status de cada recebimento Comparando o relatório de liquidação com o core ou o ERP, pelo par 1 para 1. - **nos dois lados, diferença dentro da tolerância** → Igual (`|extrato - core| <= tolerância`) - **nos dois lados, diferença acima da tolerância** → Divergente (`extrato - core`) - **liquidado e sem par no core ou no ERP** → Só no extrato (não baixado) - **baixado no core ou no ERP e sem liquidação** → Só no core - **mesmo cliente, transação e valor, concluído 2 ou mais vezes** → Duplicado - **status do core diferente da resposta do processador** → Status inconsistente - **valor e data iguais, nome diferente** → Revisão manual - **dia de liquidação sem nenhuma linha no relatório** → Dia faltando ### Definições | Métrica | Definição | |---|---| | Recebimento liquidado | linha do relatório de liquidação ou do extrato com dinheiro creditado, pela data de liquidação em America/Sao_Paulo | | Recebimento baixado | pagamento registrado no core ou baixa de parcela no ERP, na conta da baixa e na categoria de receita | | Não baixado | recebimento liquidado sem par no core ou no ERP depois das duas etapas de pareamento, por dia de liquidação | | Diferença | valor do extrato menos valor do core ou ERP, por par; acima da tolerância declarada vira divergente | | Pagamento duplicado | segunda ocorrência concluída do mesmo cliente, id de transação e valor; em cobrança recorrente, nova cobrança em até 2 dias | | Status inconsistente | pagamento em que o status normalizado do core difere do status da resposta do processador, por dia de criação | | Cobertura do relatório | dias de liquidação com pelo menos uma linha / dias esperados na janela, por execução | | Custo do processador | soma das tarifas por transação e de rede, por dia de liquidação e tipo de transação | ### Armadilhas - **Categoria errada no ERP.** Somar todas as categorias da conta do gateway, em vez de só receita, abriu uma diferença de dezenas de milhares de reais num mês contra o extrato. Como evitar: Filtre pela conta da baixa e pela categoria de receita. - **Estorno lançado pelo bruto.** Um lote de estornos foi criado no ERP com o valor bruto em vez do líquido. O conector não exclui, e a correção foi manual, lançamento por lançamento. Como evitar: Leia o valor líquido da linha do extrato e confira o dia antes de liberar o lote. - **Custo abaixo da fatura.** Dias sem arquivo do processador sumiram do cálculo de custo, que ficou menor que a fatura sem nenhum erro no pipeline. Como evitar: Monitore a cobertura por dia de liquidação e alerte o dia faltando. - **Conexão de outro cliente.** Num BPO, tabelas antigas do ERP de um cliente vinham de uma conexão errada e traziam os dados de outra empresa. Como evitar: Uma conexão por cliente, documentada, e nunca usar a de outro para ler ou escrever. - **Cobrança contada duas vezes na migração.** Duas plataformas de boleto rodaram em paralelo e a união simples somou a mesma cobrança nas duas. Como evitar: Deduplique pelo id da transação, preferindo o registro pago, e corte por data. - **Chave inválida some em silêncio.** Códigos de cruzamento preenchidos com lixo, como 0 ou números curtos, deixavam registros fora da conciliação sem aviso. Como evitar: Valide o formato da chave e liste à parte quem ficou fora. ### Teste de aceitação - [ ] Para um dia fechado, a soma de igual, divergente e só no extrato tem a mesma contagem e o mesmo valor do relatório de liquidação. - [ ] Nenhuma linha do core ou do ERP casa com duas linhas do extrato, e nenhuma linha do extrato casa com duas parcelas. - [ ] Para um dia conferido na conta do processador, o pago a receber no ERP é igual à soma do extrato e o aberto é zero. - [ ] A tabela de cobertura tem uma linha por dia de liquidação da janela em cada execução, e todo dia faltando gerou alerta. - [ ] Rodar a baixa automática duas vezes no mesmo dia não cria nenhum lançamento novo. ### Context document ```text Conciliação de recebimentos - Lados: relatório de liquidação em contra em . Toda resposta mostra os dois lados. - Chave: . Sem ela, 1ª etapa por data de liquidação + valor bruto, pareando 1 para 1; 2ª etapa por nome normalizado + valor, até 3 dias. Nome diferente com valor e data iguais vai para revisão manual. - Status: igual (diferença até R$ ), divergente (mostrar os dois valores e a diferença), só no extrato (não baixado), só no core. - Data: data de liquidação, convertida para America/Sao_Paulo. Nunca a data do pedido. - Duplicado: mesmo cliente, mesmo id de transação e mesmo valor, concluído 2 ou mais vezes. Recorrente: segunda cobrança em até 2 dias. Estornos e valores até R$ 1 fora. - Status inconsistente: status do core diferente do status da resposta do processador. - Cobertura: todo dia de liquidação da janela precisa ter arquivo. Dia faltando é falha de carga, nunca dia sem recebimento. - ERP: filtrar pela conta da baixa e pela categoria de receita. Tarifas, estornos e taxas de transferência são lançamentos próprios. Estorno pelo valor líquido do extrato. - Contagens (quantos divergem, quantos não baixados) são calculadas na hora, com a data da carga. Nunca cite de memória. - Antes de qualquer escrita no ERP, liste o dia e crie só o que falta. O conector não exclui. Exceções por cliente: - : conexão do ERP ; nunca usar a de outro cliente. - : a plataforma de cobrança vale até ; a partir de . - : estorno lançado na categoria . ``` ### Variações - **Funding em dois sistemas:** Aportes e recompras do controle financeiro contra a base operacional, por empreendimento e mês, com aporte positivo, recompra negativa e tolerância de R$ 1,00. - **Boletos de cooperativa e seguro:** Cobranças mensais de cota ou prêmio em duas plataformas de boleto, deduplicadas pelo id da transação e casadas com o cadastro do associado. - **BPO com gateway de e-commerce:** Extrato do gateway contra as parcelas do ERP de cada cliente do escritório, com recebimento, tarifa e estorno lançados pelo conector.