A origem

Uma empresa mais consciente, conectada e capaz de aprender com a própria operação.

Contato

// A CAMADA ECONÔMICA DA EMPRESA

OS NÚMEROS NÃO CONTAM TODA A HISTÓRIA. Mas revelam quando ela não fecha.

Receita, custo, margem, caixa, cobrança, faturamento e projeção são partes da mesma realidade.

O Financeiro conecta esses movimentos para transformar número em contexto e contexto em decisão.

EXPLORAR O FINANCEIRO
archēLABentidade · empresa
Receitas
Custos
Contas
Faturas
Cobranças
Transações
Metas
Projetos
Clientes
archēLABentidade · empresa
ReceitasCustosContasFaturasCobranças TransaçõesMetasProjetosClientes
// DO CADASTRO AO PLANEJAMENTO

DINHEIRO TAMBÉM tem um fluxo.

Primeiro sabemos entre quem. Depois organizamos contas. Depois acompanhamos movimento. Depois cobramos e faturamos. Depois registramos a obrigação fiscal. E aí usamos tudo isso para escolher o próximo ciclo.

6 camadas reais · estrutura do sistema
camada 01CadastrosQuem participa do movimento — antes de qualquer valor existir.Fornecedores
Bancos & Contas
Categorias
camada 02ContasO compromisso assumido, antes de o dinheiro se mover.A Pagar
A Receber
Recorrentes
Provisionamento
camada 03MovimentaçõesO dinheiro se move e o estado financeiro muda.Transações
Lançamentos
camada 04Cobrança & FaturamentoDa venda ao recebimento — que não são a mesma coisa.Cobranças
Faturas
camada 05FiscalO movimento gera obrigação — e ela também é contexto.Notas Fiscais
Impostos
camada 06PlanejamentoO histórico vira base para escolher o que vem.Metas
Orçamentos
Relatórios
14 núcleos no catálogo · 6 ativados pela archēLAB   Três dos ativados — Impostos, Notas Fiscais e Orçamentosnão existem no catálogo da plataforma. Foram criados pela empresa para as camadas Fiscal e Planejamento. É o motor funcionando como deveria: o catálogo oferece, a empresa acrescenta o que a operação dela pede.

DINHEIRO NÃO É SÓ MOVIMENTO. É sinal.

// CAMADA 01 · QUEM PARTICIPA DO MOVIMENTO

ANTES DO DINHEIRO SE MOVER, precisamos saber entre quem.

Um fornecedor não é um cadastro novo. É uma empresa que já existe no sistema, ganhando uma relação financeira.

A transação guarda o empresa_id, e o nome vem de lá. Duplicar seria criar uma segunda verdade sobre a mesma empresa.

Fornecedores Quem recebe dinheiro da empresa. Não é ficha isolada: é a mesma entidade do CORE, com contrato, categoria, conta e histórico de pagamento pendurados nela.
  • empresa já cadastrada
  • categoria de gasto
  • conta de pagamento
  • projetos que consomem
  • histórico completo
Bancos & Contas Onde o dinheiro está. Corrente, investimento, caixa, carteira, digital — cada uma com banco, moeda, titular, saldo inicial e saldo atual.
  • saldo_inicial · saldo_atual
  • banco · agência · número
  • moeda
  • chave e tipo de PIX
  • integração e última sincronização
Categorias Sem classificação, dinheiro é só entrada e saída. A categoria é hierárquica — tem categoria-pai — porque análise precisa de nível, não de lista plana.
  • árvore pai → filha
  • tipo (receita ou despesa)
  • cor e ícone
  • ordem e ativo
Saldo sem contexto pode enganar. A conta guarda saldo_atual, mas o número que importa para decidir inclui o que ainda vai entrar, o que já está comprometido, o que se repete todo mês e o que está provisionado. Saldo é um estado. Contexto é o resto da frase.
// CAMADAS 02 E 03 · O COMPROMISSO E O MOVIMENTO

A PAGAR E A RECEBER não são duas tabelas.

São a mesma tabela, vista por lentes diferentes. Troque a lente abaixo e repare: as linhas não mudam de lugar — muda o filtro que decide quais aparecem.

A expressão do filtro fica visível a cada troca. É literalmente o que o sistema faz.

Uma tabela: fin_transacoes
descrição · tipo categoria vencimento valor status
arquitetura real · verificada no código   Está escrito em app/actions/financeiro-pagar.ts: “A pagar = despesas PENDENTES (tipo='despesa', status='pendente'). Vencido = despesas pendentes com data < hoje.” Os valores da tabela acima são demonstrativos; o que é real e verificável são as colunas, o vocabulário de tipo e status, e a regra de cada lente.

