DM Yan

Mestre Cronista

Retornar ao Hub

Open Finance e Monitoramento Financeiro

16 de out. de 2026Leitura de 34 min

Open Finance e Monitoramento Financeiro

Resumo

Para o monitoramento financeiro pessoal de Yan, há duas abordagens práticas: um agregador oficial de Open Finance, como a Pluggy, para sincronização estruturada; ou a captura de notificações do celular e envio para um webhook do n8n, para receber eventos quase em tempo real. A primeira é a opção mais adequada como fonte principal de dados; a segunda pode funcionar como complemento ou protótipo de baixo custo.

Por que é relevante para Yan

O projeto Home Finance Tracker já prevê múltiplas contas, cartões, faturas, reconciliação bancária, receitas de RPG e alertas. A integração automática reduz a manutenção manual que tornou o Firefly III pouco conveniente para esse uso e pode alimentar o ledger e os fluxos existentes de n8n.

Opções de integração

Agregador via Open Finance

Confirmado por fonte externa, consultada em 2026-10-16: a documentação da Pluggy descreve conectores de Open Finance regulado que seguem o modelo de dados da plataforma, incluindo itens, contas e transações. A API também documenta transações de cartão e consulta por fatura. O fluxo exige consentimento do usuário na instituição financeira; não é uma API aberta para ignorar autenticação ou consentimento.

Fluxo proposto:

  1. Autorizar cada instituição na interface de consentimento do provedor.
  2. Sincronizar contas, saldos, transações e dados de cartão por um job diário ou periódico.
  3. Normalizar os dados no Home Finance Tracker.
  4. Deduplicar por identificador externo e reconciliar divergências antes de gerar alertas.
  5. Manter tokens e segredos fora do vault e fora de mensagens ou logs públicos.

Vantagens: dados estruturados, menor dependência de scraping e melhor cobertura para extratos e cartões.

Cuidados: cobertura, produtos disponíveis, frequência de atualização, limites e preço variam por instituição e plano; validar cada conector antes de adotar a integração como fonte contábil definitiva.

Notificações do Android para webhook

Confirmado por fonte externa, consultada em 2026-10-16: a documentação do MacroDroid lista gatilhos relacionados a notificações e ações para chamar serviços web. Uma macro pode filtrar notificações bancárias e enviar um POST ao n8n com o texto recebido.

Fluxo de protótipo:

  1. Filtrar apenas notificações dos aplicativos bancários autorizados.
  2. Extrair valor, tipo, estabelecimento e data sem enviar credenciais, códigos ou conteúdo desnecessário.
  3. Enviar o evento para um webhook protegido do n8n.
  4. Classificar como pendente até a confirmação por uma fonte bancária ou por conciliação posterior.

Vantagens: baixo custo inicial e baixa latência para compras, Pix e cobranças notificadas.

Limitações: notificações podem ser alteradas, atrasadas, agrupadas ou não disparadas; o texto pode não conter todos os campos necessários. Portanto, esse caminho não deve ser a única fonte de verdade para saldos, faturas ou impostos.

Decisão atual

Provável: começar pelo agregador de Open Finance como fonte estruturada e usar notificações via n8n apenas como sinal de evento ou fallback. Antes de implementar em produção, comparar cobertura, custo, estabilidade e dados de cartão da Pluggy com as instituições efetivamente usadas.

Não armazenar neste vault credenciais bancárias, tokens de consentimento, cookies, números completos de conta/cartão, identificadores privados ou conteúdo bruto de notificações.

Relações no vault

Atualização operacional — 2026-10-16

Confirmado por relato local: Yan já integrou cinco bancos ao Pluggy e quer avaliar a inclusão das contas da esposa, além de sincronizar os dados com o Firefly III e um watcher do Hermes.

Confirmado por documentação atual da Pluggy: o caminho gratuito para uso pessoal é o Meu Pluggy, com até cinco conexões ativas do mesmo titular e atualização automática própria do serviço. O limite de cinco não deve ser generalizado para todos os planos ou ambientes da API: a documentação também descreve limites diferentes para sandbox/desenvolvimento e para uso comercial.

Decisão técnica recomendada: tratar o limite como uma restrição de titularidade e produto, não criar uma segunda conta como workaround automático. Uma conta separada da esposa pode ser investigada somente se o uso, consentimento, titularidade dos dados e termos da Pluggy forem compatíveis; não persistir credenciais no vault. Enquanto isso, o sincronizador deve aceitar múltiplas fontes de credenciais por configuração externa e rotular as contas por titular, sem misturar segredos ou dados brutos no repositório.

Integração com Firefly III: a deduplicação por external_id é compatível com a documentação do Firefly III, que permite pesquisar esse campo e usá-lo para detectar duplicatas. Isso é uma estratégia de implementação, não prova de que o identificador entregue pela Pluggy seja globalmente único: o sincronizador deve compor uma chave estável com a origem/item quando necessário e testar transações pendentes versus confirmadas.

Status do watcher: o desenho Pluggy → sincronizador/n8n → Firefly III → alertas do Hermes permanece uma proposta de automação; o lote não fornece evidência de que essa integração já esteja implementada ou validada em produção.

Fontes

Segurança operacional para credenciais

Decisão: nunca enviar client_secret, tokens, cookies, senhas ou cabeçalhos de autorização pelo chat, nem persistir esses valores no vault, no batch de captura ou em logs. A configuração deve ficar fora do conteúdo versionado, em arquivo local protegido ou em um gerenciador de segredos; o sincronizador deve receber apenas a configuração necessária em tempo de execução. O arquivo local também deve ser excluído do Git e ter permissões restritas.

