O relatório de despesa que ninguém lançou

Um comprovante chega por email numa terça à tarde. A confirmação de um voo, a renovação de um software, um jantar com cliente. Cai numa inbox, recebe uma olhada, e então nada acontece com ele. Três semanas depois, no fim do mês, alguém abre uma planilha para “fazer as despesas” e aquele comprovante, junto com outros onze, precisa ser caçado, relido, categorizado e digitado à mão. Alguns são encontrados. Um ou dois, não.

O comprovante sempre ia virar um lançamento de despesa. A única questão era se um humano cansado faria isso no último dia do mês, ou se já estaria pronto na hora em que alguém pensasse em perguntar.

Esse gap, entre o momento em que a informação chega e o momento em que ela vira um registro, é onde a maior parte do trabalho pequeno de uma empresa apodrece. O relatório de despesa que ninguém lançou não é um problema de disciplina. É um problema de design. O comprovante já era um fato estruturado quando caiu; nós só não construímos nenhum caminho da inbox até o ledger além de uma pessoa lembrar de levá-lo até lá.

Este post é sobre fechar esse gap. A tese é simples, e vou repeti-la: a tarefa deveria estar pronta antes de você lembrar de começá-la.

A versão ingênua: uma pasta, um prazo e uma pessoa que esquece

Aqui está o workflow que quase toda empresa de fato roda, não importa o que o marketing da ferramenta financeira diga.

Comprovantes chegam espalhados, no email, como PDFs, como fotos de papel, como itens numa fatura de cartão. Eles se acumulam em algum lugar solto: uma pasta, uma thread encaminhada, uma caixa de sapatos do tipo digital. Então, numa data fixa, um humano se senta e converte a pilha em lançamentos. Abre cada um, lê o fornecedor e o valor, decide a qual budget pertence e digita num formulário. Multiplique por todo mundo que gastou dinheiro, e você tem um ritual de fim de mês que ninguém curte e todo mundo adia.

O ritual falha de três formas previsíveis, e vale nomeá-las porque cada uma parece uma falha pessoal quando na verdade é estrutural.

A primeira falha é o comprovante perdido. Algo chegou, recebeu uma olhada e escorregou para debaixo de outras quarenta coisas antes de alguém lançá-lo. No fim do mês está impossível de achar, então a despesa é reconstruída de memória ou silenciosamente descartada. Dinheiro que saiu da empresa não deixa rastro nos próprios livros da empresa.

A segunda é a categoria errada. O humano fazendo a digitação no fim do mês não estava na sala quando o dinheiro foi gasto. Ele chuta. O jantar com cliente é classificado como “material de escritório” porque era o padrão onde o cursor parou. Os livros fecham e ainda descrevem uma empresa que não existe.

A terceira é o timing. Tudo isso acontece de uma vez, no pior dia possível, feito por alguém que preferiria estar fazendo literalmente qualquer outra coisa. A decisão sobre o que uma transação foi é tomada à distância máxima do evento, pela atenção mínima. O custo não é a meia hora. O custo é que a memória financeira da empresa é montada, uma vez por mês, pela sua versão mais esgotada.

Nenhum desses é resolvido por um formulário melhor. Um formulário melhor ainda espera ser preenchido. O modelo inteiro é reativo: o dado fica inerte até uma pessoa lembrar de agir sobre ele. E lembrar de agir sobre um comprovante que não vive em lugar nenhum é um trabalho em que humanos são simplesmente ruins.

Por que “só me lembre” não resolve

O patch óbvio é um empurrãozinho. Configure um lembrete. Receba uma notificação quando um comprovante chegar dizendo “lance isto”. Adicione uma regra que te avisa no dia 28.

É uma melhoria do mesmo jeito que um alarme mais alto é uma melhoria sobre um silencioso. O alarme ainda precisa de uma pessoa para levantar.

Um lembrete não faz o trabalho, ele reatribui o trabalho de volta para você, só que com um prazo anexado. Pior, um lembrete para cada comprovante é seu próprio tipo de falha: agora o sistema te interrompe quarenta vezes por mês para te avisar de coisas que você já sabia que chegaram, e você começa a ignorar os pings exatamente do jeito que ignorou os comprovantes. O fix ingênuo para “o humano esquece” é “lembrar o humano”, e ele perde pela mesma razão que o original perdeu. Mantém o humano no caminho crítico de um trabalho ao qual o humano não acrescenta nada.

Ler o nome de um fornecedor num comprovante não é um julgamento. Reconhecer que uma cobrança recorrente do mesmo provedor é a mesma categoria do mês passado não é um julgamento. Extrair o valor, a data e o estabelecimento de um email de confirmação não é um julgamento. Essas são as partes de “fazer despesas” que consomem todo o tempo e não exigem nenhuma sabedoria.

Então a pergunta não é como lembramos o humano de fazer a tarefa. É por que o humano está fazendo a tarefa, afinal.