A CONTA É O COMPROMISSO. A transação é o movimento.

// O EVENTO FINANCEIRO

UMA TRANSAÇÃO NUNCA DEVERIA existir sozinha.

Estas são as colunas de ligação que já existem numa linha de fin_transacoes. Cada uma é uma pergunta que a transação passa a conseguir responder.

colunas reais da tabela
conta_idDe onde saiuSem isso, o saldo de nenhuma conta fecha.
empresa_idCom quemO fornecedor ou o cliente — a mesma entidade do resto do sistema.
contato_idCom quem, pessoaQuando a relação é com uma pessoa e não com uma empresa.
projeto_idPor causa de quêO que liga o custo ao trabalho que o gerou.
categoria · subcategoriaQue tipo de movimentoO que permite somar coisas comparáveis.
centro_custo_tipo · _refQual área absorveAponta para qualquer coisa — departamento, projeto, unidade.
servico_ref · servico_livreSobre qual serviçoO serviço cadastrado, ou o texto livre quando ainda não é cadastro.
comprovante_urlCom qual provaA evidência anexada ao movimento, não numa pasta paralela.
Oito ponteiros numa linha só. É isso que separa lançamento de extrato bancário: o extrato diz que saiu dinheiro; a transação com contexto diz de onde, para quem, por causa de quê, em nome de qual área e com qual prova.
// O QUE AINDA NÃO ACONTECEU

NEM TODA SAÍDA JÁ ACONTECEU. Mas algumas já podem ser previstas.

Alguns compromissos nascem todo mês. Outros ainda não existem, mas já dá para saber que vão existir.

Planejar é dar contexto ao que ainda não aconteceu.

Recorrentes Assinatura, aluguel, folha, serviço, mensalidade, parcelamento. Um modelo com frequência e dia gera as contas — ninguém digita doze linhas iguais à mão.
  • frequência · dia
  • data de início e fim
  • próxima data — o campo que faz o modelo andar
  • conta e categoria de destino
  • ativo
Provisionamento Imposto, férias, custo estimado de projeto, receita prevista. O que ainda não é transação mas já pesa na decisão de hoje.
  • competência — o mês a que pertence
  • vencimento — o mês em que sai
  • valor e tipo
  • conta e categoria
  • status
Repare que a provisão tem competência e vencimento separados. É o mesmo par de datas que aparece na transação — e é ele que sustenta a distinção entre lucro e caixa, mais adiante nesta página.
// O REGISTRO ENCONTRA A REALIDADE

O SISTEMA DIZ QUE PAGAMOS. O banco também?

Conciliação é o momento em que o que a empresa registrou encontra o que de fato aconteceu. É onde erro de digitação, cobrança indevida e pagamento esquecido aparecem.

ConciliadoO lançamento tem uma contraparte no extrato. Os dois lados contam a mesma história.
Não conciliadoExiste no sistema e não no banco — ou o contrário. Ainda não é erro: é pendência.
DivergenteOs dois existem e não batem. Valor, data ou ambos. É aqui que mora o problema real.
Extrato importadoO sistema aceita importação de extrato — a conta guarda provedor, id externo e a data da última sincronização.

CONCILIAR É O MOMENTO EM QUE o registro encontra a realidade.

// CAMADA 04 · DA VENDA AO RECEBIMENTO

VENDER NÃO É o mesmo que receber.

Entre a assinatura do contrato e o dinheiro na conta existem cinco estados diferentes — e uma empresa pode quebrar dentro desse intervalo com a agenda comercial cheia.

VendaO Comercial fecha. Ainda não existe nada financeiro além de uma expectativa.módulo comercial
CobrançaGerada com valor, vencimento, método e origem. Pode carregar boleto, link e PIX — a tabela tem coluna para os três.gerada · enviada · paga · vencida
FaturaA receita formalizada. Guarda número, valor total, desconto, emissão, vencimento e pagamento — e aponta para a cobrança e para a transação.entidade com relações, não um PDF
VencimentoA data chega. O estado muda sozinho, sem ninguém tocar em nada.derivado da data
RecebimentoA transação de receita passa de pendente para realizado. Só aqui virou caixa.fin_transacoes · status
ConciliaçãoO extrato confirma. Agora a história fecha dos dois lados.fecha o ciclo
// QUANDO A RELAÇÃO FINANCEIRA MUDA

UMA FATURA VENCIDA NÃO É apenas um número vermelho.

