Resposta rápida
Um rastreador de despesas com IA precisa de quatro peças funcionando juntas: OCR que extrai os itens de uma foto de recibo, um modelo de categorização que mapeia o gasto para a linha de orçamento certa, uma cadeia de aprovação que roteia por valor e departamento, e um registro de reembolso que fecha o ciclo assim que a pessoa é ressarcida. A Greta.sh monta essas quatro peças em um único app Next.js com camada de dados Postgres/Prisma — sem licença por usuário, sem fornecedor terceiro guardando os dados dos seus gastos. Você descreve o fluxo, a Greta.sh constrói o schema, o pipeline de OCR e a lógica de aprovação como um sistema conectado.
Por que uma ferramenta de despesas por assento fica cara assim que você escala?
Expensify, Ramp e ferramentas parecidas cobram por usuário ativo, por mês, para sempre. Um time de 40 pessoas em um plano de US$ 10 por assento está comprometendo US$ 4.800 por ano só para registrar recibos — e esse número sobe a cada contratação. Não é que essas ferramentas sejam ruins. Elas são feitas para uma empresa genérica, o que significa que suas categorias, seus limites de aprovação, seus códigos de departamento precisam se encaixar no schema de outra pessoa.
Já vi times financeiros manterem uma planilha paralela só para reclassificar gastos que as categorias padrão do fornecedor não cobrem. Esse é o custo real de "comprar pronto": não é a mensalidade, é o retrabalho construído em cima dela todo mês.
Um rastreador que você constrói uma vez não tem nada disso. Você define as categorias. Você define quem aprova o quê. E o custo marginal do quadragésimo funcionário enviando um recibo é zero, não mais um assento.
Do que você é dono de verdade quando constrói
O código fica no seu repositório do GitHub. As imagens de recibos e os registros de despesas ficam no seu próprio banco Postgres, não na nuvem multi-tenant de um fornecedor. Se você precisa de um novo tipo de despesa — digamos, diária para um cliente específico — você adiciona uma coluna e uma regra, não abre um chamado de suporte.
Como a captura de recibos e o OCR funcionam por baixo do capô?
O fluxo é mais simples do que parece. Um funcionário tira uma foto ou encaminha um e-mail de recibo; a imagem cai em um armazenamento de objetos (S3 ou um bucket do Supabase); um serviço de OCR — Google Cloud Vision, AWS Textract ou uma chamada de visão de LLM — extrai nome do estabelecimento, data, total e itens da linha como JSON estruturado. Esse JSON vira um rascunho de despesa, pré-preenchido, esperando o funcionário confirmar ou corrigir antes de entrar na fila de aprovação.
A etapa de categorização roda logo depois da extração. Em vez de forçar o funcionário a escolher entre 30 categorias genéricas em um dropdown, um prompt de classificação enxuto — alimentado com o nome do estabelecimento, o valor e o departamento do funcionário — atribui uma categoria e um índice de confiança. Qualquer coisa abaixo de, digamos, 85% de confiança é sinalizada para uma checagem humana em vez de ser arquivada errada silenciosamente. Essa única trava é a diferença entre uma categorização em que as pessoas confiam e uma que elas simplesmente contornam.
A detecção de duplicidade importa mais do que parece à primeira vista. Dois envios com o mesmo estabelecimento, valor e data dentro de uma janela de 48 horas deveriam ser sinalizados antes da aprovação, não pegos por um auditor três meses depois.
Como construir um fluxo de aprovação que não vire um gargalo?
A maior parte do atrito de aprovação vem de um único erro de design: rotear toda despesa pela mesma cadeia, não importa o valor. Um recibo de café de R$ 12 e um jantar com cliente de R$ 3.000 não deveriam cair na mesma fila do mesmo gestor com a mesma urgência.
O padrão que funciona: uma tabela de regras mapeia faixas de valor e categorias para uma cadeia de aprovação. Abaixo de R$ 50, aprovação automática se a categoria bater com a política e o funcionário tiver histórico limpo. Entre R$ 50 e R$ 500, aprovação de um gestor. Acima de R$ 500, ou qualquer coisa sinalizada pela checagem de confiança acima, roteia tanto para o gestor quanto para o financeiro. Guarde isso como dado — uma tabela que a Greta.sh consegue consultar — e não como if-statements fixos enterrados em um componente, para que o financeiro possa mudar um limite sem pedir a um engenheiro que suba um deploy.
Notificações importam aqui também. Uma aprovação parada, não lida, numa caixa de entrada é o mesmo que nenhum sistema de aprovação. Roteie aprovações pendentes por Slack ou e-mail com um link de aprovar/recusar em um clique, e a fila realmente anda em vez de empilhar até a semana do pagamento.
Para onde o dinheiro do reembolso realmente vai?
Essa é a parte que ferramentas genéricas costumam acertar e construções personalizadas erram se você não tomar cuidado: o registro de despesa e o registro de pagamento não são a mesma coisa. Uma despesa aprovada fica em um estado de "pronta para pagar" até entrar de fato em uma rodada de pagamento — uma transferência ACH em lote, um payout via Stripe, ou uma transferência bancária manual registrada pelo financeiro.
Construa o schema de forma que uma despesa só possa virar "paga" quando estiver vinculada a um lote de pagamento específico, com seu próprio ID e timestamp. Isso te dá uma trilha de auditoria que responde "a Sarah foi reembolsada pelo jantar com cliente do dia 14 de março, e em qual rodada de pagamento" sem ninguém precisar vasculhar e-mails.
Uma comparação rápida
| Ponto | SaaS de despesas por assento | Rastreador construído com a Greta.sh |
|---|---|---|
| Custo com 40 funcionários | ~US$ 400+/mês, cresce com o headcount | Só o custo de hospedagem, sem taxa por assento |
| Categorias e regras de aprovação | Se encaixam no schema do fornecedor | Batem exatamente com seus departamentos e limites |
| Dados de recibos e despesas | Ficam na nuvem multi-tenant do fornecedor | Ficam no seu próprio banco Postgres |
| Novo tipo de despesa ou regra | Chamado de suporte ou upgrade de plano | Uma mudança de schema e uma linha de regra |
| Relatórios | Dashboard do fornecedor, exportável | Consulte seus próprios dados como quiser |
Onde isso fica dentro de um app construído com a Greta.sh
A Greta.sh monta isso como um schema Prisma com uma tabela Expense (valor, estabelecimento, categoria, URL do recibo, índice de confiança, status), uma tabela ApprovalRule que o financeiro consegue editar sem precisar de um deploy, e uma tabela PaymentBatch que as despesas referenciam assim que são efetivamente pagas. A etapa de OCR roda em uma rota de API — algo como app/api/expenses/extract/route.ts — que chama um modelo de visão, grava o resultado estruturado de volta no rascunho e devolve para o funcionário confirmar rapidamente.
Descreva a política em linguagem simples — "aprove automaticamente qualquer coisa abaixo de R$ 50 na categoria viagem, senão roteie para o gestor do funcionário, e sinalize qualquer coisa acima de R$ 500 também para o financeiro" — e a Greta.sh monta essa lógica direto na tabela de aprovação e no código de roteamento, em vez de você configurar um motor de regras dentro do painel administrativo de outra empresa.
Para times que precisam só de uma fatia disso — não de um rastreador completo — alguns MVPs focados da Greta.sh resolvem problemas mais estreitos rápido: um Divisor de Contas em Grupo com Links do Venmo para dividir uma conta compartilhada na hora, e um Rastreador de Quilometragem para Deduções Fiscais para registrar quilômetros de trabalho e exportar um relatório pronto para o imposto de renda. Se você também está avaliando um fluxo de suporte ao lado disso, veja nosso guia sobre como criar um Helpdesk com IA.
Perguntas frequentes
Isso substitui um software de contabilidade como o QuickBooks? Não — substitui a camada de captura e aprovação de despesas que normalmente fica na frente da sua contabilidade. Envie as despesas aprovadas e pagas para o seu razão contábil por meio de uma sincronização agendada ou exportação, em vez de tentar reconstruir a contabilidade de partidas dobradas do zero.
O OCR consegue ler recibos manuscritos ou apagados? Razoavelmente bem, embora a precisão caia em letra manuscrita e em recibos térmicos desbotados. É exatamente por isso que a sinalização por índice de confiança importa — qualquer coisa que o modelo não tenha certeza vai para uma checagem humana em vez de ser arquivada errada silenciosamente.
O que acontece com despesas em moedas diferentes? Guarde o valor e a moeda originais junto com um valor convertido na taxa de câmbio da data da transação. Recalcular despesas antigas pela taxa de hoje é um bug comum — trave a taxa no momento do envio.
Os funcionários precisam de um aplicativo mobile? Não um aplicativo dedicado. Uma página web responsiva que abre a câmera, captura a foto e mostra o rascunho pré-preenchido cobre o caso de uso real — alguém no caixa querendo resolver isso em menos de 15 segundos.
Isso é mais difícil de construir do que parece? A chamada de OCR e as regras de aprovação são, cada uma, um dia de trabalho focado, não um projeto de um trimestre inteiro. O que antes levava semanas de um time de engenharia para conectar agora é um fluxo de descrever-e-montar com a Greta.sh.
Fechamento
Um rastreador de despesas não é complicado depois que você separa as quatro coisas que ele realmente precisa fazer: capturar, categorizar, aprovar e pagar. Acerte essas quatro e o dashboard, os relatórios, a exportação para o seu contador — tudo isso — é a parte fácil. Construir você mesmo significa não pagar uma mensalidade crescente só para registrar recibos que o seu próprio time já sabe categorizar.