A orientação do lote para compartilhar chaves diretamente na conversa foi tratada como inadequada e não deve ser repetida. O fato de um serviço estar rodando ou de um sincronizador ter sido declarado como “testado” na conversa não substitui a verificação independente de filesystem, execução e leitura de retorno antes de registrar o status como produção.

Atualização operacional — custo do Pluggy e alternativa por e-mail

Relato local, ainda não verificado externamente: ao abrir o dashboard da Pluggy, Yan percebeu o início aparente de um trial associado a um plano pago e sinalizou que não deseja assumir uma mensalidade corporativa. O valor mencionado na conversa não foi tratado como preço confirmado. O status de cobrança, método de pagamento e condições do trial devem ser conferidos diretamente em Billing/Subscription e, se necessário, com o suporte oficial; não presumir que a ausência de cartão ou contrato elimine automaticamente qualquer obrigação.

Decisão de arquitetura: não avançar com uma integração paga da Pluggy sem confirmar explicitamente o plano, o trial, os limites e a forma de cobrança. Como alternativa de baixo custo, avaliar um fluxo baseado em notificações por e-mail dos bancos:

  1. Aplicar uma etiqueta/filtro às mensagens financeiras autorizadas.
  2. Receber as mensagens no n8n por Email Trigger (IMAP) ou Gmail Trigger.
  3. Extrair somente data, valor, instituição, tipo e estabelecimento; descartar credenciais, códigos e conteúdo desnecessário.
  4. Enviar a transação para o Firefly III local após validação, normalização e deduplicação.
  5. Marcar o registro como pendente quando o e-mail não trouxer dados suficientes para conciliação.

Esse fluxo é uma proposta de protótipo, não evidência de implementação ou validação em produção. E-mails podem atrasar, faltar ou conter campos incompletos; portanto, não devem ser a única fonte de verdade para saldo, fatura ou obrigações fiscais. Credenciais IMAP/Gmail devem permanecer nas credenciais protegidas do n8n, fora do vault e de logs.

Localização operacional dos identificadores no dashboard

Confirmado por evidência visual local, consultada em 2026-10-16: no painel em português da Pluggy, os bancos conectados podem ser inspecionados pelo menu Dados Financeiros, nas áreas Execuções ou Eventos. Essas telas exibem as execuções de login/conexão e os eventos de criação correspondentes; ao abrir uma entrada, o painel apresenta o identificador da conexão/item.

Esse procedimento serve para localizar IDs durante diagnóstico e configuração do sincronizador, mas os identificadores não devem ser copiados para o vault, para mensagens ou para logs públicos. Os rótulos e a organização do dashboard podem mudar; confirmar a tela diretamente antes de atualizar procedimentos operacionais.

Fluxo pessoal via Meu Pluggy — atualização operacional

Confirmado por documentação oficial da Pluggy, consultada em 2026-10-16: o fluxo de uso pessoal não exige contratar o plano comercial nem termina com o trial. No Dashboard, o usuário deve abrir a aplicação, entrar em Demo e usar Connect Account; no widget, deve selecionar o conector MeuPluggy, em vez de escolher diretamente um banco ou o Sandbox. Cada banco já conectado no Meu Pluggy aparece como um item da aplicação e é atualizado automaticamente pelo serviço.

Para obter um identificador sem persistir segredo no vault:

  1. Acessar a página Demo da aplicação no Dashboard.
  2. Abrir Connected Items.
  3. Selecionar o item correspondente e copiar o itemId apenas para a configuração protegida do sincronizador.
  4. Manter clientId, clientSecret, API keys e demais credenciais fora do vault, do chat e dos logs.

A documentação oficial informa que esse caminho é pessoal, limitado a até cinco conexões e não deve ser tratado como autorização para uso comercial. A disponibilidade e os rótulos da interface podem mudar; confirmar o painel antes de atualizar o procedimento.

Validação do sincronizador Pluggy → Firefly III — 2026-10-16

Confirmado por teste local em modo seguro: cinco conexões foram consultadas contra a API da Pluggy. Quatro retornaram contas e transações normalmente; uma não retornou contas na primeira consulta. O teste dry-run encontrou 110 lançamentos e não gravou nenhum lançamento no Firefly III.

Correção de integração: o sincronizador deve usar GET /v2/transactions, com paginação por cursor. A API oficial marca o endpoint antigo baseado em páginas como depreciado; a documentação também confirma que transações de faturas abertas e parcelas futuras chegam como PENDING até afetarem o saldo devido.

Bloqueios antes da importação real: não importar parcelas futuras como despesas já realizadas; o cartão observado contém lançamentos futuros até 2027. Pagamentos de fatura também podem aparecer no cartão e na conta bancária, portanto a reconciliação precisa identificar e excluir a duplicidade antes de escrever no Firefly III. A importação real permanece bloqueada até essas regras serem implementadas e testadas.

Segurança: nenhum identificador de conexão, token, segredo ou cabeçalho de autorização foi persistido nesta nota. O acesso ao Firefly III deve continuar em configuração protegida, fora do vault, do chat e dos logs.

Fontes adicionais

Registro de captura — 2026-10-16

Confirmado por relato local: uma execução de dry-run do sincronizador financeiro identificou 84 transações dos últimos 15 dias, abrangendo Nubank, PicPay, Inter e InfinitePay, e reportou conexão com uma instância Firefly III v6.7.9. O registro não confirma gravação de transações no Firefly III nem deve ser interpretado como validação de produção.