Nosso jeito: capturar no momento da chegada, não no momento do prazo

Aqui está a virada. Em vez de esperar por uma data e uma pessoa, o sistema age quando o comprovante chega, porque esse é o momento em que a informação está mais fresca, o contexto mais rico e o trabalho menor.

Um comprovante cai. Um agent conectado o lê, não como uma imagem para ser armazenada, mas como um fato a ser entendido. Ele extrai o estabelecimento, o valor, a data, a moeda. Olha para o próprio brain da empresa, lançamentos passados, fornecedores recorrentes, os budgets que existem, e propõe a categoria do jeito que alguém que tivesse visto os últimos seis meses de gastos proporia. Monta um rascunho de lançamento de despesa que está correto com muito mais frequência que o chute do fim de mês, porque é feito no momento do evento por algo que não esquece como o mês passado foi.

Então ele faz a única coisa que separa um assistente de um autocomplete: não escreve silenciosamente nos livros. Há dinheiro envolvido, então o lançamento espera por um sim. A proposta aparece, aqui está o comprovante, aqui está o lançamento que rascunhei, aqui está por que categorizei assim, e um humano aprova no tempo que leva para ler uma linha. O julgamento permanece humano. A digitação, a caça, a categorização, o lembrar, tudo isso já está feito.

Reveja as três falhas através desse design e veja-as desaparecer.

O comprovante perdido não pode se perder, porque foi capturado no instante em que chegou, não três semanas depois quando já tinha escorregado. A categoria errada fica mais rara, porque a categorização acontece com o histórico completo da empresa à vista em vez de um padrão de cursor. E o timing deixa de ser um ritual, porque não há pilha para processar no fim do mês, a pilha virou lançamentos revisados um por um, no dia em que cada um chegou, enquanto ninguém estava pensando em despesas.

A tarefa deveria estar pronta antes de você lembrar de começá-la. Quando o fim do mês chega, o relatório não é uma tarefa. É uma confirmação.

A parte que não é sobre despesas

Afaste-se dos comprovantes e você vai notar que o formato se repete em todo lugar numa empresa.

Uma reunião termina e os action items vivem só na memória de alguém até evaporarem. Uma cláusula de contrato define uma data de renovação que ninguém transfere para um calendário até ela já ter vencido. Um cliente diz algo que importa numa thread de suporte e isso morre na thread porque ninguém o carregou até o lugar onde decisões são tomadas. Cada um desses é a mesma falha da despesa não lançada: um fato estruturado chega, e não há caminho da chegada ao registro além de um humano lembrar de levá-lo até lá. O trabalho nunca foi difícil. O levar era o problema inteiro.

É por isso que não pensamos na captura de despesas como uma feature financeira. É uma instância de um princípio geral: informação que chega numa forma que uma máquina consegue ler não deveria esperar por um humano para transcrevê-la. O trabalho do humano nunca foi a transcrição. O trabalho do humano é o julgamento, esse lançamento está certo, essa categoria é honesta, esse dinheiro deveria ter sido gasto, afinal. Faça a máquina fazer a parte em que é boa, apresente a parte que precisa de uma pessoa, e os registros da empresa começam a se manter sozinhos.

Esse é o modelo. Não um formulário mais esperto que você preenche mais rápido. Um sistema que lê o que chega, rascunha o registro e te faz uma única pergunta de sim-ou-não no único momento em que um humano de fato acrescenta algo.

A virada: fim de mês nunca foi pra ser um dia de pavor

Aqui está a parte que não é sobre software.

Na maioria das empresas, a pessoa fazendo despesas no fim do mês é uma das últimas que você gostaria que gastasse uma noite com isso. Um founder reconstruindo um trimestre de comprovantes a partir de uma fatura de cartão. Um operador que preferiria estar conversando com clientes, digitando nomes de fornecedores num formulário. Exatamente as pessoas cuja atenção vale mais, gastando-a no trabalho que exige menos.

Esse trabalho parece diligência. É um imposto. Cada comprovante caçado e digitado à mão é um pequeno saque da mesma conta que financia as decisões que só uma pessoa pode tomar. Você começou a fazer suas próprias despesas à mão porque nenhum sistema faria por você, e isso nunca foi um bom uso de você.

A promessa não é uma ferramenta financeira com uma interface mais bonita. É que o relatório se escreve sozinho à medida que o mês acontece, para que a pessoa mais capaz da empresa pare de ser a que lembra de lançar o comprovante e passe a ser a que decide se o gasto valeu a pena, para começar.

---

É isso que estamos construindo na Apollo Space, não um formulário mais arrumado, mas um sistema que lê o que chega, rascunha o registro e espera pelo seu sim. O relatório de despesa que ninguém lançou nunca foi uma falha de disciplina. Era um trabalho que continuávamos entregando para a única parte do sistema que esquece. Se você já encontrou um comprovante três semanas tarde demais, você já sabe que ele deveria ter sido feito no dia em que chegou.