Probleminhas Com Sistema Monetário

Como resolver problemas comuns em sistemas monetários

O sistema monetário interno da maioria das empresas ébasicamente um conjunto de regras de conciliação, taxas de câmbio e split de pagamentos. Quando algo falha, geralmente não é o banco ou a adquirente que erraram. É a forma como você mapeou a origem dos valores no seu ledger.

probleminhas com sistema monetário no dia a dia

Vou começar pelo que mais vejo acontecer nos chats de suporte financeiro: discrepância de centavos. O usuário diz que a conta fecha com R$ 0,07 de diferença. A resposta normal é arredondamento. Mas na prática, são duas causas diferentes. A primeira é o arredondamento truncado durante a conversão cambial. Se você converte USD para BRL usando uma taxa com seis casas decimais e depois trunca para duas casas em cada linha de venda, a soma das linhas nunca vai bater com o total convertido de uma vez. A solução é converter o valor total do lote e depois distribuir. Funciona para o Brasil todo. Para operações multi-moeda, você precisa aplicar a mesma lógica em cada moeda base separadamente.

A segunda causa é o split de taxa de serviço. Quando uma platforma cobra 2,5% mais uma taxa fixa de R$ 0,50 por transação, o cálculo do repasse para o vendedor costuma ser feito de forma diferente dependendo do módulo que você consulta. O módulo de cobrança calcula (valor - taxa_fixa) * (1 - percentual). O módulo de liquidacao às vezes calcula valor * (1 - percentual) - taxa_fixa. A diferença aparece só quando o ticket é baixo. Num valor de R$ 10,00, a diferença pode ser de R$ 0,02 a R$ 0,05 por operação. Multiplicado por mil transações por dia, vira R$ 200 a R$ 500 de diferença mensal que ninguém explica. Eu tive esse problema num projeto meu com uma fintech de marketplace. O sistema de conciliação automática dava false-positive de erro todo dia. Descobri que o módulo de fee estava sendo aplicado duas vezes em transações que vinham de um canal específico de afiliados. A correção foi adicionar uma flag de origem no payload e tratar o caminho de afiliado com uma regra separada. Levei uma tarde inteira só pra rastrear porque o log de fees não mostrava a origem da transação.

Agora vou falar do problema que ninguém gosta de admitir: floating point. Se você armazena valores monetários em float ou double, você vai ter problemas. Sempre. Não é questão de se, é questão de quando. R$ 0,10 somado dez vezes em float dá algo como 0,9999999999999998. Isso não é um bug raro. Isso acontece em todo sistema que não usa decimais ou inteiros para representar dinheiro. A regra é simples. Armazene tudo em centavos como inteiro, ou use decimal/BigDecimal dependendo da linguagem. Se o seu sistema já usa float e tem milhões de registros, não tente corrigir tudo de uma vez. Crie uma view de normalização que converte os valores para inteiro numa coluna separada e vá migrando gradualmente. Se você tentar um update em massa, vai travar o banco por horas e provavelmente vai perder consistência em alguma tabela de log.

Conciliação automática versus manual

A maioria dos problemas monetários surge na gap entre o que o banco diz que recebeu e o que seu sistema diz que deveria ter recebido. A conciliação automática funciona bem quando as regras são claras. Quando têm regras claras e poucos casos borda. O problema é que casos borda são exatamente onde o dinheiro desaparece. Um cenário comum que vejo em empresas de médio porte: a adquirente faz o split de comissao antes de repassar pro vendedor. O vendedor vê um valor, o banco vê outro, e a plataforma fica no meio sem saber quem deve o quê. A solução que eu uso é criar uma conta de transitória chamada "commission_hold". Todo valor de comissão entra nessa conta primeiro, você concilia ela contra o extrato da adquirente, e só depois libera pro vendedor. Isso adiciona um passo no processo, mas elimina a maior parte das reconciliações manuais.

Outro ponto que as pessoas ignoram: a taxa de liquidação. Quando o dinheiro cai na conta, já vem descontada a taxa. Muitos sistemas registram o recebimento pelo valor bruto e depois ajustam a taxa como uma linha separada. Isso gera inconsistência porque o extrato bancário mostra um valor único e o sistema mostra dois. O correto é registrar pelo valor líquido e usar um campo de gross_amount separado para controle interno. Aí sua conciliação bancária funciona direto, sem ajuste manual.

Quando o sistema não funciona mais

Vou ser direto sobre onde essas soluções falham. Conciliação automática cai quando você tem mais de cinco moedas diferentes operando simultaneamente com taxas de conversão que mudam durante o dia. O custo de manter o mapeamento correta cresce exponencialmente. Nesse caso, o melhor é aceitar que parte do processo será manual e focar em logs detalhados, não em automação. Também não adianta automatizar conciliação se a sua origem de dados é ruim. Se o ERP gera notas fiscais com valores diferentes dos valores registrados no sistema de pagamento porque tem algum job noturno que recalcula impostos e sobrescreve o registro original, você vai gastar tempo demais tentando reconciliar algo que já nasceu errado. A solução raiz não está no módulo de conciliação. Está em impedir que o valor mude depois de lançado.

Se você precisa de uma referência rápida para começar, recomendo olhar a especificação ISO 20022 para fluxos de pagamento. Ela padroniza campos como Amount, Chrgs e Tax de forma que sua conciliação tenha menos ambiguidade. Não é solução mágica, mas reduz significativamente os casos onde você precisa perguntar "o que esse número significa?". O que funciona na prática é menos automação e mais rastreamento. Um bom sistema monetário não evita erros. Ele mostra exatamente onde o erro aconteceu e quanto tempo levou para detectá-lo. Se você está gastando mais de duas horas por dia corrigindo diferenças manuais, o problema não é a velocidade da sua reconciliação. É a qualidade dos dados que entram no sistema.