A credencial recebida, o token, o caminho exato de configuração e quaisquer identificadores de conta foram deliberadamente omitidos desta nota. O status efetivo da integração deve continuar sendo verificado por execução independente e leitura do retorno, não apenas por uma mensagem de sucesso.

Objetivo operacional — conciliação Pluggy → Firefly III

Decisão de escopo: o fluxo deverá sincronizar os últimos 30 dias de contas bancárias e cartões conectados ao Pluggy, incluindo Nubank, PicPay, Inter e InfinitePay, e lançar os dados no Firefly III após normalização, deduplicação e conciliação.

Requisitos funcionais:

  1. Categorizar as transações e preservar a descrição original quando houver parcelamento no crédito.
  2. Registrar somente a parcela incidente no ciclo atual; lançamentos futuros devem permanecer pendentes até afetarem o saldo devido.
  3. Detectar e vincular transferências entre contas de mesma titularidade como transferências internas, sem classificá-las como receita ou despesa.
  4. Conferir faturas de cartão e eliminar duplicidades entre o pagamento da fatura e os lançamentos correspondentes.
  5. Gerar um relatório Markdown estruturado com totalizadores de Entradas Reais, Despesas Fixas/Variáveis, Faturas de Cartão e Saldo Consolidado.

Critérios de validação:

  • A execução do sincronizador deve terminar sem erros.
  • O banco SQLite local do sincronizador e os mecanismos de idempotência do Firefly III devem impedir colisões e lançamentos duplicados.
  • O resultado deve ser conferido por leitura independente do Firefly III e por reconciliação dos totalizadores; uma mensagem de sucesso isolada não valida produção.

Status: objetivo operacional documentado; a execução de sincronização e a gravação no Firefly III não foram comprovadas pelo lote e permanecem pendentes de validação independente. Configurações, tokens, identificadores de contas e credenciais continuam fora do vault.

Registro de execução Pluggy → Firefly III — 2026-10-16

Relato local do lote, com confirmação parcial por retorno de execução: o sincronizador coletou 110 transações da Pluggy, ignorou 36 parcelas futuras de cartão e encontrou 74 registros já sincronizados no banco SQLite local. A reexecução não publicou operações duplicadas. O retorno também informa saldo consolidado de R 8.194,40 em entradas e R$ 5.177,50 em despesas no período de 01/10 a 16/10/2026.

O retorno declara quatro faturas reconciliadas como transferências, no total de R 4.632,92. Esses valores são evidência do retorno do processo, mas o lote não inclui leitura independente posterior da API nem os identificadores necessários para auditar cada lançamento; portanto, não devem ser tratados como prova definitiva de estado contábil.

Regras operacionais confirmadas pelo retorno:

  • Parcelas futuras de cartão, com vencimento posterior a outubro de 2026, não devem ser importadas como despesas realizadas.
  • Pagamentos de fatura e transferências entre contas próprias devem ser registrados como transfer, evitando duplicar saídas ou receitas.
  • A idempotência deve usar o banco local synced_transactions.db e uma chave external_id vinculada ao identificador externo da origem; a composição precisa permanecer estável quando a origem ou o item forem necessários para evitar colisões.
  • O balanço informado deve ser conferido por leitura independente do Firefly III e por reconciliação dos totalizadores antes de considerar a integração validada em produção.

Não persistir tokens, cabeçalhos, credenciais, IDs privados ou dados bancários completos nesta nota.

Detalhes da verificação de retry

Confirmado pelo retorno local da execução: a verificação precisou corrigir dois problemas operacionais: a chamada a /api/v1/summary/basic precisava incluir start e end, e a consulta SQLite deveria usar synced_transactions em vez de synced. Após a correção, o retorno foi VERIFY_OK.

A auditoria reportou 74 transações idempotentes no banco local, distribuídas em 19 depósitos, 20 pernas de transferências pareadas e 35 despesas. O relatório também separou quatro pagamentos de fatura, totalizando R 4.632,92. Esses números continuam sujeitos à ressalva de que o lote não contém uma leitura independente posterior da API; não são prova definitiva de estado contábil sem reconciliação externa.

Fonte local anterior: lote de knowledge capture /home/ubuntu/.hermes/plugin-data/obsidian-knowledge-capture/nodes/foundry/batches/batch-a5cb48249c8544c6be85a25912fb7474.json, evento 2eef927dabb454d685f9f894, consultado em 2026-10-16.

Fonte do lote anterior: C:\Users\Yanbd\AppData\Local\hermes\plugin-data\obsidian-knowledge-capture\nodes\yan-B450M\batches\batch-65ce72027db54ba2a7a5413bebbf426f.json, evento cfb9a917aefd7960760a2edd, consultado em 2026-10-16.

Inventário de cobertura e histórico — 2026-10-16

Confirmado por relato local, com dados sensíveis minimizados: a sincronização pessoal tem sete produtos ativos distribuídos entre Nubank, PicPay, Banco Inter e InfinitePay, abrangendo contas de movimentação, cartões e recebimentos. Os nomes internos das contas, finais de cartões, identificadores e contagens individuais de transações foram deliberadamente omitidos.

Confirmado pela documentação da Pluggy: a API de transações pode recuperar até 12 meses de dados; isso é uma capacidade documentada do produto, não uma garantia de que cada instituição ou produto terá exatamente essa profundidade. No inventário observado, a data inicial variou por produto, aproximadamente entre 16/10/2025 e 08/11/2025. A execução local consultou os últimos 15 dias e reportou mais de 1.800 transações disponíveis para eventual sincronização histórica.

