Controle financeiro costuma falhar por um motivo simples: registrar dá trabalho.
Você compra vinte itens no supermercado. Ninguém quer chegar em casa e digitar vinte linhas. Abastece o carro e esquece de anotar a quilometragem. Faz uma compra no cartão e só percebe o impacto quando a fatura fecha. Paga uma conta, salva o comprovante em algum lugar e semanas depois já não lembra onde está. Compra carne em três lugares diferentes durante o mês, mas não consegue responder qual deles realmente saiu mais barato.
Planilhas resolvem parte do problema. Aplicativos financeiros resolvem outra parte. Mas, na prática, ainda existe uma quantidade enorme de trabalho manual entre “isso aconteceu” e “isso virou informação útil”.
O JULIUS nasceu justamente nesse espaço.
Ele foi criado para ajudar a transformar a própria bagunça do cotidiano — mensagem, áudio, cupom, fatura, abastecimento, conta e comprovante — em um histórico financeiro estruturado.
É um sistema particular desenvolvido pela Luminvs Tecnologia, em evolução contínua, que combina IA generativa, visão, transcrição, WhatsApp, regras financeiras, banco de dados e GPT Actions.
E talvez a melhor forma de explicar o projeto seja esta:
JULIUS é uma memória financeira que sabe conversar.
Não é uma planilha com chatbot por cima
Há uma diferença enorme entre colocar um chatbot em cima de uma tabela e construir um assistente financeiro.
Um chatbot pode responder bonito.
Um assistente financeiro precisa saber onde o dinheiro entrou, onde saiu, qual cartão foi usado, em qual fatura a compra caiu, qual conta pagou a fatura, se houve parcelamento, se o mesmo comprovante já foi processado, se uma correção anterior deve ser reaproveitada e se determinado gasto pertence à casa ou a um veículo.
Isso exige regras.
Exige banco de dados.
Exige rastreabilidade.
Exige impedir duplicidade.
Exige saber quando não alterar nada sem confirmação.
E só depois disso a IA pode tornar a experiência natural.
O princípio do JULIUS
A IA conversa. O sistema financeiro sustenta a verdade.
1. O que é o JULIUS?
JULIUS é um assistente financeiro particular que centraliza informações de finanças familiares e pessoais.
No projeto analisado, ele trabalha com:
- receitas;
- despesas;
- compras;
- consumo;
- abastecimentos;
- parcelamentos;
- cartões e faturas;
- pagamentos;
- contas bancárias e carteiras;
- saldos;
- transferências;
- comprovantes;
- importações;
- conciliações;
- veículos;
- manutenções;
- quilometragem;
- histórico e auditoria.
Mas a interface mais interessante não é necessariamente uma tela.
É a linguagem natural.
Você pode informar uma despesa como uma pessoa fala:
“Gastei 12 reais no café.”
Ou registrar um abastecimento por áudio.
Ou mandar a fotografia de um cupom.
Ou, depois que o histórico existe, perguntar:
“Quanto gastamos este mês?”
A diferença é que a resposta não vem da memória do modelo. Ela vem das operações publicadas pela própria API financeira.
2. Texto, voz, foto e WhatsApp: finanças entrando do jeito que a vida acontece
O fluxo original do JULIUS foi desenhado em torno de um grupo financeiro no WhatsApp.
A Evolution API recebe as mensagens. O backend identifica se a entrada é texto, áudio ou imagem.
Texto vai para interpretação.
Áudio é transcrito antes de ser interpretado.
Imagem pode ser enviada ao modelo multimodal para leitura de documentos financeiros.
Uma conversa vira banco de dados
O usuário não precisa pensar primeiro em formulário.
Esse detalhe é mais importante do que parece.
O melhor sistema financeiro não é o que possui mais campos. É o que reduz a distância entre o momento em que algo acontece e o momento em que aquilo é registrado.
3. A foto do cupom não vira “Supermercado R$ 487”. Ela pode virar a compra inteira.
Esse é um dos recursos mais interessantes do projeto.
O prompt de leitura de documentos foi construído para não tratar um cupom como uma única despesa genérica.
Se existem dez itens diferentes legíveis, a orientação é gerar dez eventos.
Se existem cem itens, a orientação é gerar cem eventos.
Cada produto pode carregar:
- descrição;
- quantidade;
- unidade;
- valor unitário;
- valor total;
- estabelecimento;
- forma de pagamento;
- categoria;
- nível de confiança.
Isso muda o tipo de pergunta que o sistema consegue responder depois.
O cupom deixa de ser uma fotografia
Ele passa a ser uma base de consumo.
Agora imagine isso acontecendo durante meses.
O sistema deixa de saber apenas quanto foi gasto em supermercado. Ele passa a ter memória sobre o que foi comprado, onde, quando e por quanto.
4. Classificação automática: o dado entra bagunçado e precisa sair utilizável
Texto humano é ambíguo.
“Paguei a luz.” “Comprei carne.” “Recebi salário.” “Abasteci.” “Comprei no crédito.”
O modelo transforma essas frases em uma estrutura financeira com campos previsíveis.
O projeto diferencia ações como receita, despesa, compra, abastecimento e consumo. Também utiliza categorias amplas como alimentação, moradia, transporte, saúde, lazer, cartão e outras.
Há regras específicas para documentos mais complexos.
Holerites, por exemplo, possuem heurísticas próprias para separar proventos de descontos, reconhecer salário, auxílio-alimentação, previdência, IRRF, empréstimos consignados e outros itens.
O objetivo não é ter uma IA “criativa”. É justamente o contrário: transformar linguagem livre em estrutura previsível.
5. E quando você corrige o JULIUS? A correção pode virar memória para a próxima vez.
Esse recurso merece destaque.
O sistema possui uma tabela específica de aprendizado baseada em correções manuais.
Quando um lançamento é corrigido, o JULIUS pode gerar uma espécie de assinatura — uma fingerprint — usando elementos como texto, identificação de boleto, CNPJ, favorecido e valor.
Essa assinatura é ligada aos campos que o usuário corrigiu.
Quando algo semelhante aparece no futuro, o sistema procura essa memória antes de depender apenas do modelo generativo.
O usuário corrige uma vez. O sistema tenta lembrar depois.
Aprendizado operacional aplicado a lançamentos recorrentes.
Não é “retreinar o modelo da OpenAI”. É algo mais controlável: preservar as decisões do usuário e reutilizá-las quando o contexto combina.
6. Quando cada item é salvo, nasce uma memória de preços
Aqui começa uma das partes mais poderosas.
Se um cupom é armazenado apenas como:
Supermercado — R$ 482,30
você sabe quanto gastou.
Mas se ele é desmontado em produtos, quantidades, preços e estabelecimento, outras perguntas passam a ser possíveis.
Por exemplo:
- quanto gastei com carne este mês?
- em quais estabelecimentos comprei determinado produto?
- qual foi o último preço registrado?
- onde paguei menos por um corte semelhante?
- quanto o preço de um item variou ao longo do tempo?
- quanto da compra mensal foi alimentação, higiene ou outras categorias?
É importante fazer uma ressalva: comparar “qual açougue é mais barato” exige comparar registros equivalentes — mesmo produto, corte, unidade, qualidade e período quando isso for relevante.
Mas o sistema cria justamente a matéria-prima para essa análise.
É aí que controle financeiro começa a se aproximar de inteligência de consumo.
7. O melhor painel pode ser uma pergunta: “JULIUS, quanto eu gastei?”
O projeto possui uma camada de consultas em linguagem natural.
Ela não entrega o banco inteiro ao modelo e torce para ele acertar.
O backend constrói um catálogo de ferramentas a partir das operações GET publicadas na própria OpenAPI. O modelo escolhe a operação adequada, recebe o resultado real da API e só então escreve uma resposta natural.
Exemplos já cobertos em testes:
- “Qual o meu saldo?”
- “Quanto gastamos este mês?”
- “Quais foram os últimos lançamentos?”
Como a operação de lançamentos aceita filtros por período, categoria, pessoa, descrição, estabelecimento, conta, cartão, veículo e valores, o mesmo conceito permite consultas mais específicas sobre aquilo que foi registrado.
Natural por fora. Estruturado por dentro.
A resposta só deve existir depois que uma ferramenta consultou a fonte financeira.
Essa arquitetura reduz um dos maiores riscos de um assistente financeiro: inventar números porque “parecem plausíveis”.
8. Cartão de crédito: consumo hoje, pagamento depois — sem contar duas vezes
Cartão é um dos pontos em que controles financeiros simples costumam se confundir.
Você compra hoje, consome hoje, mas paga a conta bancária depois.
Se o software registrar a compra como despesa e depois registrar o pagamento da fatura como outra despesa igual, o mesmo consumo aparece duas vezes.
O JULIUS possui uma estrutura própria para evitar isso.
O cadastro do cartão contém tipo, dia de fechamento, dia de vencimento e regra para compras feitas no próprio dia de fechamento.
Uma função central calcula em qual ciclo cada compra entra.
Parcelas preservam a compra original, mas são distribuídas pelos ciclos de vencimento.
O pagamento da fatura reduz a conta bancária, enquanto o consumo já permanece registrado nos itens da fatura.
Consumo e caixa são coisas diferentes
O sistema precisa preservar os dois sem duplicar a despesa.
Esse tipo de detalhe é o que transforma um registrador de gastos em um sistema financeiro coerente.
9. Conciliação inteligente: quando o histórico encontra a fatura
Dados financeiros chegam de diferentes lugares.
Parte é lançada na hora. Parte chega por extrato. Parte aparece na fatura. Parte foi registrada antes de o cadastro do cartão estar completo.
O projeto possui fluxos de conciliação para colocar essas peças em acordo.
No módulo de crédito existe uma operação em lote que localiza compras antigas ainda sem fatura e simula como elas deveriam ser vinculadas.
O fluxo segue uma regra de segurança:
- primeiro executa um dry-run;
- gera um preview;
- calcula um hash daquele estado;
- mostra o que é reconciliável e o que ficou pendente;
- só depois de autorização aplica;
- se os dados mudaram desde o preview, a operação é rejeitada.
Também existem estruturas para importação e reconciliação de movimentos externos, com pares entre linha externa e lançamento interno.
Significa automatizar o que é seguro, simular antes quando existe risco e deixar ambiguidade para revisão humana.
10. Contas, saldos e transferências: saber quanto gastou não é o mesmo que saber quanto tem
O JULIUS também modela contas financeiras.
Existe diferença entre:
- saldo inicial;
- saldo calculado;
- saldo confirmado;
- saldo estimado atual;
- movimentação interna;
- ajuste de saldo;
- receita;
- despesa.
Uma transferência entre duas contas próprias, por exemplo, não cria renda nem despesa. Ela apenas move patrimônio.
O projeto possui uma operação específica para isso.
Da mesma forma, uma compra no cartão não reduz imediatamente a conta bancária. Quem reduz a conta é o pagamento da fatura.
Essas distinções fazem com que perguntas sobre saldo tenham uma base contábil muito mais consistente.
11. Casa e carro: eu não dividiria o JULIUS. Um cérebro financeiro, dois contextos.
O projeto possui um domínio doméstico muito forte: supermercado, alimentação, contas, salários, cartões, bancos, pagamentos, documentos e orçamento.
Também possui um domínio de veículo igualmente interessante: abastecimento, quilometragem, manutenção, componentes, custos e próxima troca.
Seria possível criar um “JULIUS Casa” e um “JULIUS Carro”.
Mas arquiteturalmente existe uma vantagem maior em manter os dois dentro do mesmo cérebro.
Porque o carro também é dinheiro da casa.
Combustível impacta o orçamento.
Seguro, manutenção e peças impactam fluxo de caixa.
Uma troca de óleo paga no cartão pertence ao veículo, mas também pertence a uma fatura e a uma conta que será usada para pagar essa fatura.
Um cérebro. Vários contextos.
Separar a visualização faz sentido. Separar a verdade financeira, não.
A melhor evolução, portanto, é criar painéis e experiências especializadas para Casa e Carro, mas preservar uma única memória financeira por baixo.
12. O carro deixa de ser “gasolina” e vira um ativo com histórico
O módulo de veículos possui cadastro normalizado, quilometragem atual, manutenção e alertas consultivos.
Uma manutenção pode guardar:
- veículo;
- data do serviço;
- quilometragem;
- categoria;
- tipo de serviço;
- componente;
- intervalo em quilômetros;
- intervalo em meses;
- garantia;
- próxima troca;
- lançamento financeiro relacionado.
O abastecimento, por sua vez, já faz parte do modelo financeiro, com campos específicos para combustível, veículo e quilometragem.
Isso abre perguntas úteis:
- quanto este carro custou no ano?
- quanto foi gasto com combustível?
- qual foi a última troca de óleo?
- com quantos quilômetros ela aconteceu?
- qual é a próxima manutenção prevista?
- quanto já foi gasto em determinado componente?
Em vez de criar um aplicativo separado para carro, o JULIUS transforma o veículo em uma dimensão da própria vida financeira.
13. Comprovantes e documentos: a evidência pode ficar ligada ao lançamento
Uma linha no banco diz que algo foi pago.
Um comprovante mostra a evidência associada.
O projeto possui suporte a anexos persistentes relacionados a lançamentos, com armazenamento de metadados, hash SHA-256, origem, tamanho, tipo MIME e histórico de arquivamento.
Isso permite manter o documento ligado ao registro financeiro correspondente.
O mesmo princípio vale para fotos recebidas no fluxo de lançamento: o sistema preserva relacionamentos sem simplesmente despejar base64 no banco de mensagens.
Para auditoria pessoal, isso é extremamente útil.
14. GPT Actions: a IA não recebe “acesso ao banco”. Ela recebe ferramentas.
Essa talvez seja a decisão arquitetural mais importante do projeto.
O JULIUS publica uma OpenAPI específica para Actions.
Em vez de dizer ao modelo “aqui está o banco, faça o que quiser”, a aplicação oferece operações nomeadas e restritas.
Existem ferramentas para:
- listar lançamentos;
- resumir receitas e despesas;
- consultar contexto financeiro;
- listar contas;
- consultar saldos;
- listar cartões;
- consultar faturas;
- listar compras de uma fatura;
- criar ou editar lançamento em fluxos autorizados;
- anexar documento;
- baixar lançamento;
- pagar fatura;
- reconciliar compras de crédito;
- transferir entre contas.
No modo conversacional de consulta, o catálogo é ainda mais restrito: o orquestrador utiliza operações GET para buscar dados antes de responder.
LLM com ferramentas, não com liberdade irrestrita
A linguagem natural escolhe uma operação; a API continua mandando nas regras.
15. Escrever dinheiro exige mais cuidado do que consultar dinheiro
O código reflete essa diferença.
Operações de escrita possuem mecanismos como:
- Bearer específico;
- idempotency_key para evitar repetir uma alteração;
- operation_id para rastrear cada operação;
- dry_run em fluxos sensíveis;
- expected_version para impedir alterações sobre uma versão desatualizada;
- auditoria de antes e depois;
- soft delete em vez de apagar histórico;
- regras específicas para pagamento e reconciliação.
Até o webhook do WhatsApp possui idempotência por message_id, evitando duplicação quando a plataforma reenvia o mesmo evento.
Esse tipo de engenharia raramente aparece em uma demonstração bonita, mas é o que impede um assistente financeiro de virar uma máquina de duplicar lançamentos.
16. Por trás do JULIUS: FastAPI, SQLite, OpenAI, Evolution, Docker e Traefik
O backend atual utiliza FastAPI e Pydantic. A persistência está em SQLite com migrations versionadas, WAL, foreign keys, backups e verificações de integridade.
A comunicação com o WhatsApp passa pela Evolution API.
A inteligência artificial é consumida por APIs da OpenAI para interpretação, visão, transcrição e orquestração de ferramentas.
A aplicação é empacotada em Docker e exposta em infraestrutura com Traefik e HTTPS.
Arquitetura simplificada do JULIUS
Uma experiência natural apoiada por componentes especializados.
17. Onde o JULIUS realmente economiza tempo?
Não é porque a IA consegue escrever uma resposta elegante.
É porque tarefas pequenas deixam de se acumular.
Antes: digitar produto por produto do supermercado.
Depois: fotografar o cupom e revisar os itens extraídos.
Antes: lembrar de lançar o combustível quando chegar em casa.
Depois: falar o valor, litros e quilometragem.
Antes: abrir três faturas para descobrir o que vence no mês.
Depois: consultar a previsão financeira.
Antes: procurar um comprovante perdido.
Depois: manter o arquivo ligado ao lançamento.
Antes: tentar lembrar em qual açougue determinada carne estava mais barata.
Depois: recuperar o histórico de itens e estabelecimentos e comparar o que foi efetivamente registrado.
Antes: somar na mão quanto um veículo custou.
Depois: consultar lançamentos e manutenções vinculados ao veículo.
Antes: corrigir todo mês o mesmo boleto classificado de forma errada.
Depois: a memória de correções pode reconhecer a assinatura recorrente.
É retirar o máximo possível de trabalho entre o acontecimento real e a informação confiável.
18. O que esse conceito permite no futuro
Inteligência de consumo
Com histórico item a item, o sistema pode evoluir para comparações de preço, frequência de compra, variação de valores e cesta recorrente.
Planejamento doméstico
Casa, contas, cartões e previsões podem ser analisados em conjunto para antecipar meses mais apertados.
Gestão de veículos
Custos financeiros e eventos técnicos podem formar um custo total por veículo ao longo do tempo.
Assistente preventivo
Em vez de responder apenas quando perguntado, futuras automações podem destacar inconsistências, faturas incompletas, manutenções próximas ou despesas fora de um padrão definido pelo próprio usuário.
Busca semântica sobre documentos
Comprovantes e anexos podem ganhar camadas futuras de indexação para localizar evidências a partir de perguntas naturais.
Memória familiar compartilhada
Como o sistema já registra pessoa associada ao lançamento, diferentes participantes podem compor uma visão familiar sem perder a autoria de cada movimento.
Mais supervisão, não menos
Quanto maior a autonomia da IA, mais importante se torna saber onde ela pode agir sozinha e onde precisa simular, pedir autorização ou deixar a decisão para uma pessoa.
19. Perguntas frequentes
O JULIUS é um aplicativo de banco?
Não. Ele é um sistema particular de organização e inteligência financeira. Ele registra e modela informações financeiras, mas não substitui os sistemas oficiais das instituições.
Ele consegue registrar uma lista completa de supermercado?
Sim. O fluxo de leitura de documentos foi instruído a transformar cada item legível em um evento separado, preservando quantidade, unidade e valores quando disponíveis.
Ele pode responder “qual açougue foi mais barato”?
Se o histórico tiver produtos comparáveis, quantidades/unidades e estabelecimentos identificados, a camada de consulta tem os dados necessários para recuperar e comparar esses registros. A comparação deve respeitar equivalência entre os produtos.
Ele entende áudio?
Sim. O fluxo do WhatsApp transcreve áudio e depois interpreta o conteúdo financeiro.
Ele lê foto?
Sim. Imagens de cupons, comprovantes, boletos, notas, holerites e outros documentos financeiros podem ser interpretadas, respeitando legibilidade e confirmação quando houver ambiguidade.
Ele controla cartão?
Sim. Há cadastro de cartões, fechamento, vencimento, faturas, compras vinculadas, parcelamento, pagamentos e reconciliação.
Ele controla veículos?
Sim. Existe cadastro de veículos, quilometragem, abastecimentos, manutenções, componentes, custos e próximas trocas.
Por que usar Actions?
Porque o modelo pode escolher ferramentas específicas sem receber liberdade irrestrita sobre o banco. As regras financeiras continuam implementadas na API.
O JULIUS pode errar?
Sim. OCR, visão, transcrição e interpretação podem errar. Por isso o projeto possui confiança, confirmação, dry-run, auditoria, versionamento e aprendizado a partir de correções.
Seu dinheiro já conta uma história. O JULIUS foi criado para não deixar essa história se perder.
Compras, produtos, cartões, contas, comprovantes, carros e decisões deixam de viver em lugares separados e passam a formar uma memória financeira consultável por linguagem natural.
Conclusão: o futuro do controle financeiro talvez não seja abrir um aplicativo. Talvez seja simplesmente conversar.
Imagine um sistema que viu os cupons que você decidiu registrar.
Que sabe quais itens estavam dentro de cada compra.
Que conhece seus cartões, fechamento e vencimento.
Que diferencia consumo de pagamento de fatura.
Que sabe quando uma transferência não é renda.
Que relaciona combustível ao carro.
Que preserva manutenção e quilometragem.
Que guarda comprovantes.
Que lembra de correções que você fez no passado.
E que, depois de tudo isso, permite perguntar:
“JULIUS, quanto gastamos com carne nos últimos três meses e em quais lugares compramos?”
Ou:
“Quanto o carro custou este ano entre combustível e manutenção?”
Ou simplesmente:
“Quanto eu tenho e o que ainda vence este mês?”
É aí que a inteligência artificial deixa de ser uma camada decorativa.
Ela passa a ser a interface de uma memória financeira construída com regras, histórico e evidências.
A visão do JULIUS
Quanto mais simples fica registrar, mais poderosa fica a memória acumulada.
É ter uma IA que sabe perguntar ao seu próprio histórico, aplicar as regras corretas e devolver exatamente a informação que você precisa naquele momento.
JULIUS — de lançador de gastos a memória financeira inteligente.