Ledgerline.

O problema

A parte difícil nunca foi o dashboard. Era tornar a importação e a categorização confiáveis o suficiente pra agir em cima: CSVs de bancos com formatos diferentes, pagadores recorrentes com nomes inconsistentes, e o fato de que ferramenta financeira em que ninguém confia é pior que nenhuma.

O que tornou tecnicamente interessante

Cada banco exporta CSV com suas manias: datas em formatos diferentes, débitos como valor positivo ou negativo, encodings que quebram no meio do arquivo. A camada de ingestão precisa traduzir tudo isso num modelo de transação confiável sem perder dado no caminho.

A categorização precisa ser automática o suficiente pra economizar tempo e corrigível o suficiente pra continuar precisa — um motor de regras que aprende pagadores recorrentes, com toda correção manual realimentando as regras.

A pergunta central do painel — 'quanto eu posso gastar com segurança agora' — depende de compromissos, não só de saldos. Isso significa modelar obrigações futuras, não apenas transações passadas.

Decisões

Um modelo de transação único e normalizado

Todo formato de banco é traduzido na borda do sistema, então o domínio central nunca precisa saber de onde veio a transação. Adicionar um banco virou um problema de mapeamento, não de reescrita.

Agregação no servidor, não no cliente

Os resumos mensais são calculados em views SQL em vez de carregar transações cruas no navegador — o painel continua rápido mesmo com anos de histórico.

Motor de regras com correção humana

A automação cuida da maior parte da categorização, e correções manuais realimentam as regras — o sistema fica mais preciso quanto mais é usado.

Resultado

• Exportações de bancos diferentes se normalizam num modelo único — o pipeline se estende por mapeamento, não por reescrita.
• Resumos mensais e cientes de compromissos são calculados em SQL — a interface nunca rederiva o estado financeiro.
• Correções alimentam o motor de regras em vez de acumular como exceções sem estrutura.