Decisão operacional: ampliar a janela somente por execução explícita do sincronizador (--days 90, --days 180 ou --days 365), preservando idempotência, reconciliação de faturas e classificação de transferências. A disponibilidade histórica deve ser tratada como variável por produto e validada na resposta da API; não registrar credenciais, números de conta/cartão, tokens ou IDs privados.

Fonte local: lote de knowledge capture C:\Users\Yanbd\AppData\Local\hermes\plugin-data\obsidian-knowledge-capture\nodes\yan-B450M\batches\batch-4c51ac599d1b44eda41496d0567c2f64.json, evento c5dde42f14a6a66d2e1fd4b6, consultado em 2026-10-16.

Fonte externa: Pluggy — Transactions, documentação oficial consultada em 2026-10-16.

Parcelamento no Firefly III — atualização operacional — 2026-10-16

Confirmado por fontes públicas do projeto, consultadas em 2026-10-16: o Firefly III não oferece, no fluxo documentado, um recurso nativo para cadastrar uma compra de cartão como um plano de parcelas com geração e acompanhamento automático. A issue #548 registra a limitação histórica para compras parceladas; a issue #10073 continua como solicitação de suporte a parcelas mensais. A documentação também descreve cartões como contas de ativo destinadas à administração, sem tratamento especial automático para parcelamento.

A alternativa compatível com esse limite é registrar cada parcela quando ela efetivamente ocorrer e, quando for necessário projetar compromissos futuros, criar transações datadas no futuro ou usar transações recorrentes/API com cautela. A orientação do mantenedor na issue #3361 confirma que transações futuras manuais ou automação via API são o caminho de contorno, não um módulo nativo de parcelamento. Discussões da comunidade no r/FireflyIII mostram que a escolha entre lançar o total na compra ou apenas as parcelas depende do modelo de controle adotado; para o fluxo de Yan, a regra operacional deve continuar distinguindo despesa realizada, parcela futura e pagamento da fatura.

Relato local do lote, não verificado de forma independente neste processamento: o sincronizador foi ajustado para consultar uma janela padrão de 365 dias, incluir parcelas já incidentes e pré-agendar parcelas futuras com uma anotação no formato Parcela N/total — fatura prevista YYYY-MM. O retorno declara 1.820 transações após reconstrução da idempotência, 26 parcelas futuras agendadas e 10 parcelas de outubro anteriormente descartadas; esses números devem ser tratados como evidência do retorno da execução, não como prova de estado contábil sem leitura posterior da API e reconciliação.

Regras de implementação registradas pelo lote:

  • Detectar uma parcela que se materializou com data ou valor deslocado e corrigir a transação existente por atualização, sem publicar uma duplicata.
  • Não classificar automaticamente todo lançamento PENDING como compra futura: o status pode representar uma fatura ainda não paga.
  • Exigir evidência da perna negativa no cartão ao identificar pagamentos de fatura, para evitar que descrições contendo “fatura” sejam pareadas por engano.
  • Manter a idempotência baseada em identificador externo estável, composto com a origem/item quando necessário, e validar o resultado por leitura independente do Firefly III.

Fontes adicionais:

Wise no Pluggy — avaliação operacional — 2026-10-16

Relato local do lote: Yan perguntou sobre a possibilidade de acompanhar movimentações da Wise pelo Pluggy. A resposta operacional indicou que o conector Wise está disponível e que a conexão deve ser feita pelo fluxo do Meu Pluggy, mantendo o itemId somente na configuração protegida do sincronizador. O lote não contém o itemId, credenciais ou evidência de uma conexão efetivamente criada; portanto, a inclusão ainda não está validada.

Confirmado por documentação oficial da Pluggy, consultada em 2026-10-16: Wise aparece na tabela pública de cobertura com contas e transações, mas sem suporte indicado para cartões de crédito. A documentação do Meu Pluggy define o caminho para uso pessoal, com até cinco conexões, e orienta escolher o conector MeuPluggy na página Demo da aplicação, não o banco diretamente. Cada banco conectado exige autorização própria.

Decisão operacional: antes de incorporar a Wise ao ledger, confirmar se a conta é pessoal ou empresarial e verificar no painel a cobertura efetiva do produto e das moedas usadas. A documentação consultada não comprova, por si só, como cada saldo ou transação multimoeda será exposto no sincronizador. Preservar a moeda original quando retornada pela API ou mapear contas por moeda; qualquer conversão para BRL deve ser uma etapa explícita, com taxa e data registradas fora desta nota. Não copiar itemId, tokens, credenciais ou identificadores de conta para o vault.

Importação de faturas de cartão por PDF — atualização operacional — 2026-10-17

Relato local do lote, sem validação de execução neste processamento: PDFs de faturas de outros cartões podem ser tratados como uma fonte adicional para o Firefly III. O fluxo proposto é extrair data, valor e descrição, apresentar uma tabela em dry-run para conferência e somente depois publicar os lançamentos. PDFs escaneados exigem OCR; nenhum PDF, dado bancário completo ou credencial deve ser persistido nesta nota.

