Quase todos os proprietários de software começam a conversa com um número: a receita recorrente anual. É o número certo por onde começar e quase nunca é o número que o comprador acaba por multiplicar.
Entre o ARR da apresentação do fundador e o ARR do contrato de compra e venda existe uma série de deduções. Receita recorrente apenas no nome, mas cancelável mensalmente. Implementação e personalização contabilizadas como subscrição. Contratos que se renovam ao critério do cliente e que ainda não foram postos à prova. Uma conta grande que já deu a entender discretamente que vai sair. Tudo isto aparece na due diligence, e cada ponto move o múltiplo e não a linha da receita — por isso uma correção de 400 mil euros ao ARR pode custar sete dígitos de valor da empresa.
Este artigo expõe o que o comprador paga num negócio de software, quanto o mercado está a pagar em 2026, como o churn e o desenvolvimento à medida comprimem o múltiplo e o que um proprietário deve corrigir no ano anterior a ir para o mercado.
Por quanto se vendem realmente as empresas de software
A distância entre perceção e realidade é maior no software do que em qualquer outro setor com que trabalhamos, porque os proprietários continuam ancorados em 2021.
Os dados da Software Equity Group para o segundo trimestre de 2026 colocam a empresa SaaS cotada mediana em 3,2x a receita dos últimos doze meses, face a 5,7x um ano antes. As operações privadas aguentaram melhor: a aquisição SaaS mediana fechou a 4,0x receita, contra 4,2x no ano anterior, com uma média de 6,2x — a diferença entre mediana e média é o punhado de ativos premium que puxa o valor médio para cima.
O volume, por seu lado, está em máximos. A SEG registou 2.784 operações SaaS nos doze meses até ao segundo trimestre de 2026, o período mais ativo da sua base de dados, com 698 só no trimestre, mais 9,6% em termos homólogos. Esta é a conclusão estrutural para um proprietário: não faltam compradores nem operações fechadas. Faltam compradores dispostos a pagar preços de 2021, e o mercado tornou-se bastante mais seletivo quanto ao que considera qualidade.
Dois esclarecimentos poupam muita negociação inútil. Primeiro: um múltiplo sobre ARR e um múltiplo sobre a receita dos últimos doze meses não são a mesma coisa, e a diferença equivale a cerca de um ano de crescimento; aplicar um múltiplo de ARR a referências construídas sobre receita passada sobrevaloriza o negócio. Segundo: as referências privadas publicadas para empresas mais pequenas ficam bem abaixo dos números de manchete — para negócios autofinanciados com alguns milhões de ARR, o ponto de partida realista é 3x a 5x, e não os 8x a 12x que circulam nas comunidades de fundadores. Na Conclave Partners preferimos fixar essa expectativa na primeira reunião a descobri-la na décima semana do processo.
O que o comprador entende por "recorrente"
A primeira tarefa do comprador na due diligence é reconstruir o ARR a partir dos contratos em vez de o aceitar do painel de indicadores. O proprietário devia fazer esse exercício primeiro.
Contratado versus implícito
A receita recorrente contratada é aquilo que os clientes se comprometeram legalmente a pagar durante um prazo definido. O ARR implícito é um valor mensal multiplicado por doze. Uma carteira de clientes mensais pode ser perfeitamente saudável e ainda assim ser avaliada de forma diferente de contratos anuais com renovação automática, porque o comprador está a pôr preço no que sobrevive a uma mudança de propriedade e a um aumento de preços.
Serviços vestidos de subscrição
As taxas de implementação, a migração de dados, a formação, a configuração e o suporte pago são partes normais de um negócio de software e receita legítima. Não são recorrentes, e os compradores separam-nas. Quando as taxas de arranque foram diluídas na linha da subscrição, a reformulação torna-se desconfortável.
Consumo, excessos e vendas pontuais
A receita por consumo é real mas volátil, e os compradores descontam-na face à subscrição contratada. Os excessos que surgiram porque um cliente teve um ano atípico são normalizados. As licenças perpétuas e a revenda de hardware são avaliadas como um fluxo separado, com múltiplo inferior.
A retenção é o múltiplo
Se a qualidade do ARR decide o que é multiplicado, a retenção decide o próprio múltiplo. Nada mais num negócio de software o move tanto.
O inquérito da SaaS Capital de 2026, a mais de 1.000 empresas privadas de SaaS B2B com 3 a 20 milhões de dólares de ARR, dá as referências atuais: retenção líquida de receita mediana de 103% e retenção bruta mediana de 91%, com o decil superior em 117,9% e 100% respetivamente. O crescimento mediano da mesma amostra caiu para 15%, vindo de 20% no ano anterior, enquanto a retenção se manteve praticamente estável.
Daqui decorrem duas coisas para o vendedor. Primeira: ambas as métricas são examinadas, e a retenção bruta é o teste mais duro. Uma retenção líquida acima de 100% é muitas vezes sustentada pela expansão dentro de meia dúzia de contas grandes enquanto a base perde clientes em silêncio; os compradores separam as duas precisamente porque uma empresa pode mostrar 105% de NRR e 82% de GRR, e essa combinação é avaliada como um problema de churn, não como uma história de crescimento. Segunda: estar na mediana não é uma fraqueza — a mediana é a referência. O erro é apresentar uma retenção mediana como excecional, o que custa credibilidade a todas as outras afirmações do modelo.
O churn de clientes merece apresentação separada do churn de receita. Um negócio que perde 20% dos clientes mas apenas 8% da receita está a perder contas pequenas, e isso é uma história gerível. O contrário não é.
O problema do desenvolvimento à medida
É a causa mais frequente de uma empresa de software ser reavaliada em baixa, e aquela que os proprietários mais defendem em vez de corrigir.
Muitas empresas de software rentáveis do lower middle market obtêm uma parte substancial da receita de trabalho à medida: funcionalidades construídas para um só cliente, integrações faturadas à hora, personalização contínua que nunca chega a ser produto. Paga bem e parece software. Para o comprador é um negócio de serviços colado a um produto, e os negócios de serviços transacionam a uma fração dos múltiplos do software.
O efeito surge em três sítios ao mesmo tempo. A margem bruta cai abaixo da faixa de 75–85% que os compradores esperam, e a margem é um dos primeiros filtros aplicados. A receita passa a depender do número de pessoas, pelo que crescer exige contratar e não implementar. E a base de código fragmenta-se em variantes por cliente, o que transforma a due diligence técnica numa lista de riscos e torna o produto mais difícil de vender ao cliente seguinte sem mais trabalho à medida.
O remédio não é recusar trabalho à medida, mas separá-lo e identificá-lo. Reporte receita de produto e receita de serviços como linhas distintas, cada uma com a sua margem. Converta a personalização recorrente em funcionalidades configuráveis do produto sempre que possível. Quando um módulo à medida serve mais do que um cliente, transforme-o em produto e venda-o como módulo. Um negócio que mostra 70% de receita de produto a 82% de margem bruta e 30% de serviços a 40% é avaliado sobre dois fluxos compreensíveis; o mesmo negócio com um único número misturado é avaliado sobre a suspeita. No nosso trabalho na Conclave Partners, esta separação, feita com um ano de antecedência, vale frequentemente mais do que um ano de crescimento do ARR.
Concentração, contratos e base de renovações
A concentração de clientes no software segue a mesma lógica de qualquer outro setor, com um agravante: um contrato de software costuma ser mais fácil de abandonar do que uma relação de fornecimento. Abaixo de cerca de 10% do ARR num único cliente o negócio é tratado como diversificado; entre 20% e 30% a concentração passa a ser uma questão explícita de preço; acima de 30% uma parte apreciável dos compradores retira-se ou reestrutura a operação em torno do risco em vez de negociar o múltiplo.
O arquivo contratual pesa tanto como a concentração. Os compradores examinam prazos de pré-aviso, mecânica de renovação automática, direitos de aumento de preço, cláusulas de cessão e de mudança de controlo, compromissos de disponibilidade e respetivas penalizações, e quaisquer cláusulas invulgares de rescisão por conveniência concedidas há anos para fechar um grande contrato. Os contratos que não podem ser cedidos sem consentimento criam aqui o mesmo problema que os acordos com fornecedores na distribuição: numa venda de ativos têm de ser novados um a um.
Vale a pena verificar o calendário de renovações antes do lançamento. Um processo que faz passar uma grande coorte de renovações pela due diligence fica exposto: se essas renovações escorregarem, o comprador vê a linha de tendência dobrar exatamente no pior momento.
Código, propriedade intelectual e due diligence técnica
A due diligence técnica no software raramente cria valor, mas é frequentemente onde o valor se perde.
A titularidade da propriedade intelectual é a primeira questão, e o defeito mais comum em empresas geridas pelo dono é o trabalho de prestadores externos sem cessão de direitos por escrito. Freelancers, agências deslocalizadas e os primeiros amigos do fundador que escreveram código fundacional precisam todos de cessões documentadas; em várias jurisdições europeias a posição supletiva sem acordo escrito não favorece a empresa. Tem solução, mas é bem mais difícil de resolver depois de o comprador perguntar.
O cumprimento das licenças de código aberto é a segunda. Componentes copyleft embutidos num produto distribuído podem trazer obrigações que os advogados do comprador tratarão como matéria relevante, e um inventário de componentes preparado com antecedência transforma uma bandeira vermelha num ponto de checklist.
A segurança e a proteção de dados são a terceira. Os compradores esperam hoje controlos de acesso documentados, historial de incidentes, registo de subcontratantes e uma posição defensável em matéria de RGPD, sobretudo quando o produto trata dados pessoais entre países. A ausência de certificação não é fatal nesta dimensão; a ausência de qualquer prática documentada é.
Onde tenham sido usadas intensivamente ferramentas de IA para escrever código, conte com perguntas específicas sobre a proveniência e o licenciamento do código gerado e sobre que direitos os fornecedores de modelos mantêm sobre os dados de entrada. Os compradores já perguntam isto por rotina.
Quem compra empresas de software
O universo de compradores mudou, e favorece o vendedor preparado.
Dominam os compradores financeiros. A SEG registou private equity e compradores estratégicos participados por fundos em 59% das operações SaaS do segundo trimestre de 2026 — hoje é mais provável que o comprador de uma empresa de software do lower middle market seja um fundo ou a sua plataforma do que um adquirente industrial independente. Estes compradores são quantitativos, rápidos quando os dados estão limpos e implacáveis com a qualidade da receita. Também estruturam o risco com earn-outs e capital retido em vez de abandonarem a operação.
Os compradores estratégicos pagam pelo que não conseguem construir depressa: uma base de clientes num segmento que lhes falta, uma integração pesada em regulação, um ativo de dados ou uma equipa. Toleram métricas mais fracas se o encaixe for bom, mas demoram mais e envolvem mais interlocutores.
Uma terceira categoria, os consolidadores de pequenas empresas de software vertical, cresceu consideravelmente. Compram a múltiplos disciplinados, fecham de forma fiável e são muitas vezes a resposta certa para o fundador que prefere certeza a preço máximo. Saber a qual dos três um negócio pode realmente interessar, antes de escrever os materiais, é a maior parte do trabalho, e é onde a Conclave Partners passa as primeiras semanas de um mandato de software.
O que corrigir doze meses antes de vender
Reconstrua o ARR a partir dos contratos. Prepare um mapa cliente a cliente com valor contratado, prazo, data de renovação, pré-aviso e quaisquer cláusulas não padronizadas. Este documento vai ser pedido; tê-lo antes de o processo começar muda o tom de todas as conversas seguintes.
Separe a receita de produto da receita de serviços, com margem bruta para cada uma, e reexprima pelo menos dois anos de histórico na mesma base. Uma reclassificação pontual no último exercício parece preparação para uma venda.
Apresente a retenção corretamente. Reporte retenção bruta e líquida de receita e retenção de clientes, definidas de forma coerente, calculadas do mesmo modo todos os meses e com as definições escritas. Ao comprador importa menos o nível do que se o cálculo sobrevive ao recálculo dele.
Feche as lacunas de propriedade intelectual e licenças. Reúna as cessões de todos os prestadores que escreveram código, elabore o inventário de componentes e resolva qualquer exposição copyleft. Doze meses chegam; quatro semanas não.
Reduza a dependência do fundador. Se o fundador é ao mesmo tempo arquiteto principal, comercial principal e ponto de escalonamento das maiores contas, o comprador está a adquirir um emprego e não uma empresa. Processos documentados, um segundo decisor técnico e relações com clientes sustentadas pela equipa mudam materialmente a avaliação do risco.
Arrume as contas segundo o mesmo princípio que vale em todos os setores: os ajustamentos verificáveis são aceites e os sustentados apenas pela palavra do proprietário levam o comprador a descontar todo o resultado. No software isto inclui os custos de desenvolvimento capitalizados, que os compradores reformulam por rotina. A quem pergunta à Conclave Partners por onde começar apontamos o mapa de ARR e a separação da receita, porque tudo o resto depende de esses dois documentos aguentarem.
Processo e prazos
Um negócio de software preparado leva normalmente seis a nove meses do lançamento ao fecho, um pouco menos do que os setores de ativos físicos, porque não há imóveis, existências nem equipamento para inspecionar e porque os compradores financeiros avançam depressa quando o data room está completo.
Conte com uma due diligence mais profunda em três pontos concretos: a reconstrução do ARR, o recálculo da retenção e a revisão técnica e de propriedade intelectual. Conte também com a perda de alavancagem na exclusividade: assim que um comprador a tem, a tensão concorrencial desaparece e cada achado negativo é renegociado a seu favor. Entre nela tarde, com o mapa de ARR, a separação da receita e o processo de propriedade intelectual já resolvidos.
FAQ
Com que múltiplo se vende uma empresa SaaS?
No segundo trimestre de 2026 a aquisição SaaS mediana fechou a 4,0x a receita dos últimos doze meses, com as comparáveis cotadas em 3,2x, segundo a Software Equity Group. As empresas mais pequenas e autofinanciadas transacionam habitualmente abaixo dessas medianas, numa faixa de 3x a 5x. A posição dentro de qualquer intervalo é fixada pela retenção, pelo crescimento, pela qualidade da receita e pela margem bruta.
O meu negócio é avaliado pelo ARR ou pelo lucro?
As empresas de software em crescimento são normalmente avaliadas por um múltiplo de receita; as mais lentas e rentáveis, cada vez mais por EBITDA. Em torno de 10–15% de crescimento muitos compradores olham para ambos e usam o resultado menos favorável, pelo que a disciplina de margem conta tanto como o crescimento nessa fase.
Quanto é que o churn reduz o preço?
De forma direta e substancial, porque muda o múltiplo e não a receita. Face às referências de 2026 — 103% de retenção líquida e 91% de retenção bruta no SaaS B2B privado — ficar bastante abaixo de qualquer uma delas retira o negócio do intervalo que a maioria dos compradores financeiros considera sem reestruturar a operação.
O desenvolvimento à medida prejudica a minha avaliação?
Sim, quando não está distinguido da receita de produto. Os serviços transacionam a múltiplos mais baixos do que o software, pelo que uma apresentação misturada convida o comprador a avaliar todo o negócio mais perto do múltiplo de serviços. Separar as duas linhas, com margens, protege o múltiplo do produto.
Quem é mais provável que compre a minha empresa de software?
Estatisticamente, um comprador financeiro: private equity e adquirentes participados por fundos representaram 59% das operações SaaS no segundo trimestre de 2026. O resto divide-se entre compradores estratégicos e consolidadores de software vertical, e cada um avalia a mesma empresa por critérios diferentes.
Quanto tempo demora vender uma empresa de software?
Cerca de seis a nove meses do lançamento ao fecho para um negócio preparado, com a reconstrução do ARR, a análise de retenção e a due diligence técnica a ocupar a maior parte do calendário. A preparação anterior leva outros seis a doze meses se o arquivo contratual, a separação da receita ou as cessões de direitos precisarem de trabalho.
Ildar Zakirov — Conclave Partners ildar@conclavepartners.com
Sergi Kosiakof — Conclave Partners sergi@conclavepartners.com