Numa instituição pública com a qual colaborei, o orçamento anual tinha duas estações. No início do ano, cada área pedia a maior dotação que conseguisse. Se a verba acabava a meio do exercício, acabavam os cabimentos, e compras necessárias ficavam por fazer. Se sobrava dinheiro em novembro, o incentivo invertia-se: havia que gastá-lo antes do fecho, porque uma execução baixa tornava mais difícil defender a mesma verba no ano seguinte.
Nas empresas, o orçamento económico faz-se de baixo para cima, normalmente em Excel. As áreas dizem o que esperam faturar ou gastar e defendem esses números perante a administração, que os corta ou aumenta, por vezes, de forma discricionária.
A este exercício, chamamos planeamento financeiro, com uma boa parte do seu tempo investido em negociação. Quando o número entra na avaliação e no prémio, quem o propõe responde a duas perguntas: o que vai acontecer, e quanto quer que esperem de si. A tesouraria tende a ser mais honesta, por necessidade (há limites duros quanto a disponibilidades financeiras e prazos de pagamento).
Michael Jensen, da Harvard Business School, deu a este mecanismo um título pouco diplomático em 2003: Paying People to Lie. Quando a remuneração depende da distância ao orçamento, argumentava, chefes e subordinados mentem ao construí-lo e fazem jogo ao executá-lo.
A empresa fica sem a informação imparcial de que precisa para coordenar as suas partes. (O próprio Jensen admitia que a evidência sobre o custo disto era escassa.)
A crítica é mais antiga do que o artigo: o Handelsbanken sueco deixou de fazer orçamentos no início dos anos 70, com Jan Wallander, que os considerava um mal desnecessário. Em 1998, Jeremy Hope e Robin Fraser fundaram o movimento “Beyond Budgeting” e fizeram do banco o seu caso de referência. A proposta troca o orçamento anual por previsões deslizantes e dá mais autonomia a quem decide
Mudou alguma coisa nestes processos financeiros?
Eu achava que este mundo antigo já deveria ter acabado. Hoje, há plataformas de planeamento na cloud e modelos de linguagem capazes de comentar um balancete com mais paciência do que muitos contabilistas. Mas os inquéritos às equipas de planeamento financeiro contam outra história.
No inquérito de 2025 da Association for Financial Professionals (AFP), 96% dos profissionais de planeamento financeiro usavam folhas de cálculo para planear, independentemente da dimensão da empresa. Dos mesmos inquiridos, 71% usavam também, pelo menos uma vez por trimestre, plataformas de gestão do desempenho (EPM).
Mesmo assim, as folhas de cálculo continuam a sustentar o planeamento: 82% usam-nas para preparar os dados que entram na plataforma e 57% para o contornar. A empresa comprou o sistema, e o Excel ficou a trabalhar à volta dele.
A série da FP&A Trends pergunta desde 2017 quanto tempo demora a produzir um forecast. Em 2017, 23% das organizações produziam-no em dois dias ou menos; em 2025, só 15% did. O tempo médio subiu de 5,75 para 6,09 dias entre 2017 e 2024, e a parte que considera os seus forecasts bons ou muito bons (42% em 2024) era praticamente a mesma do primeiro ano. A recolha e validação de dados ocupa 46% do tempo destas equipas, o valor mais alto dos últimos cinco anos.
Os números de 2026 não alteram o quadro. A AFP encontrou um ciclo orçamental de quase nove semanas, igual há três anos, e concluiu que o investimento em tecnologia de planeamento ainda não trouxe os ganhos de eficiência esperados. Num inquérito a 314 organizações sobre a tecnologia das equipas financeiras, a Gartner voltou a encontrar as folhas de cálculo como a tecnologia mais adotada e registou uma perda de valor e de investimento nas plataformas de planeamento alargado.
Convém ler estes números com cuidado. Os inquéritos da FP&A Trends são patrocinados por fornecedores de software de planeamento (a SAP em 2024, a OneStream em 2025) e a qualidade do forecast é autoavaliada. As amostras pesam para o lado das grandes empresas: em 2025, só 8% dos inquiridos trabalhavam em empresas com menos de 25 milhões de dólares de receita. Mesmo assim, é difícil acusar de pessimismo quem vende plataformas de planeamento.
Os dias de trabalho investem-se noutra coisa. O software calcula em segundos o que antes levava uma tarde, mas o calendário do forecast continua marcado pelas pessoas que enviam números e pelas que os discutem. E o número continua a ser negociado: em 2025, 38% das organizações ainda planeavam com “o ano passado mais x%”, um método de negociação com aspeto de método de previsão.
O que fazem as equipas financeiras de elite?
Há empresas onde este ciclo encurtou. Os casos publicados vêm quase inteiramente de fornecedores e consultoras: KeyBank diz ter reduzido o seu forecast de mais de cinco dias para um, numa das maiores transformações financeiras feitas sobre Workday nos Estados Unidos. Na Umicore, o diretor financeiro conta que um ciclo completo de forecast ocupava uma semana de trabalho e agora cabe em menos de um dia.
O que os dois descrevem é sobretudo trabalho manual que desapareceu: dados que antes se introduziam manualmente entram agora sozinhos no modelo. A outra peça que distingue as melhores equipas é o modelo assente em drivers.
Em vez de prever centenas de linhas de contas, prevê-se o volume, o preço, as pessoas e o prazo médio de recebimento, e as contas fazem o resto. Isto tem uma vantagem que raramente é percetível. Num modelo por drivers, quem quer defender um número tem de defender os pressupostos.
Na FP&A Trends, 77% das organizações com modelos total ou dinamicamente assentes em drivers dão nota boa ou muito boa aos seus forecasts, contra 27% das que usam modelos básicos ou nenhum modelo. É uma correlação autoavaliada (equipas competentes tendem a ter ao mesmo tempo bons modelos e bons forecasts), e a diferença já aparecia em 2024.
O que as competições de previsão mostram sobre os métodos
Os métodos estatísticos prolongam o histórico de uma série segundo uma forma escolhida à partida. O exponential smoothing, por exemplo, faz uma média em que os meses recentes pesam mais do que os antigos e junta-lhe tendência e sazonalidade. O ARIMA liga cada valor aos valores e aos erros dos períodos anteriores. Têm poucos parâmetros e funcionam com pouco histórico (e existem há mais de meio século).
O machine learning inverte a lógica: em vez de ser o analista a escolher a forma, o algoritmo aprende-a a partir de muitos exemplos, e pode usar dados que não estão na própria série, como o preço ou o calendário de promoções. Em previsão, muitos métodos desta família juntam centenas de árvores de decisão, cada uma corrigindo os erros das anteriores.
O deep learning é um ramo do machine learning que usa redes neuronais com muitas camadas (daí o termo “profundo”) e pertence à mesma família dos modelos de linguagem. Quanto mais flexível o método, mais dados pede e mais difícil é perceber porque prevê o que prevê.
Para saber que métodos preveem melhor, Spyros Makridakis organiza competições de forecasting desde 1982. Os organizadores retêm os valores mais recentes de séries reais e pedem a equipas de todo o mundo que os prevejam. Ganha quem se aproximar mais do que aconteceu. A M4, a quarta edição, terminou em 2018 e pôs 61 métodos a prever as mesmas 100 mil séries.
O resultado desiludiu quem esperava uma vitória das máquinas: nenhum dos seis métodos puros de machine learning bateu a simples média de três métodos estatísticos, e ganhou um híbrido que juntava as duas famílias. (Anos depois, investigadores da Amazon correram uma rede neuronal pura sobre as mesmas séries, sem afinações especiais, e ficaram perto do vencedor.)
Na competição M5, em 2020, o problema era outro: 42.840 séries de vendas do Walmart, muitas parecidas entre si e acompanhadas de dados externos. Nesta, o machine learning ganhou.
Para uma empresa média, a lição é prática. O forecast tem umas dezenas de rubricas com cinco anos de dados mensais, e nesse terreno os métodos simples costumam ganhar, por enquanto. Os métodos assentes em machine learning compensam quando há milhares de séries semelhantes e variáveis que as expliquem. A complexidade tem de ser ganha contra uma alternativa simples, e isso só se sabe testando.
Independentemente do método, como avaliar a eficácia do forecast?
Um sistema de forecast precisa de algo que os modelos em Excel geralmente fazem mal: lembrar-se do que previram. Se em abril previmos setembro e em julho voltamos a prever setembro, a diferença entre as duas versões diz mais do que a comparação com um orçamento feito em outubro do ano anterior. Com controlo de versões, também se mede onde a empresa erra e a partir de que horizonte.
Suponha-se que o EBITDA esperado para o ano cai de 4,2 para 3,7 milhões de euros entre duas versões. O sistema decompõe a diferença: 360 mil euros vêm da margem de um negócio, 140 mil do atraso na entrada de dois clientes. A alteração passa o limiar de materialidade que a empresa definiu e antecipa uma falta de liquidez daqui a cinco meses.
Um modelo de linguagem (LLM) ajuda a escrever um parágrafo com a causa da alteração e a decisão que ela exige: compara as versões e propõe uma explicação. A previsão em si fica com modelos que se podem testar contra o que aconteceu. Num guia de implementação publicado em março de 2026, a Gartner descreve a previsão de tesouraria com IA como o uso de técnicas tradicionais assentes em drivers, que produzem previsões probabilísticas e explicáveis para planear liquidez e cenários.
O que pode fazer uma empresa média sem gastar milhões?
A arquitetura que dá resposta a esta questão tem seis camadas e pode assentar no SAF-T, no ERP ou numa mistura dos dois. Nenhuma camada exige uma plataforma de planeamento. O investimento vai quase todo para o desenho do modelo e para as primeiras semanas de trabalho; licenças e infraestrutura pesam pouco.
1. Fontes de dados
Cada driver deve vir da fonte mais rápida que o serve. O SAF-T tem a vantagem de ser igual em todos os programas certificados. O de faturação traz as vendas linha a linha e segue para as Finanças até ao dia 5 do mês seguinte. O de contabilidade traz todos os lançamentos e tem de poder ser produzido numa inspeção, embora a entrega regular continue adiada.
Uma empresa com um ERP integrado pode ler diretamente a base de dados ou a API, e ganha encomendas em carteira, stocks e centros de custo com atualização diária.
| Origem | O que alimenta | Frequência |
|---|---|---|
| SAF-T de faturação | Vendas por cliente, produto, quantidade e preço | Mensal (até dia 5) ou em tempo real |
| SAF-T de contabilidade ou balancete | Resultados e balanço por conta | Depois do fecho |
| Base de dados ou API do ERP | Encomendas, compras, stocks, centros de custo | Diária |
| Bancos, por open banking | Saldos e movimentos | Diária |
| Processamento salarial | Pessoas e custo por pessoa | Mensal |
| CRM | Oportunidades e datas previstas de fecho | Diária |
O limite de todas as fontes contabilísticas é o fecho. A declaração mensal de IVA de dezembro entrega-se até 20 de fevereiro, e uma contabilidade que feche a esse ritmo entrega o realizado com mês e meio de atraso. Um acordo escrito com o contabilista para fechar até ao décimo dia útil é a linha mais barata do projeto.
2. Infraestrutura de dados
Tarefas agendadas leem os ficheiros e as APIs e gravam tudo numa pequena base de dados na cloud, em duas zonas: a dos dados tal como chegaram e a dos dados tratados. Entre as duas fica a peça mais valiosa do projeto, uma tabela que liga cada conta e cada artigo ao driver que alimenta. Todos os meses, os dados tratados têm de bater com o balancete (se não batem, o forecast parte de um número errado com toda a confiança).
O acesso é restrito por perfil, porque o SAF-T de contabilidade contém tudo e os salários são dados pessoais. As ferramentas podem ser as que a empresa já paga, ou uma pilha leve com uma base de dados PostgreSQL e rotinas em Python.
3. Modelos
O centro é um modelo financeiro por drivers: 15 a 25 drivers, cada um com dono, fonte, método e frequência, e as demonstrações financeiras ligadas entre si, com a caixa a sair dos prazos médios e um horizonte que rola doze a dezoito meses para a frente. O que muda de driver para driver é o método de previsão, e a escolha faz-se por concurso.
| Família | Quando serve | Investimento |
|---|---|---|
| Regras | Relações conhecidas: salários, contratos, prazos de pagamento | Horas de desenho |
| Estatísticos (ETS, ARIMA, Theta e combinações) | Séries mensais sem variáveis externas; são a linha de base | Bibliotecas gratuitas |
| Machine learning (árvores de decisão combinadas) | Muitas séries parecidas com variáveis explicativas, como vendas por cliente ou produto com preços e pipeline | Semanas de desenvolvimento e dados limpos |
| Deep learning pré-treinado | Candidato extra, sem treino próprio, com modelos como o Chronos, da Amazon | Baixo para usar; o custo está no teste |
Treinar redes neuronais de raiz raramente se justifica a esta escala, porque pedem muitos dados. Os modelos pré-treinados mudam a conta: no teste dos próprios autores, o Chronos bateu os modelos estatísticos locais em séries que nunca tinha visto, um resultado que tem de ser confirmado nas séries de cada empresa. A regra é igual para todos os candidatos. Cada um entra num backtest contra uma previsão ingénua sazonal, e em produção fica o melhor ou uma combinação (na M4 ganharam as combinações; na M5, o machine learning com muitas séries e variáveis explicativas).
4. Versões e medição
Cada ciclo grava a linha de base e cada ajuste feito por cima dela, com autor e justificação, e nada se reescreve. Esta tabela permite medir o erro por horizonte e enviesamento, e aplicar o teste a que Michael Gilliland chama forecast value added: cada ajuste tem de melhorar a previsão ingénua, e um ajuste que não melhora é removido. Há boas razões para o fazer.
Em mais de 60 mil previsões de quatro empresas, os ajustes pequenos pioravam muitas vezes o resultado e os ajustes para cima erravam mais vezes de direção (embora, em média, os ajustes ajudassem em três das quatro). Antes de arrancar, reconstrua-se os últimos 24 a 36 meses só com a informação disponível em cada data, para os comparar com a previsão ingénua e o orçamento antigo. É a primeira prova a mostrar à administração.
5. Explicação
A decomposição faz-se no modelo financeiro: entre duas versões, cada driver recebe a parte da diferença que lhe cabe, em euros. As regras de materialidade, definidas pelo CEO e pelo CFO, decidem quando isso chega a alguém (por exemplo, o EBITDA do ano mudar mais de 100 mil euros ou 2%, ou a caixa prevista descer abaixo do mínimo nos próximos seis meses).
Quando uma regra dispara, o sistema prepara um pequeno ficheiro com as duas versões, os drivers ordenados por impacto, os comentários dos donos e o nome de quem decide. Um modelo de linguagem (LLM) escreve a partir desse ficheiro um parágrafo curto. Uma verificação automática confirma que cada número no texto existe no ficheiro, e o controller aprova antes de o parágrafo seguir. (As plataformas de topo já vendem isto como análise automática de desvios.)
O RAG (retrieval-augmented generation) gera explicações apoiadas em pesquisa. Entra no processo quando uma explicação precisa de documentos: contratos, notas comerciais, atas, emails das áreas. Esses documentos são indexados, e a pesquisa devolve excertos com a indicação da fonte, que o modelo usa para dar contexto. Os números continuam provenientes do modelo financeiro.
Numa empresa média, o contexto de um mês cabe muitas vezes numa única instrução, e o RAG pode esperar. O comentário mensal custa menos do que um café.
6. Entrega e governação
O CEO recebe o parágrafo quando uma regra dispara e uma página por mês (não precisa sequer de abrir um dashboard). O forecast fica fora da remuneração variável e separado do objetivo, para que quem o faz não tenha razões para o enviesar.
O CFO é dono do modelo, o controller corre o ciclo mensal e cada driver tem alguém que responde por ele. A própria lógica do modelo tem versões, com a data e a razão de cada alteração.
Investimento e calendário
Numa empresa de 20 a 50 milhões de faturação anual, a primeira versão requer cerca de nove semanas de desenvolvimento. O calendário tem quatro fases: duas semanas para as decisões de desenho do sistema, três para as fontes de dados, a infraestrutura e o modelo, duas para seleção de métodos e controlo de versões e duas para a explicação.
Seguem-se três ciclos em paralelo com o processo antigo, antes de o desligar. As licenças e a cloud pesam pouco na estrutura. O investimento está no trabalho de desenho do modelo e de quem conduz as conversas com a administração. Uma equipa com um CFO capaz de desenhar drivers e alguém que saiba ligar dados consegue montar a arquitetura sozinha.
Limites
Esta arquitetura acelera a recolha dos números e a criação do forecast. Apesar disso, há duas coisas que não resolve: o fecho tardio da contabilidade e a construção do forecast com base no resultado pretendido, em vez de uma produtiva discussão dos pressupostos (caso em que volta a ser uma negociação, por melhor que seja o modelo).
São problemas de organização, e os inquéritos sugerem que pesam mais do que a tecnologia nas grandes empresas. Em 2024, 31% das organizações relatavam conflitos de interesses entre a sede e as unidades de negócio, e 13% admitiam que os planos eram influenciados politicamente. Em 2025, a falta de processos integrados entre departamentos era apontada como barreira duas vezes mais do que a falta de um sistema comum (42% contra 21%).
Uma empresa média, com um diretor financeiro e um controller, tem menos gente a negociar o número e menos camadas políticas, por isso pode tirar mais proveito desta arquitetura do que algumas multinacionais tiraram de uma plataforma de elite. É só uma hipótese que vale a pena testar.
Construir a arquitetura acima exige a combinação certa de competências financeiras e de dados. Se quiseres uma segunda opinião sobre a tua configuração, fala connosco.[Contacta-nos →]
Post Views: 25