Regras de processamento propostas:

  • Criar a conta de cartão no Firefly III somente se ela não existir; validar previamente o schema da API e os campos específicos de conta de cartão.
  • Registrar compras da fatura como withdrawal com um external_id estável, composto com o hash do PDF e a sequência do lançamento, ou outra chave equivalente que permaneça estável entre reprocessamentos.
  • Registrar o pagamento da fatura vindo da conta bancária como transfer, não como despesa, para evitar bitributação.
  • Agendar parcelas futuras com data futura; não tratá-las como despesas realizadas no ciclo atual.
  • Manter um banco local de transações sincronizadas e reprocessar o mesmo PDF sem duplicar lançamentos.
  • Preferir Open Finance quando houver conector confiável para o banco: o extrato diário oferece dados mais completos e reduz a dependência de reconstrução manual da fatura.

A fatura é um extrato mensal agrupado, não necessariamente o extrato transacional completo. Antes de implementar, decidir se o objetivo é reconstruir compras linha a linha ou registrar apenas o total da fatura e seu pagamento. O fluxo deve permanecer bloqueado para escrita real até a tabela extraída ser revisada e a idempotência ser testada.

Fonte local: lote de knowledge capture /home/ubuntu/.hermes/plugin-data/obsidian-knowledge-capture/nodes/foundry/batches/batch-7c91e3daf5bd4b2d9d615df728354d7f.json, evento c9f974df6524b354414d18cd, consultado em 2026-10-17.

Fontes adicionais:

Titularidade separada no Pluggy — atualização operacional — 2026-10-17

Relato local do lote: para incluir contas da esposa no fluxo financeiro, foram consideradas duas alternativas: conectar as contas na mesma conta Pluggy, se ainda houver capacidade aplicável ao produto em uso, ou usar uma conta/aplicação própria dela. Em ambos os casos, o sincronizador deve manter o titular como dimensão explícita e rotular as contas no Firefly III, sem misturar dados ou credenciais.

Confirmado pela documentação oficial da Pluggy: uma integração via API usa CLIENT_ID e CLIENT_SECRET para obter uma API key temporária; esses valores são credenciais de configuração e não devem ser enviados pelo chat nem persistidos no vault. No Dashboard, a área de itens conectados permite localizar o itemId de cada conexão. Para uso pessoal via Meu Pluggy, a documentação orienta selecionar o conector MeuPluggy no fluxo da aplicação, e não assumir que qualquer limite de conexões da modalidade pessoal se aplique a todos os planos ou ambientes.

Procedimento seguro:

  1. Confirmar a titularidade, o produto Pluggy e os limites vigentes antes de criar uma segunda conexão.
  2. Se for usada uma aplicação própria, obter as credenciais no Dashboard e mantê-las em configuração protegida, fora do repositório e do vault.
  3. Conectar os bancos pelo fluxo autorizado do Meu Pluggy e guardar apenas os itemIds na configuração protegida do sincronizador.
  4. Associar cada item ao titular correto e usar uma chave de idempotência composta pela origem, pelo item e pelo identificador externo da transação quando necessário.
  5. Criar ou localizar contas correspondentes no Firefly III com rótulos de titularidade, reconciliando transferências Pix entre contas da casa sem classificá-las como receita ou despesa.

Status: a necessidade de suportar mais de um titular é conhecimento operacional útil, mas o lote não prova que a conta da esposa foi criada, que uma conexão foi autorizada ou que a sincronização multiusuário foi validada em produção.

Fontes adicionais:

Execução relatada Pluggy → Firefly III — 2026-10-17

Relato operacional local, não verificado independentemente nesta curadoria: o fluxo teria sincronizado contas adicionais com o Firefly III, pareado transferências internas e agendado parcelas futuras. O lote não inclui leitura posterior da API, reconciliação dos saldos ou identificadores auditáveis; portanto, isso atualiza o estado para execução relatada, não para integração validada em produção.

Antes de tratar o fluxo como confiável, reler o Firefly III, conferir a idempotência e reconciliar os totalizadores. Não registrar neste vault valores individuais, nomes de titulares, números de contas/cartões, credenciais, tokens ou identificadores privados.

Fonte local: lote C:\Users\Yanbd\AppData\Local\hermes\plugin-data\obsidian-knowledge-capture\nodes\yan-B450M\batches\batch-fb5891b658614527b7ca2aa5e9a749c9.json, evento 5144ec4b3a0eba274f495739, consultado em 2026-10-17.

Relatório financeiro Midas — 2026-10-18

Relato operacional local, sem validação independente adicional nesta curadoria: foi gerado um relatório financeiro em PDF com gráficos para visualizar fluxo mensal de entradas, despesas, parcelas futuras, comparação entre titulares, recorrências, receitas, saídas, encargos, atrasos, juros, parcelamentos e percentuais planejados versus observados. O relatório também incluiu um plano de ação financeiro.

A sincronização apresentou falhas parciais na primeira execução por causa da identificação de uma conta intermediária. A correção passou a detectar o banco pelo campo marketingName. Uma execução posterior em modo de conferência encontrou 2.597 transações já registradas no banco local e não encontrou novos lançamentos pendentes. Isso é evidência do retorno local, não prova independente de que todos os registros estejam corretos no Firefly III.

Decisões e cuidados: manter o relatório como artefato de análise, não como fonte contábil; conferir divergências diretamente no Firefly III; preservar a idempotência do banco local; e não registrar no vault o PDF, credenciais, tokens, identificadores de conta ou dados bancários completos.

Fonte local: lote /home/ubuntu/.hermes/plugin-data/obsidian-knowledge-capture/nodes/foundry/batches/batch-40da42d415644eaa835f3c244d518c1c.json, evento 701414cdeb95ac7f6a2b04f3, consultado em 2026-10-18.

Relatório financeiro consolidado com gráficos — 2026-10-17

