Como conciliar pagamentos com ciclos liberados

1. Modele pagamento e ciclo como eventos diferentes

Um pagamento passa por estados definidos pelo sistema de cobrança; um ciclo passa por eventos de comando, liberação, início, término ou falha. O fato de uma etapa aparecer não prova que a próxima ocorreu. Crie uma tabela de transações com identificador, horário, valor, status de pagamento, origem, máquina e vínculo para ciclo. Em outra tabela, mantenha os eventos do equipamento: comando de início, resposta, código de falha, término e identificador da máquina.

Uma chave única por pedido ou sessão simplifica o pareamento, mas pode não estar disponível em todos os sistemas. Não invente um ID retroativo só para fazer os dados coincidir. Registre qual campo realmente liga os eventos — ID da ordem, referência do gateway ou código de sessão — e a qualidade da correspondência. O relatório de recebimentos e o de ciclos respondem a perguntas diferentes; documente o sentido de cada status antes de consolidar.

Se os sistemas não compartilham chave, anote quais campos serão combinados e limite pareamentos por aproximação a uma fila de revisão humana. Valor igual e horário próximo podem corresponder a duas compras diferentes; nome de cliente não deve ser usado como atalho sem necessidade e proteção. Mantenha campo para nível de confiança e motivo do vínculo. Uma correspondência incerta não deve alimentar automaticamente um estorno, cobrança ou declaração de que o ciclo foi pago.

2. Sincronize período e relógio antes de comparar

Defina o fuso da unidade e confira a configuração de relógio nos painéis, terminais e exports. Pagamento aprovado às 23h59 e ciclo liberado às 00h01 pode cair em datas diferentes, embora faça parte da mesma interação. Use uma janela de pareamento que considere a latência real do sistema, definida após observar logs ou documentação técnica; não escolha um número arbitrário e não amplie a janela até parear transações que podem ser independentes.

Se o provedor liquida em lote, a data de depósito não substitui o identificador transacional. Compare aprovação com ciclo e, em etapa separada, liquidação com extrato. A ITG 2000 (R1) consta nas normas do CFC para escrituração; mantenha documentação de suporte conforme orientação do contador. A conciliação operacional deve conservar referência e horário suficientes para localizar o fato, sem dizer que a planilha substitui o registro contábil ou do sistema.

3. Monte uma matriz de combinações e exceções

Classifique cada par de registros em: pagamento aprovado + ciclo iniciado; pagamento aprovado + sem evento de ciclo; ciclo iniciado + pagamento não aprovado; cobrança cancelada + ciclo iniciado; dois pagamentos + um ciclo; um pagamento + dois ciclos; reembolso + ciclo concluído; ou sem correspondência nos dois lados. Para cada classe, defina investigação e responsável. O status “sem correspondência” deve ficar separado de “fraude” ou “erro” até a origem ser confirmada.

Essa matriz também revela eventos sem cobrança: ciclo de teste, cortesia, manutenção, falha de registro ou uso manual autorizado. Identifique-os como exceção documentada, não como venda. Se o sistema aceita pagamentos divididos ou créditos pré-pagos, modele como tal antes de chamar duas autorizações de duplicidade. Um relatório com quantidade de casos e valores por classe ajuda a priorizar sem esconder a diferença em uma linha de total.

Defina quais exceções são esperadas e autorizadas: teste do técnico, ciclo cortesia, manutenção, reprocessamento após falha e uso de contingência. Cada exceção recebe motivo, solicitante, autorização e duração ou alcance. Assim, uma execução legítima sem pagamento não é classificada junto de uma falha, e uma falha não desaparece sob o rótulo de cortesia. Reveja privilégios de liberação manual para garantir que só funções autorizadas possam usá-los.

4. Trate aprovado sem ciclo sem gerar nova cobrança

Localize a referência do pagamento e consulte o log do comando de liberação, resposta do equipamento e registro de cancelamento. Confirme se a máquina recebeu o comando, se ficou aguardando interação, se o ciclo iniciou e se houve timeout. Verifique em seguida o status atual do pagamento e se existe uma política documentada de cancelamento ou reembolso. Não peça ao cliente para pagar novamente antes de saber se a primeira cobrança está ativa; a duplicidade pode agravar o caso.

Se o evento não puder ser localizado, informe a pendência ao responsável financeiro e técnico com os IDs, horário e equipamento. A resposta ao cliente deve ser factual, com protocolo e próximo passo, sem prometer crédito ou prazo que depende de um terceiro. Registre qual fonte confirmou a aprovação e qual não apresentou a liberação. O desfecho pode ser reembolso, reexecução ou outra solução conforme a política e o caso; não há solução universal a aplicar sem análise.

