A auditabilidade normalmente custa fricção. Cada controlo adicional, seja um segundo aprovador, um formulário assinado ou um passo de reconciliação, compra rastreabilidade ao tornar o processo mais lento e mais irritante de usar. Construímos o Spendwise porque não aceitámos essa troca, e temos gerido a nossa própria empresa com ele há um ano.
O Problema Técnico: Nenhuma Fonte Única de Verdade
A gestão manual de benefícios e despesas corporativas tem uma falha estrutural: não há estado e não há transacionalidade.
O nosso próprio processo corria em ficheiros Excel isolados e conversas de mensagens. O custo não era principalmente o tempo, uma vez que validar um pedido à mão demora cerca de um minuto e o volume era gerível. O custo era a exatidão. Uma célula atualizada na cópia errada de uma folha de cálculo, ou uma aprovação acordada numa conversa e nunca registada por escrito, é suficiente para pagar a mesma fatura duas vezes. Não havia uma resposta autoritária à questão de saber se algo foi aprovado, por quem e quando. Havia apenas um conjunto de artefactos que, na sua maioria, concordavam entre si.
Esse é um problema de gestão de estado, não um problema de produtividade. É também o tipo de problema que se agrava silenciosamente: ninguém nota a falta do rasto de auditoria até alguém o pedir.
Arquitetura e Automação: Receção Resiliente de Faturas
O Spendwise é construído em Next.js como um monólito. Esta é uma escolha deliberada que mantém a iteração rápida e a implementação simples, e que uma única equipa pode operar sem uma organização de plataforma por trás. A interface é responsiva (mobile-first), pelo que um colaborador submete uma despesa a partir de um telemóvel sem instalar nada.
A receção de faturas é tratada por visão computacional (VLMs e OCR) orquestrada através do n8n, um motor de automação de código aberto. Uma execução de receção automatizada demora cerca de 5 segundos e coloca os dados extraídos no pedido sem que um humano lhes toque. Ao longo de um ano de utilização em produção, 95% das submissões concluem este caminho sem correção manual.
Os restantes 5% são onde a engenharia importa. Os pipelines financeiros não podem falhar silenciosamente, pelo que definimos limites de confiança explícitos nos prompts de extração. Quando a confiança da extração cai abaixo do limite, ou ocorre uma falha técnica em qualquer ponto da validação automatizada, o sistema encaminha o pedido para o utilizador ou para a equipa técnica com a falha exposta. Nenhuma fatura é descartada e nenhum pedido fica parado num estado indefinido.
A submissão duplicada, o modo de falha que motivou todo o projeto, é tratada na receção. Cada fatura recebe uma impressão digital com uma hash derivada do valor, data e comerciante. Se já existir uma hash correspondente, o pedido é recusado na submissão e é explicado o motivo ao utilizador. O duplicado nunca entra no fluxo de trabalho, pelo que nunca pode chegar a um aprovador ou a uma execução de pagamento.
O Filtro Contextual: Rejeição como Funcionalidade
A maioria das ferramentas de faturas fica-se pela extração: lê o documento e entrega-lhe os campos. A extração por si só não responde à pergunta que uma equipa financeira realmente tem, que é se esta despesa deveria sequer ter sido submetida.
O Spendwise aplica um filtro contextual por cima da extração. Para além de categorizar a despesa, detalhar o recibo por itens e validar o número de identificação fiscal (NIF) da empresa, o modelo avalia cada submissão face ao ramo de negócio da empresa e à sua política de despesas. Dois exemplos da nossa própria implementação:
- Uma fatura de restaurante com data de um domingo à noite (tarde) é rejeitada automaticamente. A extração é bem-sucedida e o recibo é válido, mas a marca de tempo (timestamp) coloca-o fora de qualquer contexto de trabalho plausível.
- Uma fatura de um fornecedor legítimo é rejeitada quando a análise de itens descobre compras pessoais misturadas no que, de outra forma, seria uma despesa de negócios válida. O filtro lê a discriminação dos itens, e não apenas o total.
Em ambos os casos, o raciocínio é anexado ao pedido em vez de ser entregue como um veredicto opaco, para que o colaborador veja exatamente em que regra a submissão falhou e possa corrigi-la ou contestá-la. A mesma passagem gera um título de pedido padronizado e uma descrição escrita de cada validação efetuada, de modo a que um aprovador que leia o pedido semanas mais tarde veja o que o sistema verificou e o que concluiu.
Nenhuma destas regras está codificada de forma rígida para o nosso negócio. São configuração, e adaptá-las à política e ao setor de um cliente é a primeira coisa que fazemos numa nova implementação.
Máquina de Estados e Governação de Acessos
Para eliminar a ambiguidade da era das folhas de cálculo, a lógica do fluxo de trabalho da plataforma é centralizada numa máquina de estados explícita. Os pedidos movem-se através de estados definidos, incluindo Rascunho, Submetido para Aprovação, Aprovado para Pagamento, Rejeitado, Concluído e Cancelado. Nenhum pedido transita de forma arbitrária. Cada transição tem um gatilho definido, um ator definido e uma marca de tempo registada.
As notificações derivam da máquina de estados em vez de serem acopladas paralelamente a ela. Uma transição que requer aprovação notifica exatamente as pessoas que a podem conceder, razão pela qual um ano de uso em produção não produziu nenhuma conversa de e-mail paralela a perseguir aprovações.
A autenticação e autorização correm através de SSO, nativamente integrado com o Azure AD. A plataforma herda os grupos de gestão que já existem no diretório da empresa, pelo que as estruturas de permissões são mapeadas uma vez, em vez de serem reconstruídas à mão e mantidas em paralelo. A mesma integração adapta-se a outros fornecedores de identidade, como o Okta ou o Google Workspace.
Localidade dos Dados: As Faturas Ficam Onde as Coloca
A automação de despesas normalmente significa enviar os documentos financeiros da sua empresa para um fornecedor de IA externo. Não queríamos isso para nós e não assumimos que os clientes também o queiram.
Na Lynxmind, o Spendwise corre inteiramente em modelos locais. As faturas são armazenadas numa implementação auto-alojada da Supabase, com uma camada de armazenamento escrita contra uma interface em vez de um fornecedor, pelo que o S3 ou qualquer outro backend é uma alteração de configuração e não uma reescrita. A camada do modelo é igualmente conectável: modelos locais, um endpoint privado ou uma API pública, escolhidos pelo cliente em vez de impostos pelo produto.
Para uma empresa que está a avaliar se as ferramentas financeiras assistidas por IA são compatíveis com a sua política de dados, esta é a diferença entre uma conversa de aquisição e um projeto à partida inviável.
Impacto: Imutabilidade e Evidência de Auditoria
Um ano em produção na Lynxmind, com cerca de 40 utilizadores e aproximadamente 10 pedidos por semana, produziu os resultados para os quais desenhámos o sistema: ausência de pagamentos duplicados, um registo de aprovação inequívoco e o desaparecimento da coordenação em canais secundários que costumava rodear todos os pedidos.
O mecanismo subjacente é um conjunto de tabelas de auditoria rigorosas que criam um registo imutável de quem aprovou o quê, e quando. Os registos são anexados, nunca editados. O histórico de um pedido é reconstruível de ponta a ponta, incluindo as decisões automatizadas e o raciocínio por trás delas.
Queremos ser precisos sobre o que isto significa para a conformidade, porque a indústria geralmente não o é. SOC 2 e ISO 27001 são certificações organizacionais que cobrem controlos, políticas e recolha de evidências em toda uma empresa, e nenhum produto de software as confere. O que o Spendwise faz é produzir as evidências de aprovação e acesso que essas auditorias pedem, numa forma que um auditor pode aceitar, sem um exercício manual de recolha de evidências a cada ciclo. Se a sua organização está à procura de qualquer uma destas normas, o Spendwise foi concebido para ser um trunfo nesse processo e não uma lacuna no mesmo.
Construir vs. Comprar
O Spendwise exigiu seis meses de trabalho contínuo a quatro engenheiros, o que equivale a cerca de dois anos-engenheiro antes de qualquer manutenção. Esse valor é a verdadeira âncora de “construir vs. comprar”, e não inclui o ano de consolidação em produção que se seguiu: os modos de falha que encontrámos, o ajuste de limites, os casos extremos na receção.
Somos os proprietários do código, pelo que o modelo de entrega é uma decisão do cliente: auto-alojado na sua infraestrutura, alojado por nós, ou algo intermédio. A nossa equipa encarrega-se da configuração e extensão, adaptando a máquina de estados ao seu regime de benefícios e hierarquia de aprovação.
A execução do pagamento permanece no sistema que já utiliza. O Spendwise integra-se com o SAP para que um pedido aprovado flua para o seu pipeline financeiro existente em vez de criar um segundo, e o mesmo padrão de integração aplica-se a qualquer outro ERP ou plataforma de contabilidade.
O Que Procuramos
O Spendwise está comprovado dentro da Lynxmind e pronto para a sua primeira implementação externa. Estamos à procura de um parceiro, idealmente uma PME portuguesa, para o correr em produção, e estamos a absorver totalmente o custo de configuração e personalização.
Não procuramos um utilizador piloto para gerar um logótipo para um website. Queremos uma empresa com complexidade real de aprovação, porque é isso que nos dirá que partes da máquina de estados são genuinamente gerais e quais partes são nossas. Em troca, obtém um fluxo de trabalho de despesas configurado e auditável, e acesso direto à equipa que o construiu.
Se isto descreve a sua operação financeira, devíamos falar.