Relato local do lote: foi gerado um PDF de análise financeira com visualizações de composição de renda, orçamento Midas 50/30/20 e evolução histórica de seis meses. O resumo informado apresenta a composição de renda como Yan 62%, Raquel 33% e rendimentos 5%, além de um comprometimento de 24% em dívidas/encargos, acima da faixa ideal indicada no próprio relatório.

O relatório também projeta alívio de caixa entre novembro de 2026 e maio de 2027, com liberação informada de R$ 1.157 por mês a partir de fevereiro de 2027, conforme o encerramento de faturas parceladas. As decisões estratégicas registradas são bloquear novas compras parceladas e priorizar a quitação antecipada de passivos com receita extra de RPG.

Limitação: o PDF e os gráficos não foram anexados ao vault, e os números permanecem relato do resumo do artefato, não uma reconciliação independente do Firefly III ou dos extratos. Não registrar o arquivo, credenciais, dados bancários completos ou identificadores privados nesta nota.

Fonte local: lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-bee87fddfce54390879aafc51b0b026d.json, evento ec2ba143b3243d416894d339, consultado em 2026-10-17.

Auditoria financeira integral Midas — lote atual

Relato local do artefato, sem reconciliação independente nesta curadoria: o relatório integral informado no lote consolida 12 meses, de novembro de 2025 a outubro de 2026, com R 208.437,73 em despesas e superávit nominal de R$ 3.767,61. O diagnóstico apresentado divide a renda em Yan (62,5%), Raquel (31,2%) e aplicações (6,3%); no orçamento 50/30/20, o custo básico aparece em 52%, encargos passados em 24,6% e poupança líquida livre em 5,8%.

A análise sazonal aponta uma entressafra em janeiro/fevereiro, com receitas na faixa de R 9 mil, e pico de R 50.165,81 associados a encargos, incluindo atrasos liquidados, faturas parceladas e renegociações. Esses números descrevem o relatório produzido, não substituem a leitura direta do Firefly III nem devem ser tratados como saldo contábil auditado.

Uso recomendado: preservar o PDF como artefato de análise fora do vault; usar a sazonalidade para dimensionar reserva de caixa; manter o bloqueio de novas compras parceladas; e priorizar passivos caros quando houver receita extra de RPG. Não registrar fornecedores, credenciais, identificadores de conta ou dados bancários completos nesta nota.

Fonte local: lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-74f06fa55d6b4a758884ad99ff2092d5.json, evento b482a3e508b95380862920bb, consultado em 2026-10-17.

Correção da classificação de receitas — 2026-10-18

Relato operacional local do lote, sem reconciliação independente adicional nesta curadoria: a revisão do cálculo de 12 meses concluiu que o extrato bruto havia tratado movimentos técnicos como novas receitas. Foram identificados R 67.285,98 em transferências cruzadas ou entre contas próprias e R$ 26.625,53 em resgates de RDB/aplicações próprias. Esses movimentos representam rolagem, transferência patrimonial ou resgate de recursos já existentes; não devem ser somados automaticamente como renda nova.

A classificação revisada, filtrando salários, pagamentos de alunos/jogadores de RPG, vendas reais e outras entradas externas efetivas, informou R 3.500,79 por mês, e R 2.798,50 por mês. Os valores são resultado relatado da auditoria local, não substituem uma reconciliação independente dos lançamentos na origem.

Regra operacional: o relatório deve separar entradas externas efetivas, transferências internas, resgates de aplicações, créditos técnicos de cartão e pagamentos de fatura. Antes de usar totalizadores para decisões financeiras, conferir cada grupo contra a origem e evitar dupla contagem entre cartão, conta bancária e contas do mesmo domicílio.

Fonte local: lote /home/ubuntu/.hermes/plugin-data/obsidian-knowledge-capture/nodes/foundry/batches/batch-b7ad2d84b8b041ec98e4ed9939cc434d.json, evento 8f71c65cb9e2abc2bd9bc4b4, consultado em 2026-10-18.

Refinamento de categorias — despesas não classificadas — 2026-10-18

Decisão operacional derivada da correção do lote: a categoria genérica “outras despesas” não deve ser usada como destino final para lançamentos não conciliados. Cada item precisa ser revisado e atribuído a uma categoria específica ou marcado como pendente de classificação, mantendo separadas despesas reais, transferências internas, resgates de aplicações, créditos técnicos e pagamentos de fatura.

Essa regra reduz a perda de rastreabilidade e evita que uma categoria ampla esconda erros de classificação ou duplas contagens. Valores de uma auditoria específica permanecem fora desta atualização; totalizadores devem ser aceitos somente após conferência dos lançamentos na origem.

Fonte local: lote C:\Users\Yanbd\AppData\Local\hermes\plugin-data\obsidian-knowledge-capture\nodes\yan-B450M\batches\batch-efd9c838b47844c799e627f0fb6cdf3b.json, evento 5ae9f9a00e1e409a25f44e68, consultado em 2026-10-18.

Distinção entre despesa real e lançamentos técnicos — 2026-10-18

Relato operacional local do lote, sem reconciliação independente adicional nesta curadoria: a revisão identificou que cobranças contábeis de saldo em atraso e créditos de atraso do Nubank, usados para rolagem da dívida, haviam sido somados como se fossem novas compras. O mesmo princípio vale para transferências entre contas próprias e resgates de RDBs/CDBs: são movimentos de financiamento, transferência patrimonial ou liquidação de saldo existente, não receita externa ou despesa de consumo por si só.