Use uma mensagem consistente para o cliente: confirme o identificador que será verificado, diga se há cobrança localizada ou se ainda está em análise e forneça protocolo. Se houver suspeita de duplicidade, informe que a equipe está conferindo antes de solicitar novo pagamento. Não peça senha, código de autenticação ou dados completos do cartão. Quando um terceiro controla a transação, explique a dependência sem transferir toda a responsabilidade ao cliente nem garantir um resultado que ainda não foi confirmado.

5. Trate ciclo sem pagamento confirmado com cautela

Confira se a cobrança está realmente negada ou apenas pendente, se o pagamento usou crédito anterior, se houve falha de sincronização ou se o ciclo foi autorizado manualmente. Confirme o log bruto antes de interpretar o painel. Não cobre automaticamente o cliente nem desligue equipamento remotamente sem política e avaliação técnica. Se o ciclo foi liberado durante falha do sistema, crie registro de exceção e envie para revisão do fechamento.

Um evento de máquina pode ser duplicado por retransmissão ou reinício de integração. Compare identificadores e horário, e consulte o fornecedor sobre comportamento idempotente quando aplicável. Não apague evento repetido; marque a cópia técnica como duplicada por referência ao original e preserve ambos os registros. Se a situação se repetir, interrompa a automação afetada conforme procedimento aprovado e escale a investigação, pois correção de uma única transação não elimina a falha de integração.

6. Use chaves, estados e reconciliação de totais

Implemente uma regra de pareamento auditável: correspondência exata por identificador quando disponível; caso contrário, combinação de atributos documentada, com revisão humana para casos ambíguos. Não faça pareamento automático apenas por valor e proximidade de horário se existirem várias compras iguais. Registre método e confiança, deixe sem correspondência quando a evidência não basta e mantenha uma fila de revisão. Compare contagens totais de eventos e pagamentos antes e depois da transformação.

Use status padronizados e não permita que um usuário encerre um caso sem motivo de resolução. Uma segunda pessoa pode revisar reembolsos, cobranças duplicadas ou ajustes acima de limite interno, se a estrutura da empresa permitir. A trilha deve guardar origem, consulta feita, decisão, responsável e data. O material do Banco do Nordeste sobre controle financeiro apoia registrar entradas e saídas, mas a regra de pareamento depende dos sistemas e do contrato usado na unidade.

Separe a tela de operação, que pode atualizar em tempo real, do arquivo de conciliação fechado para o período. Salve hora da extração, filtros e versão de integração, e marque se os status são preliminares ou finais. Se o provedor muda definições, preserve um dicionário de status por versão. Uma palavra como “aprovado” pode significar autorização financeira, captura ou confirmação final em sistemas diferentes; consulte a documentação do próprio canal antes de equiparar estados.

7. Acompanhe reincidência e corrija a integração

Conte aprovados sem ciclo, ciclos sem cobrança, duplicidades, tempo de resolução e valor pendente por período, sempre com o número total de tentativas para contextualizar a taxa. Se o denominador for desconhecido, mostre apenas contagem. Segmente por versão de software, máquina, modalidade e hora para localizar condições comuns. Não compare antes e depois de uma atualização sem registrar a data e o efeito sobre a forma de coletar logs.

Ao alterar integração, teste cenários controlados: pagamento recusado, aprovado, resposta atrasada, repetição de mensagem, cancelamento e queda de rede, de acordo com ambiente seguro e orientação do fornecedor. Preserve o resultado do teste e o plano de retorno. Uma melhora observada precisa de acompanhamento em operação; não declare que uma correção eliminou todo risco após um único dia. A fila de conciliação deve continuar disponível enquanto restar pendência material.

Ao identificar padrão, abra uma tarefa técnica com reprodução mínima: sequência de eventos, versão, IDs de teste e resultado esperado. Retire dados pessoais desnecessários e use ambiente de homologação quando houver. Solicite ao responsável pela integração uma confirmação escrita do comportamento e do plano de implantação. Depois, monitore as mesmas classes de divergência; se a taxa caiu mas o registro mudou, a série precisa de nota de quebra para não sugerir uma correção que os dados não comprovam.

Inclua no fechamento uma taxa de correspondência: quantos pagamentos aprovados ficaram ligados a um evento de máquina, quantos eventos tiveram cobrança e quantos estão pendentes. Defina o denominador e a janela de conciliação ao lado da taxa. Se houver evento sem chave ou período incompleto, mostre isso como cobertura. Sem essa informação, uma porcentagem de conciliação parece mais precisa do que os registros permitem.

Perguntas frequentes