Ela atravessa o sistema inteiro. E cada módulo que ela toca enxerga uma consequência diferente do mesmo fato.

FinanceiroInforma. O caixa previsto muda e a projeção do mês precisa ser refeita.
ClientesCompreende a relação. Um bom cliente atrasando é um sinal diferente de um cliente ruim atrasando.
ComercialPode negociar. Renegociar prazo às vezes vale mais do que cobrar duro.
archēFLOWExecuta. Verifica a regra, notifica, envia cobrança, espera, escala e registra o resultado.

RECEITA PREVISTA não é dinheiro no caixa.

// CAMADA 05 · A CONSEQUÊNCIA DO MOVIMENTO

DINHEIRO QUE CIRCULA também gera responsabilidade.

O archēCORE não é um sistema contábil e não pretende ser. O que ele faz é impedir que o documento fiscal viva isolado do fato que o originou.

núcleos Notas Fiscais e Impostos · ativados pela archēLAB
Nota fiscalNão é um arquivo numa pasta por mês. É o documento ligado à venda que o gerou.núcleo notas fiscais
Venda · Cliente · ServiçoDe onde a nota veio, para quem e sobre o quê. A transação já guarda os três.empresa_id · servico_ref
ReceitaO valor que a nota formaliza vira lançamento com categoria e competência.fin_transacoes
TributaçãoA obrigação que nasce do movimento — guia, DARF, apuração.núcleo impostos
ProvisãoO imposto do mês que ainda não venceu já entra na leitura de hoje.fin_provisoes

DOCUMENTO FISCAL ISOLADO é arquivo. Ligado, é contexto.

// CAMADA 06 · O PASSADO AJUDA A DECIDIR O FUTURO

REGISTRAR É IMPORTANTE. Planejar é usar o registro para escolher.

Um número só vira meta quando tem contexto: período, responsável, e alguma coisa que ele deveria mover.

01HistóricoO que já aconteceu, com contexto suficiente para ser lido.
02PadrõesO que se repete — sazonalidade, recorrência, ciclo de cobrança.
03ProjeçõesO que o padrão sugere para o período seguinte.
04MetasO que a empresa decide perseguir, com prazo e valor.
05OrçamentoQuanto cada área pode gastar antes de gastar.
06DecisãoA escolha feita com número na mão, não com impressão.
comportamento real do produto   O progresso de uma meta financeira não é armazenado. Ele é calculado na hora, somando as transações realizadas dentro do período dela. Meta com progresso gravado envelhece; meta calculada não tem como divergir do fato.

GASTO SEM OBJETIVO É TRANSAÇÃO. Gasto com objetivo é alocação.

// O TEMPO DO DINHEIRO

UMA EMPRESA PODE TER LUCRO e ainda assim ficar sem caixa.

Esta é a distinção que mais quebra empresa saudável — e ela existe no sistema como duas colunas de data na mesma linha.

valores demonstrativos · as colunas são reais
Competência data_competencia O mês a que o fato pertence. Serviço prestado em março é receita de março, mesmo que o cliente pague em junho. É esta coluna que responde “a operação dá resultado?”.
jan64%
fev71%
mar88%
abr82%
mai79%
Caixa data O dia em que o dinheiro entra ou sai de fato. É esta coluna que responde “tem dinheiro para pagar a folha na sexta?”. Os dois gráficos são as mesmas transações.
jan58%
fev44%
mar52%
abr96%
mai61%
Março é o melhor mês da esquerda e um mês mediano da direita. Nada está errado nos dois gráficos: o trabalho foi feito em março e o dinheiro só entrou em abril. Resultado e liquidez são perspectivas diferentes sobre o mesmo fato — e olhar só uma delas é como dirigir vendo só o retrovisor.
// VENDER MAIS NÃO É GANHAR MAIS

RECEITA não é resultado.

Entre a receita e o resultado existem custo e despesa — e é nesse intervalo que crescimento sem margem amplia o problema em vez de resolvê-lo.

ReceitaO que entrou pela operação. Sozinho, não diz nada sobre saúde.
CustosO que foi consumido para entregar. É onde o projeto revela se valia a pena.
DespesasO que a estrutura consome independentemente da entrega.
ResultadoO que sobra. A pergunta que o DRE responde e que a receita não responde.
As três perguntas que essa leitura devolve: a operação gera resultado? · onde a margem está mudando? · que área consome mais recurso? — e todas as três dependem de a transação ter sido classificada com categoria e centro de custo lá atrás.
// QUEM CONVERSA COM O FINANCEIRO