Regra de conciliação: antes de calcular receita e despesa, separar lançamentos de consumo efetivo, encargos financeiros, créditos técnicos de cartão, pagamentos e renegociações de fatura, transferências internas e resgates de aplicações. Parear débitos e créditos de rolagem pela origem e finalidade; não aceitar um total bruto do extrato como retrato do orçamento. Os valores desta auditoria permanecem como relato do processo e não substituem a conferência dos lançamentos na origem.

Fonte local: lote C:\Users\Yanbd\AppData\Local\hermes\plugin-data\obsidian-knowledge-capture\nodes\yan-B450M\batches\batch-37c5b4f840884996a8cc6103f05b34d5.json, evento 27fbd2bcc2c21968d3ffa726, consultado em 2026-10-18.

Regra de projeção com faturas fechadas — 2026-10-18

Decisão operacional confirmada pelo usuário: quando uma projeção financeira usar o dia 10 como data-base, ela deve incluir também as faturas de cartão já fechadas que vencem no intervalo analisado. O dia 10 é apenas a referência da projeção; não deve excluir uma obrigação já constituída por a fatura vencer alguns dias antes ou depois.

A conciliação deve separar:

  • faturas fechadas confirmadas;
  • parcelas futuras com vencimento até a data-base;
  • contas fixas e demais obrigações previstas;
  • compras ainda não fechadas, que não são obrigação de pagamento da fatura na data-base;
  • receitas e sessões internacionais efetivamente previstas na janela.

Regra contra dupla contagem: a compra individual do cartão e o pagamento da fatura correspondente não devem ser somados como duas despesas. A compra representa o consumo; o pagamento da fatura é uma transferência para quitar o cartão. Valores de faturas devem ser confirmados diretamente na fonte financeira atual antes de apresentar uma margem líquida como definitiva.

Fonte local: evento ee863174b6d87239613fdb18 do lote batch-232c87830756485687044b9b1a2ace49.json, consultado em 2026-10-18.

Correção: fatura corrente versus parcelas futuras — 2026-10-18

Relato operacional local do lote, com valores financeiros minimizados: uma projeção anterior usou indevidamente parcelas futuras ou saldos agregados retornados pela integração como se fossem o valor atual das faturas. Para projeções do dia 10, o valor da fatura corrente deve vir da fatura aberta ou fechada confirmada na fonte financeira, e não do saldo total do cartão nem da soma automática de parcelas futuras.

A consulta Pluggy observada no lote não foi considerada suficiente para determinar o valor da fatura corrente: o retorno aparentou representar o saldo total do cartão, que pode incluir componentes diferentes da obrigação da fatura no ciclo atual. Essa limitação é um relato local do comportamento observado, não uma afirmação geral sobre todos os conectores ou produtos.

Regra de conciliação:

  • confirmar separadamente o valor atual de cada fatura aberta ou fechada;
  • incluir parcelas e obrigações fora da fatura somente quando ainda não estiverem incluídas nela;
  • não somar novamente parcelas individuais que já compõem o total da fatura;
  • manter compras do cartão e pagamento da fatura em categorias distintas, sem contar ambos como duas despesas;
  • invalidar uma projeção anterior quando sua base usou saldo de cartão ou parcelas futuras em vez da fatura corrente;
  • não registrar no vault valores de faturas, dados bancários completos, credenciais ou identificadores privados.

O lote também registrou receitas e outras entradas da janela, mas esses valores foram deliberadamente omitidos desta nota por serem dados financeiros pessoais e por não serem necessários para preservar a regra de implementação.

Fonte local: evento 5886cf6f51ac064d48014360 do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-57164d4282f743968cdebff2e75d5501.json, consultado em 2026-10-18.

Datas e parcelas em compras no crédito — 2026-10-18

Confirmado por relato operacional local, com dados pessoais minimizados: para analisar compras no crédito, o sincronizador deve distinguir a data em que a compra foi realizada da data em que o lançamento entrou na fatura. O primeiro campo representa consumo; o segundo representa competência ou fluxo de caixa da fatura. A resposta observada também separa valor da parcela, posição da parcela no plano e status (POSTED ou PENDING). Os nomes exatos podem variar conforme o produto ou conector; não assumir que todos os bancos exponham os mesmos campos.

Mapeamento operacional observado:

  • purchaseDate ou transactionDateTime: data da compra, quando disponível;
  • date ou billPostDate: data do lançamento na fatura, quando disponível;
  • amount: valor do lançamento ou da parcela;
  • installmentNumber e totalInstallments: posição e total de parcelas;
  • status: distinguir lançamento confirmado de lançamento pendente.

Regra de conciliação: usar a data real da compra para análises de consumo e a data de lançamento/fatura para projeções de caixa. Separar compras realizadas, parcelas da fatura corrente, lançamentos pendentes e parcelas futuras. Não somar novamente parcelas individuais já incluídas no total da fatura e não transformar PENDING automaticamente em despesa realizada.

A documentação pública da Pluggy confirma a existência de date, amount, status e metadados de parcelamento em transações, e recomenda usar installmentNumber e totalInstallments como primeiro critério de agrupamento. A disponibilidade de datas específicas de compra e de postagem deve ser validada por instituição e produto durante a sincronização.

Fonte local: evento 775be111b3f96d149ac2807a do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-f7413c39199b467f92d4549bb3bc1cd5.json, consultado em 2026-10-18.

Fontes externas:

Verificação de passagens fora das faturas — 2026-10-18

