Como fazer uma rua da concordância que de fato funciona
A maioria das pessoas que ouve falar pela primeira vez em rua da concordância imagina que se trata de algum método mágico para conciliar informações. Na prática, é bem mais simples e chato do que isso. Consiste basicamente em cruzar duas bases — geralmente a sua com a do banco ou do parceiro — e identificar o que não bate. O problema é que quase todo mundo já tentou e desistiu porque fez de qualquer jeito.
O que é realmente a rua da concordancia
Não existe uma definição oficial por aí. Quando eu comecei a lidar com isso, ninguém na equipe sabia explicar direito. A gente acabou batizando o processo de "rua da concordância" porque era assim que funcionava: você pega a planilha A, a planilha B, e vai linha por linha vendo onde elas divergem. O nome veio de um documento que eu vi numa pasta antiga no escritório, com esse título escrito à mão num post-it amarelado. O conceito é simples. Você tem dois registros que deveriam ser idênticos. Eles não são. Seu trabalho é encontrar o porquê. Pode ser um erro de digitação, uma transação que caiu de um lado e não do outro, um valor que foi aplicado com código diferente, ou simplesmente uma data que foi registrada em dia útil em uma base e em dia calendário na outra.
Como eu faço na prática
Eu não uso planilha para isso mais. Planilha funciona para poucos registros, mas quando você passa de mil linhas a coisa vira pesadelo. Meu fluxo atual é o seguinte. Primeiro, eu puxo os dois arquivos brutos. Um vem do sistema financeiro, o outro do extrato ou da contraparte. Eu transformo ambos em CSV com campos normalizados — data no formato AAAA-MM-DD, valores numéricos sem separadores de milhar, códigos padronizados. Isso parece óbvio, mas 40% dos erros que aparecem na concordância surgem de formatação incompatível.
Depois, eu carrego os dois CSVs num script Python simples. Uso pandas. Faço um merge externo (outer merge) pela chave principal, que normalmente é o número do documento ou a referência da transação. O resultado mostra todas as linhas — as que batem, as que só existem de um lado, e as que existem nos dois mas com diferença. As linhas que existem nos dois mas com diferença eu separo em dois subgrupos. Um é diferença de valor, outro é diferença de data ou descrição. Cada um exige uma abordagem diferente. Valor que difere às vezes é juros ou tarifas que uma das partes não está considerando. Data que difere geralmente é problema de fuso horário ou de critério de reconhecimento — uma parte registra quando houve o lançamento contábil, a outra quando o valor foi efetivamente movimentado.
Um problema real que eu tive
Numa operação específica, eu estava conciliando pagamentos de cartões de crédito. O sistema interno registrou 1.247 transações. O extrato do cartão trouxe 1.248. A diferença era de R$ 0,01. Não era um erro bobo, era uma taxa de adesão que tinha sido cobrada separadamente e não constava nos demais campos de referência. O merge não mostrava nada errado nas linhas que coincidiam. A única diferença estava em uma linha onde o valor do sistema era 0,00 e no extrato era 0,01. Parecia lixo. Achei que podia ignorar. Mas quando eu ignorei as diferenças menores que R$ 1,00 na primeira tentativa, o relatório final travou na análise porque a contraparte apontou exatamente esse centavo como divergência.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A solução foi criar um campo de tolerância configurável no script. Quando a diferença absoluta for menor que um threshold definido pelo responsável financeiro, a linha é marcada como "conciliável automaticamente" e vai para uma aba separada para revisão humana. Threshold padrão que eu uso é R$ 0,05. Acima disso, exige justificativa documentada.
O que ninguém te conta sobre esse processo
O primeiro insight contraintuitivo é que a maioria das divergências não vem de erro. Vem de timing. Transações processadas perto do fechamento do dia, diferenças de fuso horário entre sistemas, lançamentos que caem no dia seguinte ao evento real. Se você tentar conciliar tudo com base apenas no campo data, vai passar horas caçando fantasmas. Segundo: nem sempre a base do parceiro está certa. Já vi casos em que o extrato trazia um lançamento duplicado porque o sistema de compensação havia retry automático sem registro adequado. A conciliação cega, assumindo que o arquivo externo é sempre a verdade, pode fazer você "fechar" divergências que na verdade são erros da outra ponta.
Eu sempre faço o script registrar um log de todas as linhas que foram marcadas como conciliadas automaticamente, com timestamp e responsável. Assim, se alguém questionar depois, você consegue rastrear exatamente o que foi fechado e sob qual critério.
Limitações que eu enxergo
A rua da concordância tem um ponto fraco claro: ela funciona bem quando as duas bases têm chaves únicas e estáveis para fazer o join. Quando você trabalha com transações que não têm identificador próprio — como rateios de custo compartilhado ou lançamentos agregados — o merge direto não resolve. Nesses casos, eu uso uma combinação de data mais valor como chave composta, e ainda assim preciso de um campo manual de aprovação para os casos ambíguos. Outro problema é volume. Eu já vi operações com mais de 50 mil linhas que levavam horas para rodar o merge e gerar o relatório. A otimização que fiz foi particionar os arquivos por mês antes de processar, o que reduziu o tempo de execução de cerca de 4 horas para 25 minutos no mesmo hardware. Processar tudo junto gera memória insuficiente e timeouts no banco de dados intermediário.
Se o seu volume é alto e recorrente, o script manual deixa de ser viável. Aí eu recomendo migração para uma ferramenta dedicada de conciliação automática, tipo uma instância do Trint or uma configuração customizada com regras de matching mais flexíveis. O custo inicial é maior, mas o tempo de manutenção cai drasticamente.
Dica prática que vale a pena
Antes de rodar qualquer script, escreva um resumo estatístico de cada base: total de linhas, soma dos valores, range de datas, códigos mais frequentes. Se a soma total das duas bases difere em mais de 2% antes mesmo de fazer o cruzamento, algo está errado no cadastro ou na extração. Não adianta rodar o merge e esperar encontrar o erro linha por linha. Identifique a anomalia macro antes de entrar nos detalhes. Isso economiza em média 30 minutos por rodada de conciliação e evita que você perca hora procurando uma divergência que na verdade é um erro de extração de dados.