O DINHEIRO ATRAVESSA a empresa inteira.

O Financeiro não é um departamento isolado com uma planilha. Ele é a leitura econômica de coisas que já existem em outros módulos.

Comercial Fecha a venda e cria a expectativa.
  • lead → oportunidade → venda
  • proposta com preço e desconto
  • contrato assinado
Financeiro Confirma o impacto — e devolve o que o Comercial não vê.
  • a venda virou fatura?
  • a fatura virou recebimento?
  • qual foi a margem real?
  • este cliente paga em dia?
Projetos Um projeto pode parecer bem-sucedido operacionalmente e ruim financeiramente. Ou o contrário. As duas lentes precisam conversar — e conversam porque a transação carrega projeto_id.
  • orçamento previsto
  • custo realizado
  • fornecedores consumidos
  • receita gerada
  • margem do projeto
Clientes O Financeiro conhece a relação econômica. O módulo Clientes conhece a relação de confiança, retenção e sucesso. A entidade é a mesma — muda a pergunta que cada um faz a ela.
  • receita acumulada
  • faturas em aberto
  • histórico de inadimplência
  • ticket e recorrência
KPIs & OKRs Uma meta financeira precisa voltar para a estratégia. Objetivo → KPI → meta → transações → análise → decisão. Sem o último elo, o ciclo não fecha e a meta vira número na parede.
  • objetivo estratégico
  • indicador que o mede
  • meta com prazo
  • realizado calculado
// MOVIMENTO PODE GERAR AÇÃO

O FINANCEIRO REGISTRA. O FLOW responde.

A divisão é limpa e é o que mantém os dois módulos simples: um sabe o que aconteceu, o outro faz o que precisa acontecer depois.

Financeiro Sabe que a fatura venceu, que o saldo caiu abaixo do limite, que o cliente está há 40 dias em atraso.
  • registra o fato
  • guarda o contexto
  • não executa nada sozinho
archēFLOW Verifica a regra, notifica o responsável, envia a cobrança, espera, escala e registra o resultado de volta.
  • evento → regra → ação
  • espera e escalonamento
  • o resultado volta pro Financeiro
// NÚMEROS PRECISAM DE INTERPRETAÇÃO

“POR QUE NOSSA MARGEM caiu?”

Uma pergunta dessas atravessa transações, produtos, projetos, clientes, custos, decisões e período. É atravessar relação, não consultar uma tabela.

o ON levanta hipótese — não afirma causa
01A perguntaEm linguagem natural, do jeito que alguém pergunta numa reunião.
02Os dadosTransações classificadas, no período certo.
03As relaçõesO que essas transações tocam: projeto, cliente, categoria, centro de custo.
04O contextoO que mais mudou no mesmo período, inclusive fora do Financeiro.
05HipótesesCandidatas ordenadas por evidência — não uma causa afirmada.
06A pessoa decideO ON interpreta. Ele não altera fato financeiro nenhum.
// QUEM PERGUNTA PELOS NÚMEROS

FIBONACCI  mestre dos números.

A pergunta central do módulo e a pergunta principal do agente são exatamente a mesma frase, cadastrada nos dois lugares.

Não é coincidência de redação: é o agente sendo a pergunta que o módulo faz.

Retrato de Fibonacci, referência do agente financeiro

Fibonacci

mestre dos números · módulo financeiro

“Os números sustentam essa decisão?”

// responsabilidades
  • Calcular preço, margem e custo
  • Projetar receita e fluxo de caixa
  • Avaliar viabilidade, ROI e payback
  • Analisar CAC, LTV e ticket médio
  • Validar desconto e proposta financeira
  • Comparar cenários e identificar risco
// tom declarado no sistema
  • Preciso e analítico
  • Prudente, orientado a evidências
  • Proporcional — não dramatiza número
  • Didático: explica o cálculo, não só o resultado
  • Direto, sem suavizar má notícia
o módulo tem 18 vozes cadastradas · a função não muda, o tom muda
FibonacciWarren BuffettRockefellerAdam Smith GaussPitágorasIsabel de CastelaIshida Baigan PlutosMãe do OuroTio PatinhasSr. Sirigueijo

Fibonacci é uma referência de postura, não uma ressurreição — o modelo não possui a consciência nem a personalidade histórica dele. O que existe é um conjunto de responsabilidades, critérios e um tom, escritos e auditáveis no sistema. E as outras vozes acima não mudam o que o módulo faz: mudam como ele fala. Uma empresa pode preferir a prudência de Buffett ou o didatismo de Fibonacci — a conta é a mesma.