Confirmado por relato operacional local, com valores minimizados: uma consulta às transações de crédito disponíveis no Pluggy não encontrou compras identificáveis de passagens aéreas. Portanto, a ausência de um lançamento nas faturas não prova que a passagem não foi paga; é necessário verificar também débito, Pix, InfinitePay, agência de viagens ou outra descrição de estabelecimento.

Regra de conciliação: registrar a passagem somente na conta de origem em que ela for localizada e não somá-la novamente às faturas de cartão. Se não houver correspondência nas fontes consultadas, manter o item como pendente de localização, sem inferir que ele já está incluído no total das faturas.

Não registrar valores individuais, nomes de viajantes, números de conta/cartão, identificadores privados ou credenciais nesta nota.

Fonte local: evento ce93f0e1b1d46f23cc44d9d0 do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-bd0da1b447184e94898c95677d5919ac.json, consultado em 2026-10-18.

Compra aérea identificada no crédito — 2026-10-18

Confirmado por evidência visual local, com valores e identificadores minimizados: uma compra aérea que não aparecia na consulta anterior foi localizada na fatura do cartão com a descrição do estabelecimento correspondente à companhia aérea. A evidência também mostrou que a compra está parcelada e que a fatura corrente e as parcelas futuras são obrigações distintas.

Regra de conciliação: quando uma compra ausente do extrato agregado for encontrada em uma fatura visual, registrar a origem como cartão de crédito e conferir separadamente: (1) saldo ainda aberto da fatura corrente; (2) parcela futura já prevista; e (3) se o lançamento já está incluído no total usado na projeção. Não somar a compra, o saldo da fatura e a parcela futura sem verificar a composição, pois isso pode duplicar a cobrança. A descrição do estabelecimento deve ser usada como chave auxiliar de busca, nunca como prova de que o valor ainda está fora do total agregado.

Não registrar nesta nota valores da compra ou da fatura, número de cartão, nomes de viajantes, identificadores privados, credenciais ou imagens bancárias.

Fonte local: evento 73a3eab3f54c27479aff9aae do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-48b15f467e504f0cb1109fff4c75084b.json, consultado em 2026-10-18.

Goal de auditoria determinística Pluggy + Midas — 2026-10-18

Decisão operacional: o relatório financeiro deve ser construído primeiro por cálculos determinísticos sobre os dados do Pluggy e do ledger local, não por interpretação livre de LLM. A prévia deve mostrar faturas abertas, fechadas e futuras, compras no crédito com compra, lançamento, parcela e valor, receitas por janela, saídas, folga e categorias; depois deve solicitar correções ao Yan antes de classificar gastos com LLM.

Regras preservadas para a auditoria:

  • manter faturas, compras parceladas, pagamentos de fatura e transferências internas em grupos separados;
  • incluir na projeção do dia 10 as faturas fechadas com vencimento entre os dias 10 e 13;
  • excluir da receita e da despesa transferências internas, Pix conjugais, resgates, créditos técnicos, rolagens e pagamentos de fatura;
  • conciliar compras, parcelas, abatimentos e saldos de cartões virtuais antes de totalizar;
  • usar o LLM apenas para classificação e compreensão de categorias, sem alterar valores, datas ou totalizadores;
  • não finalizar a análise quando houver divergência Pluggy/aplicação, sessão internacional sem data ou valor, possível duplicata, falta de acesso ou necessidade de escrita externa;
  • substituir a categoria genérica “Outros” por uma categoria específica ou por pendência de classificação.

A execução deve ser somente leitura na origem, validar totais por soma e ser reexecutável sem duplicação. O relatório final deve registrar período, titular, cartão, valor, datas, status, fonte, fórmula e limitações. Divergências devem ser confirmadas com Yan e permanecer registradas, sem inventar valores.

Status: objetivo e critérios documentados; o lote não comprova que a auditoria tenha sido executada nem que um relatório Markdown/PDF tenha sido produzido.

Fonte local: evento e06eaf7b5416019daf711352 do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-29b71000aece4bf893e72085010c06cc.json, consultado em 2026-10-18.

Execução da prévia Pluggy + Midas — 2026-10-18

Confirmado pelo retorno local do lote: a prévia da auditoria foi executada sobre a janela de 12 meses e produziu PDF e HTML correspondentes. Foram encontrados 2.597 lançamentos brutos, todos já presentes no SQLite local, sem novos lançamentos na execução. Nenhuma escrita foi feita no Firefly III; o modo de conferência foi idempotente.

O retorno ainda classifica a entrega como prévia, não como fechamento contábil. Permanecem pendentes a abertura da categoria genérica “Outros”, a separação por titular/cartão entre compras, parcelas e pagamentos de fatura, a conciliação das receitas por janela com StartPlaying, Pix e InfinitePay, a revisão das compras de maior valor e a aplicação das correções antes da versão final em Markdown/PDF.

Regra operacional: os totalizadores apresentados pela prévia devem ser tratados como resultado de análise local, não como saldo contábil auditado. A versão final só deve ser emitida após conciliação das fontes, confirmação das correções e substituição de categorias genéricas por categorias específicas ou pendências explícitas.

Fonte local: evento 34280c21c72b6b8b51593653 do lote C:\\Users\\Yanbd\\AppData\\Local\\hermes\\plugin-data\\obsidian-knowledge-capture\\nodes\\yan-B450M\\batches\\batch-07b931288eac4957b6bad63ca9380c19.json, consultado em 2026-10-18.

Visão de gráfico

Backlinks

  • Sem backlinks encontrados