Matching probabilistico: como a IA reconcilia pagamentos mesmo com dados incompletos

Segundo dados do setor, 75% das empresas brasileiras ainda enfrentam dificuldades para conciliar corretamente suas transações bancárias devido a falta de integração entre sistemas financeiros e dados de múltiplos CNPJs. O motivo mais comum não é falta de tecnologia -- é a qualidade dos dados. Nomes abreviados, referências truncadas, valores arredondados e descrições inconsistentes entre bancos e ERPs transformam a conciliação em um quebra-cabeca manual. O matching probabilistico com IA resolve exatamente esse problema.

Neste post, vamos explorar como algoritmos de IA atribuem scores de confiança para reconciliar pagamentos mesmo quando os dados são imperfeitos, e por que essa abordagem é superior ao matching exato tradicional.

Por que o matching exato falha

O matching exato funciona com uma lógica simples: se o valor, a data é a referência são idênticos no extrato bancário e no ERP, é um match. Se qualquer campo diverge, não e. Essa abordagem funciona razoavelmente bem quando:

• Todos os pagamentos incluem o número da nota fiscal na descrição
• Os nomes dos pagadores são sempre idênticos aos cadastrados no sistema
• Não há fracionamentos, arredondamentos ou diferenças de timing

Na prática, isso quase nunca acontece. Exemplos reais de por que o matching exato falha:

• O banco registra "TED 0341 J SILVA ME" e o ERP tem "Jose da Silva Comércio - ME"
• Um cliente paga R$ 4.997,50 referente a uma fatura de R$ 5.000,00 (descontou taxa bancária)
• A descrição do PIX diz apenas "pgto serv" sem nenhuma referência a nota fiscal
• Um pagamento de R$ 15.000,00 se refere a três notas fiscais de R$ 5.000,00 cada
• O depósito chega em D+2 mas a data no ERP e a data de emissão do boleto

O resultado? Taxas típicas de auto-match com regras exatas ficam entre 50% e 65%. As outras 35% a 50% das transações vão para uma fila de revisão manual que consome horas da equipe financeira.

Como funciona o matching probabilistico

O matching probabilistico inverte a lógica: em vez de perguntar "esses registros são idênticos?", pergunta "qual a probabilidade de esses registros se referirem a mesma transação?". Para isso, o sistema avalia múltiplas dimensões simultaneamente e calcula um score de confiança composto.

As dimensões do scoring

Um sistema típico avalia pelo menos estas dimensões:

• Similaridade de valor (peso alto): Diferença percentual entre os valores. R$ 5.000,00 vs R$ 4.997,50 = 99,95% de similaridade
• Proximidade temporal (peso médio): Quantos dias de diferença entre as datas. Mesmo dia = score máximo; D+2 = score alto; D+7 = score médio
• Similaridade de texto (peso variável): Algoritmos como Levenshtein, Jaro-Winkler ou TF-IDF comparam nomes e descrições. "J Silva ME" vs "Jose da Silva Comércio ME" = score ~82
• Histórico de padrões (peso crescente): Se esse mesmo pagador já fez 15 pagamentos anteriores com o mesmo padrão de abreviação, o score sobe
• Contexto bancário (peso auxiliar): Qual banco, tipo de transação (TED, PIX, boleto), hora do dia -- cada um adiciona ou subtrai do score final

O cálculo do score composto

Cada dimensão recebe um peso configurável e o sistema calcula um score final ponderado. Um exemplo simplificado:

Com um threshold de auto-match configurado em 90, essa transação seria reconciliada automaticamente. Se o threshold fosse 95, iria para revisão humana com o score visível e a sugestão de match.

Machine learning: o score que melhora com o tempo

A grande vantagem do ML sobre regras estáticas e o aprendizado contínuo. Cada vez que um analista:

• Confirma um match sugerido, o modelo reforça o padrão
• Rejeita um match e faz a correção, o modelo aprende com o erro
• Reconcilia manualmente uma transação que o sistema não encontrou, o modelo incorpora o novo padrão

Esse feedback loop significa que o sistema se adapta as particularidades da sua empresa. Se seus clientes consistentemente abreviam nomes de uma forma específica, ou se um determinado banco sempre trunca descrições em 20 caracteres, o modelo aprende.

Dados de implementações reais mostram a evolução típica:

• Mês 1: Taxa de auto-match de 68-72%
• Mês 3: Taxa sobe para 85-88%
• Mês 6: Taxa estabiliza em 92-96%
• Após 12 meses: Sistemas maduros alcançam 97%+ em ambientes estáveis

A HighRadius demonstrou isso no caso de uma grande rede hoteleira americana: após o período de treinamento, o sistema atingiu 97% de automação na conciliação de mais de 1.700 entidades.

Casos práticos de dados incompletos

Caso 1: pagamentos sem referência

Um cliente faz um PIX de R$ 3.200,00 com a descrição "pagamento". Sem número de nota, sem nome completo, sem nenhuma referência útil. O matching probabilistico:

1. Busca faturas abertas no range de R$ 3.100 a R$ 3.300 (tolerância de 3%)
2. Encontra uma fatura de R$ 3.200,00 para o cliente "ABC Comércio"
3. Verifica se o CPF/CNPJ do pagador PIX corresponde ao cadastro do cliente
4. Cruza com histórico: esse cliente já fez 8 pagamentos via PIX nos últimos 6 meses
5. Score final: 94 -- auto-match com flag para revisão amostral

Caso 2: pagamento fracionado

Uma empresa recebe dois depósitos no mesmo dia: R$ 7.500,00 e R$ 2.500,00. No ERP, há uma fatura única de R$ 10.000,00. O matching probabilistico:

1. Não encontra match individual para nenhum dos dois valores
2. Testa combinações: R$ 7.500 + R$ 2.500 = R$ 10.000 -- match exato de valor
3. Verifica se ambos os depósitos vem do mesmo pagador ou contas associadas
4. Consulta histórico: esse cliente já fracionou pagamentos 3 vezes antes
5. Score final: 91 -- auto-match com registro da lógica de agrupamento

Caso 3: nome completamente diferente

O extrato mostra um pagamento de "TECH SOLUTIONS HOLDING" mas no ERP o cliente está cadastrado como "TS Tecnologia Ltda". O matching probabilistico:

1. Similaridade de texto entre os nomes: score 35 (muito baixo)
2. Porém o valor (R$ 18.750,00) corresponde exatamente a uma fatura aberta
3. O CNPJ raiz do pagador está vinculado ao grupo econômico do cliente no cadastro
4. Score final: 89 -- encaminhado para revisão humana, mas com forte sugestão de match

Esse último caso ilustra por que o matching probabilistico é superior: ele combina evidências fracas em uma dimensão (nome) com evidências fortes em outras (valor, CNPJ) para chegar a uma conclusão razoável.

Configurando thresholds por tipo de transação

Não existe um threshold único ideal. A configuração deve refletir o perfil de risco de cada tipo de transação:

Pagamentos recorrentes a fornecedores: threshold 85

• Padrões previsíveis, mesmo fornecedor todo mês
• Risco baixo de erro, fácil de corrigir

Recebimentos de clientes regulares: threshold 88

• Variação moderada em valores (descontos, juros)
• Nomes geralmente consistentes

Recebimentos de clientes novos: threshold 95

• Sem histórico para o modelo se apoiar
• Maior risco de match incorreto

Transações internacionais: threshold 92

• Variações cambiais, nomes em diferentes idiomas
• Bancos intermediários adicionam complexidade

Taxas e encargos bancários: threshold 80

• Valores pequenos, padrões muito previsíveis
• Baixo impacto de um match incorreto

O papel dos LLMs na próxima geração

A integração de Large Language Models está adicionando uma nova camada ao matching probabilistico. Plataformas como a Modern Treasury já usam LLMs para:

• Interpretar descrições em linguagem natural: "pgto ref contrato manutenção predial jan/26" e associado automaticamente ao contrato correto
• Sugerir regras de reconciliação com base nos padrões detectados nos dados
• Responder perguntas operacionais como "quantos itens de conciliação estão abertos há mais de 30 dias?"
• Detectar anomalias como pagamentos duplicados ou taxas inesperadas

A Modern Treasury reporta que, com a combinação de heurística, algoritmos deterministicos e LLMs, seus clientes alcançam taxas de reconciliação de 90% a 100% no nível de transação individual.

Métricas que importam

Ao avaliar uma solução de matching probabilistico, acompanhe estas métricas:

• Taxa de auto-match: Percentual de transações reconciliadas sem intervenção humana. Meta: >90% após 3 meses
• Taxa de falso positivo: Matches automáticos que estavam errados. Meta: <0,5%
• Taxa de falso negativo: Transações que tinham match mas não foram encontradas. Meta: <2%
• Tempo médio de resolução de exceções: Quanto tempo um analista leva para resolver itens não conciliados. Meta: redução de >50% com sugestões do sistema
• Curva de aprendizado: Como a taxa de auto-match evolui mês a mês. Deve mostrar melhoria contínua nos primeiros 6 meses

Ações práticas

1. Audite sua taxa de matching atual: Calcule quantas transações são reconciliadas automaticamente hoje vs. manualmente. Se a taxa automática está abaixo de 70%, há ganho imediato com matching probabilistico.
2. Classifique suas transações por complexidade: Separe pagamentos recorrentes (fácil de automatizar) de transações ad hoc (precisam de ML mais sofisticado). Priorize a automação das recorrentes para ganho rápido.
3. Garanta a qualidade do cadastro de clientes e fornecedores: O matching probabilistico funciona melhor quando há dados auxiliares -- CNPJ, grupo econômico, contas bancárias vinculadas. Invista tempo em limpar e enriquecer esses cadastros.
4. Estabeleca um processo de feedback estruturado: Quando o analista corrige um match, deve haver um mecanismo para que essa correção alimente o modelo. Sem feedback loop, o ML não melhora.
5. Monitore falsos positivos com rigor: Um match incorreto que passa despercebido é mais perigoso que uma transação não conciliada. Faça revisão amostral semanal dos auto-matches, especialmente nos primeiros meses.