// O TESTE

TODA EMPRESA CONTA uma história sobre si mesma.

O trabalho do Financeiro não é desmentir essa história. É submetê-la a teste — e mostrar onde ela não fecha.

Teste de coerência econômica demonstração — cenário fictício
“Este produto está crescendo muito.”
// receita+30%A parte da história que estava certa. E é só ela que costuma ser citada na reunião.
// margem−12%Cada venda nova está deixando menos. O crescimento está sendo comprado.
// CAC+40%Conquistar cada cliente ficou muito mais caro do que era.
// inadimplência+8%E parte do que foi vendido ainda pode não virar dinheiro.
“Estamos crescendo ou apenas movimentando mais dinheiro?” Nenhum dos quatro números diz que a decisão foi errada. Juntos, eles dizem que a frase “está crescendo muito” é curta demais para o que está acontecendo — e que a próxima decisão precisa levar os outros três em conta.

NÚMERO NÃO EXISTE PARA SUBSTITUIR A HISTÓRIA. Existe para testá-la.

// DIFERENTES PERGUNTAS, DIFERENTES VIEWS

R$ 100 MIL SOZINHOS não explicam nada.

Em qual período? Comparado a quê? Previsto ou realizado? Receita ou caixa? Bruto ou líquido? Sem essas cinco respostas, o número não é informação.

hojemêstrimestreanopersonalizado previsto × realizadocompetência × caixabruto × líquido
Relatório não é uma entidade nova quando pode ser uma view da mesma estrutura. DRE, fluxo de caixa, receitas, despesas, contas, inadimplência, margem e projeção são oito perguntas diferentes sobre os mesmos lançamentos — não oito lugares onde o dado precisa ser copiado.
// AS DUAS FACES DE CADA NÚCLEO

A TELA QUE OPERA e a camada que explica.

Todo núcleo do sistema tem duas faces. Uma executa. A outra ensina. Confundir as duas é o que transforma software em manual ilegível — ou manual em software inútil.

A tela operacional Existe hoje em /core/financeiro/pagar e roda com dado real do tenant. Quando não há transação, ela mostra vazio — nunca um número inventado.
  • descrição e fornecedor
  • categoria
  • conta e forma de pagamento
  • vencimento, com marca de vencido
  • valor
  • status: pendente ou vencido
A camada explicativa É o que você está lendo agora. Ela não opera nada: ela responde por que a tela é daquele jeito, o que cada campo significa e o que o número deveria provocar em quem olha.
  • o conceito antes do campo
  • a fronteira com os outros módulos
  • a pergunta que o núcleo faz
  • o que a empresa perde sem ele
colunas reais da tela /core/financeiro/pagar   A tela operacional não é encenada aqui — a demonstração dela precisa de captura da tela real, dentro do sistema logado. O que esta página mostra é a estrutura dela, que é verificável no código.
// O QUE ESTE MÓDULO PROTEGE

SUSTENTABILIDADE econômica.

Não apenas saldo. Não apenas receita. Não apenas lucro. A capacidade de compreender se as decisões de hoje sustentam a operação de amanhã.

// saldo totalSoma das contas ativas. É o estado, não a leitura.fin_contas · saldo_atual
// a pagarDespesas pendentes. O que já foi assumido e ainda vai sair.tipo despesa · status pendente
// vencidoPendentes com vencimento passado. Calculado, não gravado.derivado da data
// a receberReceita prevista. Ainda não é caixa.tipo receita · status pendente
// realizado no mêsO que efetivamente se moveu no período corrente.status realizado · período
// progresso das metasCalculado somando o realizado dentro do prazo de cada meta.calculado, nunca armazenado
Os traços não são placeholder de design. É assim que o painel se comporta antes de existir lançamento — e um painel honestamente vazio vale mais do que um cheio de número plausível.

NÚMEROS NÃO TÊM opinião.

MAS TAMBÉM NÃO SE explicam sozinhos.

receitaprecisa de custo.
custoprecisa de contexto.
margemprecisa de tempo.
caixaprecisa de previsão.

E TODA DECISÃO PRECISA perguntar:

OS NÚMEROS sustentam isso?

Financeiro A camada que torna a saúde econômica transparente e governada.

OS NÚMEROS SUSTENTAM essa decisão?

quem paga e quem recebecontascompromissosmovimentações cobrançafaturamentorecebimentofiscal relatóriometaplanejamentodecisão

E no fim da fila, sempre a mesma pergunta.