Em julho de 2026, eu não escolheria uma plataforma com base apenas no gráfico de burn rate. Praticamente qualquer produto consegue dividir o caixa disponível pelo consumo mensal. As ferramentas realmente úteis preservam os fatores por trás desse número: recebimentos, datas de pagamento da folha, contratos anuais de software, serviço da dívida, premissas de captação e descasamentos de capital de giro escondidos em uma DRE aparentemente saudável.
Os valores financeiros apresentados neste artigo são exemplos ilustrativos, criados para representar uma empresa brasileira de médio porte. Eles não são benchmarks de mercado.
Quais plataformas para acompanhar runway e burn rate vale a pena considerar?
| Plataforma | Melhor aplicação | Controle do modelo | Automação de dados | Principal limitação |
|---|---|---|---|---|
| Runway | Startups criando planos operacionais baseados em direcionadores | Alto | Alto | Menos natural para modelos transacionais muito personalizados |
| Drivetrain | Equipes financeiras que trabalham com cenários frequentes | Alto | Alto | A configuração exige disciplina |
| Mosaic | Equipes focadas em relatórios e visibilidade de métricas | Médio | Alto | Lógicas muito específicas podem ficar limitadas |
| Google Sheets | Analistas que precisam controlar completamente as fórmulas | Muito alto | Baixo sem dados conectados | Finanças continua responsável por versões e atualizações |
Esses produtos não são equivalentes. Runway e Drivetrain são sistemas de planejamento. Mosaic tem maior foco em relatórios conectados e análise. Já o Google Sheets é uma superfície de modelagem que só se transforma em uma plataforma de runway depois que a equipe financeira estrutura corretamente as integrações, premissas e fórmulas.
Essa diferença importa. Em um exemplo ilustrativo, uma empresa com R$ 12,5 milhões em caixa e pagamentos operacionais líquidos médios de R$ 1,18 milhão por mês parece ter 10,6 meses de runway. Mas, se R$ 4,2 milhões em renovações anuais vencerem nos próximos 90 dias, a média aritmética estará tecnicamente correta e operacionalmente inútil.
Runway: melhor para planejamento baseado em direcionadores
Runway é uma opção adequada quando o modelo operacional precisa continuar compreensível para os gestores de cada área sem simplificar demais a lógica financeira. Quadro de funcionários, vendas contratadas, recebimentos, remuneração e fornecedores podem ser tratados como direcionadores, em vez de ficarem escondidos em referências de células.
Considere uma empresa hipotética com receita anualizada de R$ 42 milhões, margem bruta de 38,5% e um plano de contratação que leva a equipe de 147 para 181 pessoas. Finanças pode comparar o cenário-base com um congelamento de contratações por 90 dias sem reconstruir toda a lógica da folha de pagamento em cada cenário.
O benefício não está apenas em uma apresentação mais organizada. Uma projeção de runway muda porque as premissas mudaram, e o Runway facilita a inspeção dessas relações. É bem mais simples do que navegar por uma pasta de trabalho com abas chamadas Base, Base_v2, Conservador_Final e, inevitavelmente, Conservador_Final2.
A limitação aparece quando o modelo é muito específico. Um DCF para um sindicato de bancos, com várias tranches de dívida, amortizações obrigatórias, mecanismos de cash sweep, covenants e múltiplos de saída, provavelmente continuará mais confortável no Excel ou no Google Sheets.
Drivetrain: melhor para FP&A com muitos cenários
Drivetrain atende bem equipes financeiras que precisam relacionar cenários operacionais aos dados dos sistemas de origem, mas não querem entregar o modelo a uma caixa-preta. Seu caso de uso natural é a atualização recorrente de projeções: sensibilidade do runway ao ritmo de contratações, prazo de recebimento, capacidade comercial e compressão da margem bruta.
Veja três cenários ilustrativos construídos sobre o mesmo modelo operacional:
| Cenário | Caixa no fim do mês | Burn rate líquido mensal | Runway estimado |
|---|---|---|---|
| Plano-base | R$ 12,5 mi | R$ 1,18 mi | 10,6 meses |
| Contratações congeladas | R$ 13,4 mi | R$ 910 mil | 14,7 meses |
| Recebimentos mais lentos | R$ 10,9 mi | R$ 1,32 mi | 8,3 meses |
A tabela só é confiável se cada cenário preservar as relações entre contratações, encargos da folha, licenças de software, comissões, contas a receber e caixa. O Drivetrain é interessante quando FP&A precisa executar essa análise de sensibilidade toda semana, e não apenas durante o planejamento anual.
Sua limitação é menos chamativa: a implementação não elimina o trabalho de modelagem. Alguém ainda precisa definir a lógica das métricas, mapear contas, configurar os direcionadores da projeção e resolver divergências entre os sistemas de origem.
O software também não consegue decidir sozinho se uma despesa de reestruturação deve entrar no burn rate ajustado. Essa discussão ainda vai chegar à caixa de entrada de Finanças.
Mosaic: melhor para relatórios e análise de variações
Mosaic faz mais sentido quando a liderança quer uma visão integrada do desempenho financeiro e operacional. A plataforma pode funcionar entre os sistemas de origem e o material trimestral do conselho, reduzindo o trabalho recorrente de reconstruir relatórios de realizado contra orçamento.
Isso é útil quando a conversa sobre runway depende de mais do que o saldo de caixa. Em um exemplo hipotético, uma variação desfavorável de R$ 260 mil no burn rate pode ter sido causada por recebimentos mais fracos, antecipação de contratações ou pagamento pontual de um seguro empresarial. Cada causa tem uma implicação diferente para a projeção.
A orientação do Mosaic para relatórios também representa sua principal limitação. Se o modelo de runway contém cascatas específicas da empresa, mecânicas detalhadas de dívida ou uma lógica de margem de contribuição por SKU, a equipe financeira pode atingir os limites do produto antes do esperado.
O Mosaic tende a fazer mais sentido quando o principal problema está nos relatórios gerenciais e o runway é apenas um dos resultados analisados. Se o desafio central é construir e testar o plano operacional sob diferentes condições, Runway ou Drivetrain costumam ser opções mais naturais.
Google Sheets: melhor para controle total do modelo
O Google Sheets continua sendo uma opção sólida porque não impõe a arquitetura do modelo. Um analista pode manter abas separadas para DRE, Balanço Patrimonial, Fluxo de Caixa, Quadro de Funcionários, Premissas, Runway e Análise de Retorno, preservando relações explícitas entre elas.
Um modelo de runway pode buscar as despesas operacionais com efeito caixa na DRE a partir da data inicial da projeção:
=SUMIFS('DRE'!C:C, 'DRE'!B:B, ">=" & Premissas!$B$3)
Uma saída mais útil identifica o último período antes de o caixa projetado ficar negativo:
=INDEX('Fluxo de Caixa'!$F$12:$Q$12, 1, MATCH(TRUE, 'Fluxo de Caixa'!$F$12:$Q$12<0, 0)-1)
Esse resultado pode ser mais útil do que dividir o caixa atual pelo burn rate médio dos últimos três meses quando os pagamentos são irregulares.
Segundo a documentação do Google, uma planilha pode conter até 10 milhões de células, com no máximo 18.278 colunas. Para um modelo de runway de FP&A, a capacidade raramente é o principal obstáculo. Os desafios reais são controle, confiabilidade das atualizações e facilidade de revisão. Consulte os limites de arquivos documentados pelo Google Drive.
O ModelMonkey funciona nesse contexto como uma camada de conexão dentro do Google Sheets ou do Excel. Ele pode importar e transformar dados dos sistemas de origem, criar tabelas atualizáveis e ajudar na inspeção de fórmulas, enquanto o analista mantém a projeção de caixa na planilha. Isso reduz parte do trabalho manual sem obrigar a empresa a adaptar sua apresentação trimestral para investidores a uma estrutura fixa de planejamento.
O custo está na responsabilidade sobre o modelo. Finanças precisa manter as importações, proteger fórmulas, controlar as versões dos cenários e identificar referências que mudaram silenciosamente depois que alguém inseriu três colunas na aba Quadro de Funcionários.
O que uma plataforma de runway deve calcular?
Uma plataforma séria deve calcular o runway a partir dos saldos de caixa projetados, e não de uma única média de burn rate. O burn rate líquido mensal continua sendo uma métrica útil, mas deve explicar a projeção, não funcionar como seu motor principal.
A relação central é:
Burn rate líquido = saídas operacionais de caixa - entradas operacionais de caixa
Runway = meses até o caixa final projetado ficar abaixo do limite mínimo de liquidez
O limite mínimo pode ser R$ 0, mas muitas vezes não deveria ser. Se o conselho exige uma reserva de liquidez de R$ 5 milhões ou se uma linha de crédito possui um covenant de caixa mínimo, por exemplo, o runway termina quando esse limite é violado.
A projeção também deve separar burn rate bruto de burn rate líquido. Em um exemplo ilustrativo, uma empresa que recebe R$ 3,5 milhões por mês e desembolsa R$ 4,68 milhões tem burn rate bruto de R$ 4,68 milhões, mas burn rate líquido de R$ 1,18 milhão. Confundir as duas métricas torna comparações internas e externas pouco confiáveis.
Paul Graham resumiu a questão do financiamento ao perguntar se uma startup está "default alive or default dead", ou seja, se conseguirá chegar à lucratividade com o caixa disponível ou se dependerá de uma nova captação. O teste obriga a projeção a relacionar crescimento da receita, despesas e caixa restante, em vez de tratar o runway como uma simples contagem regressiva.
Como avaliar plataformas para acompanhar runway e burn rate?
Uma boa avaliação deve usar um ciclo real de projeção, e não apenas os dados de demonstração do fornecedor. O teste precisa reproduzir um fechamento mensal, um cenário conservador e uma explicação da variação adequada para o conselho.
-
Concilie o caixa inicial. Relacione a plataforma ao balanço patrimonial e aos saldos bancários até o último real. Mesmo uma diferença relativamente pequena precisa ter uma explicação.
-
Carregue um plano operacional realista. Inclua o quadro de funcionários, pelo menos 24 meses de projeção, pagamentos anuais de fornecedores, comissões, serviço da dívida e encargos da folha. Uma demonstração com poucas linhas de despesas não comprova a robustez da plataforma.
-
Altere direcionadores relacionados. Em um teste ilustrativo, adie dez contratações por 90 dias, reduza as vendas contratadas em 12% e aumente o DSO de 43 para 58 dias. Confirme se folha, receita, contas a receber, recebimentos e caixa final mudam corretamente.
-
Explique a ponte do runway. A plataforma deve mostrar por que o runway caiu, por exemplo, de 14,6 para 11,9 meses. "Projeção atualizada" não é uma explicação suficiente.
-
Reconstrua o material trimestral do conselho. Teste exportações, comentários, identificação dos cenários e formatação dos gráficos. Se Finanças precisar corrigir todos os gráficos depois da exportação, a plataforma apenas transferiu o trabalho de lugar.
O ponto de falha menos óbvio costuma ser o momento das entradas e saídas de caixa, e não a sofisticação da projeção. Uma DRE bem modelada ainda pode errar o mês em que o dinheiro termina se seguros anuais, impostos, bônus e recebíveis estiverem distribuídos como médias mensais.
No Brasil, esse cuidado também deve incluir o calendário tributário e operacional. ICMS, PIS e Cofins, parcelamentos, antecipações de recebíveis, férias, 13º salário e diferenças entre emissão de NF-e e pagamento efetivo podem alterar bastante o caixa de um mês específico, mesmo sem uma mudança relevante na DRE.
Plataformas dedicadas são melhores do que planilhas?
Plataformas dedicadas levam vantagem quando a atualização de dados, a colaboração entre áreas e a criação recorrente de cenários consomem mais tempo do que a modelagem personalizada. Google Sheets e Excel vencem quando lógicas específicas de uma transação e rastreabilidade das fórmulas são mais importantes.
Um divisor prático é a frequência das projeções. Se FP&A atualiza uma previsão de caixa de 24 meses uma vez por trimestre, a migração para outra plataforma pode gerar pouca economia. Se os dados realizados são atualizados toda semana e a diretoria pede vários cenários no mesmo dia, um software de planejamento conectado começa a justificar sua assinatura.
Não trate a responsabilidade pelas fórmulas apenas como uma desvantagem. Em um DCF para um sindicato de bancos ou em um modelo de covenants, visualizar a fórmula exata faz parte do ambiente de controle. O problema começa quando os analistas passam horas todos os meses baixando dados de ERPs, bancos e sistemas de cobrança antes mesmo de conseguirem revisar a projeção.
Perguntas frequentes sobre runway e burn rate
Qual é a melhor plataforma para acompanhar runway e burn rate?
A melhor plataforma depende do fluxo de trabalho da equipe. Runway é indicada para planejamento baseado em direcionadores, Drivetrain para análises frequentes de cenários, Mosaic para relatórios conectados e Google Sheets para modelos personalizados com controle direto das fórmulas.
Como calcular o runway de uma empresa?
Projete o saldo de caixa de cada mês usando recebimentos, folha, fornecedores, impostos, dívidas e outros movimentos esperados. O runway corresponde ao número de meses até o caixa ficar abaixo do limite mínimo de liquidez definido pela empresa.
Qual é a diferença entre burn rate bruto e líquido?
Burn rate bruto é o total das saídas de caixa no período. Burn rate líquido é a diferença entre as saídas e as entradas operacionais de caixa. Uma empresa pode ter desembolsos elevados e, ainda assim, apresentar burn rate líquido baixo se seus recebimentos forem suficientes para compensar boa parte das saídas.
Google Sheets é suficiente para controlar o runway?
Sim, desde que a equipe tenha processos sólidos de atualização, conciliação, proteção de fórmulas e controle de versões. O Google Sheets oferece flexibilidade, mas não substitui automaticamente as integrações, a governança e a manutenção exigidas por um modelo financeiro confiável.
Com que frequência o runway deve ser atualizado?
A frequência deve acompanhar a volatilidade do negócio. Empresas com caixa apertado, recebimentos instáveis ou contratações aceleradas podem precisar de atualizações semanais. Empresas mais previsíveis podem atualizar a projeção mensalmente, sempre após a conciliação do fechamento.
O runway deve considerar impostos brasileiros?
Sim. A projeção precisa refletir as datas efetivas de pagamento de ICMS, PIS, Cofins e outros tributos aplicáveis, além de férias, 13º salário e parcelamentos. Distribuir essas despesas igualmente entre os meses pode esconder picos relevantes de consumo de caixa.
Em resumo: qual plataforma escolher?
Escolha Runway quando o planejamento baseado em direcionadores e a facilidade de uso pelos gestores de área forem prioritários. Escolha Drivetrain quando FP&A precisar executar cenários operacionais frequentes e interligados. Escolha Mosaic quando os principais desafios forem relatórios conectados e visibilidade das variações. Mantenha o Google Sheets quando controle das fórmulas, modelagem personalizada e distribuição simples da planilha forem mais importantes.
A melhor plataforma é aquela que explica o movimento do caixa, e não apenas o saldo final. Um número de runway sem uma ponte até contratações, recebimentos, margem e datas de pagamento é apenas decoração.