John Glasgow, CEO, CFO e fundador da Campfire – Série de entrevistas

John Glasgow é CEO, CFO e fundador da Campfire, e tem experiência em finanças, fusões e aquisições no setor de tecnologia e estratégia corporativa. Antes de fundar a empresa, trabalhou na Adobe, na Invoice2go e na Bill.com, inclusive ajudando a conduzir a Invoice2go durante sua aquisição por US$ 625 milhões. Seu trabalho em departamentos financeiros moldou seu foco em substituir processos dependentes de planilhas por sistemas contábeis que preservem os detalhes das transações e permitam a automação.

Campfire desenvolve uma plataforma de planejamento de recursos empresariais nativa de IA para equipes financeiras e contábeis, que reúne razão geral, automação de receitas, relatórios e gestão do fechamento contábil. Seus agentes Ember trabalham com os dados contábeis subjacentes para auxiliar em tarefas como conciliação e categorização de transações, enquanto o Forecast separa valores efetivamente lançados, valores comprometidos e estimativas geradas por IA. Nesta entrevista, Glasgow fala sobre a arquitetura por trás da contabilidade nativa de IA, os limites entre a autonomia dos agentes e a aprovação humana e como as equipes financeiras podem manter a rastreabilidade à medida que a automação se expande.

Sua carreira abrange finanças, fusões e aquisições no setor de tecnologia e estratégia na Adobe, na Invoice2go e na Bill.com, antes de fundar a Campfire. O que você observou repetidamente nos departamentos financeiros que o convenceu de que era necessário reconstruir o ERP subjacente, em vez de simplesmente aprimorá-lo com mais uma camada de software?

A venda da Invoice2go para a Bill.com por US$ 625 milhões me mostrou o problema de perto. Durante a auditoria prévia à aquisição, atendi a mais de 500 solicitações recorrendo a planilhas, porque a contabilidade de receitas, os relatórios de SaaS e as consolidações ficavam nelas, e não em um sistema. Uma empresa daquele porte ainda realizava tarefas financeiras essenciais em planilhas.

Na Bill, onde liderei parcerias estratégicas e trabalhei em estreita colaboração com o CFO, vi o mesmo problema entre os clientes. A gestão da folha de pagamento, dos gastos e das contas a pagar e a receber havia sido modernizada, mas as equipes financeiras ainda precisavam recorrer a um ERP criado para outra época.

O problema está no próprio razão geral. Os ERPs legados recebem lançamentos resumidos dos sistemas de faturamento, pagamentos, folha de pagamento e outros, de modo que os detalhes das transações já se perderam quando os dados chegam ao razão. Acrescentar outra camada de software não resolve a falta de dados. Eu queria um razão geral que preservasse os detalhes e fosse capaz de executar o trabalho, o que exigia reconstruir o ERP desde o início.

“Nativo de IA” está se tornando uma descrição comum no setor de software empresarial. Do ponto de vista da arquitetura, o que torna um ERP nativo de IA fundamentalmente diferente de um ERP tradicional ao qual se acrescenta um grande modelo de linguagem ou um copiloto de IA?

A diferença fundamental é que um ERP nativo de IA é desenvolvido em torno dos dados de que os fluxos de trabalho de IA precisam para agir.

Um copiloto só pode ler o que um ERP legado armazena. Se o ERP contém resumos mensais em vez de detalhes no nível das transações, a IA pode localizar um número ou redigir uma explicação, mas não consegue, de forma confiável, associar transações, conciliar contas ou explicar como um lançamento foi criado. A Campfire mantém todos os detalhes das transações e controla tanto o razão geral quanto os subrazões, fornecendo aos agentes Ember os dados de que precisam para realmente executar o trabalho.

Outra diferença é a rastreabilidade. Cada ação dos agentes está vinculada aos dados subjacentes do razão e pode ser revisada antes de ser lançada.

A terceira diferença está no próprio modelo: o Accounting Intelligence da Campfire é treinado com dados contábeis e escreve código para executar tarefas financeiras, tornando os resultados reproduzíveis. É isso que permite aos agentes agir, em vez de apenas fazer recomendações.

A Campfire lançou recentemente o Forecast, que divide os valores do mês corrente em realizados, comprometidos e estimados por IA, em vez de pedir à IA que preveja o período inteiro. Por que você o projetou dessa forma e em que aspectos a IA é realmente útil nas projeções financeiras, em comparação com aqueles em que os dados contábeis determinísticos devem continuar prevalecendo?

Como CFO, quero saber onde o mês vai terminar cinco ou mais dias antes de seu encerramento e, a essa altura, boa parte dos resultados já é conhecida. Pedir à IA que preveja o período inteiro significaria substituir números conhecidos por suposições. Por isso, o Forecast divide o mês em três camadas:

Realizados: o que já foi lançado no razão geral.

Comprometidos: valores futuros conhecidos de contratos, faturas, ativos e arrendamentos que ainda não foram lançados.

Estimados: a projeção da Ember para a parte realmente desconhecida, baseada no histórico e na sazonalidade da empresa.

É nessa parte que, na minha opinião, a IA deve ser usada nas projeções: naquilo que ainda não é possível saber. Os dados contábeis determinísticos devem prevalecer sobre tudo o que já é conhecido. Misturar os dois dificulta distinguir fatos de estimativas. Se os dados forem combinados, não será possível saber quais números podemos defender ao apresentar a projeção ao conselho.

Quando alguém pergunta como cheguei a determinado número, posso abrir qualquer valor e mostrar seus componentes realizados, comprometidos e estimados, além das premissas da Ember. O Forecast tem caráter consultivo: nada do que produz é lançado automaticamente no razão, mas ele permite que a equipe financeira saiba com antecedência para onde o mês está caminhando e tome decisões de negócios antes do fechamento.

O Forecast permite que o Ember estime a parte desconhecida do mês com base em tendências históricas e na sazonalidade, além de explicar as premissas por trás dessas estimativas. Como vocês lidam com situações em que os padrões históricos deixam repentinamente de ser úteis, como em casos de crescimento acelerado, perda de um cliente importante, aquisição ou outro evento atípico?

É justamente nesses meses que um CFO mais precisa de uma previsão, e por isso ela é dividida em camadas. Apenas a parte estimada do Forecast depende de tendências históricas e da sazonalidade. A camada de valores comprometidos vem de contratos, faturas, ativos e arrendamentos que já constam no livro-razão do Campfire. Assim, uma aquisição, a perda de um cliente ou um crescimento acelerado não altera o que já é conhecido.

Quando o padrão muda, a equipe financeira geralmente sabe o motivo antes que isso apareça nos dados, então pode fornecer esse contexto. Ela pode adicionar uma observação sobre o que mudou, anexar algo como um plano de contratação ou conectar uma fonte, como um CRM ou HRIS, por meio da nossa integração com MCP. O Ember usa esse contexto para estimar novamente a parte desconhecida.

Cada estimativa também inclui uma explicação, em uma frase, das premissas adotadas. Assim, ao apresentar a previsão, posso mostrar o que é fato, o que está comprometido e o que está sendo projetado.

Em vez de depender inteiramente de modelos de uso geral, o Campfire desenvolveu seu próprio Large Accounting Model, ou LAM (modelo contábil de grande escala). O que vocês aprenderam sobre as limitações da IA de uso geral na contabilidade, e o que um modelo especializado precisa entender que normalmente escapa a um LLM convencional?

A contabilidade exige respostas reproduzíveis, não apenas plausíveis. Os modelos de uso geral são bons em gerar linguagem, mas podem ter dificuldade com o raciocínio numérico e com as classificações contábeis, áreas em que as mesmas entradas precisam sempre produzir a mesma resposta.

Em vez de pedir a um modelo que raciocine diretamente sobre dados financeiros, fazemos com que ele escreva SQL ou Python para executar o trabalho. O código é reproduzível, o que é importante para auditorias e permite que as empresas automatizem ações sem precisar que uma pessoa aprove cada resultado idêntico.

Nossa Accounting Intelligence é treinada com dados contábeis e entende aspectos como a estrutura do plano de contas, os padrões dos fornecedores e como deve ser uma contabilidade organizada. Também aprende com o histórico de transações de cada cliente. A precisão depende tanto do sistema em torno do modelo quanto do próprio modelo.

As equipes financeiras têm uma tolerância excepcionalmente baixa a erros de IA. À medida que os agentes começam a fazer reconciliações, categorizar transações, preparar lançamentos e interagir com o livro-razão, qual deve ser o limite entre a execução autônoma e a aprovação humana?

Esse limite deve depender de ser possível ou não verificar uma ação. Se um lançamento for reproduzível e puder ser rastreado até os dados subjacentes do livro-razão, não deveria ser necessário que uma pessoa aprovasse cada ocorrência. Se não for possível explicá-lo ou reproduzi-lo, uma pessoa deve analisá-lo antes de ele ser lançado.

Foi assim que desenvolvemos o Ember. Toda ação dos agentes é registrada, vinculada aos dados subjacentes do GL e pode ser revisada. As equipes definem limites de confiança que determinam quais tarefas o Ember executa de forma autônoma e quais são encaminhadas a uma pessoa. Também podem ampliar essa autonomia à medida que os resultados conquistam sua confiança.

As pessoas continuam responsáveis pelas decisões. Os contadores decidem quanto o Ember deve fazer, analisam as exceções e explicam por que os números mudaram. Os agentes assumem o trabalho repetitivo de correspondência, classificação e reconciliação. A TwelveLabs é um bom exemplo: com três contadores responsáveis pelas operações nos EUA e na Coreia, reduziu pela metade o tempo de fechamento e economizou mais de US$ 300.000.

O Campfire também lançou uma loja MCP que permite ao Ember interagir com sistemas externos, como plataformas de pagamentos, CRM, compras e RH. Você acredita que, em última análise, o ERP deixará de ser um sistema de registro passivo para se tornar uma camada de orquestração, na qual agentes de IA possam atuar em todo o ecossistema financeiro?

Sim, desde que o livro-razão continue sendo o sistema oficial de registro. Historicamente, o ERP registrava o trabalho realizado em outros lugares, então a maioria das respostas fica fora do livro-razão: uma renovação no CRM, uma nova contratação no HRIS, um pedido de compra no sistema de compras. Se os agentes vão executar o trabalho, também precisam desse contexto; por isso, o ERP deve se conectar diretamente a esses sistemas.

Há anos as equipes financeiras fazem previsões dessa maneira, buscando as oportunidades em andamento no CRM e o número de funcionários no HRIS. Com o Forecast, o Ember faz isso assim que uma equipe conecta esses sistemas, enquanto o livro-razão continua sendo a fonte confiável de tudo o que já é conhecido. O livro-razão permanece como fonte confiável, enquanto os agentes podem atuar nos sistemas ao seu redor.

Você tem uma perspectiva particularmente interessante sobre a economia da IA, pois é CEO e CFO de uma empresa de IA que atende outras equipes financeiras. O que você tem observado sobre a forma como as empresas estão planejando seus orçamentos para IA hoje? E espera que os preços da IA empresarial deixem de ser baseados em assinaturas por usuário e passem a levar em conta o uso, os resultados ou algum outro modelo?

Estamos vendo os orçamentos migrarem dos gastos fixos por usuário para o consumo variável de IA, e muitas equipes financeiras ainda não estão preparadas para isso. À medida que os agentes assumem tarefas antes realizadas por pessoas, as empresas podem precisar de menos licenças para usuários humanos, enquanto o uso de IA aumenta. Os fornecedores também estão acrescentando créditos e cobranças por excedentes às tarifas por usuário, então as equipes financeiras precisam estimar o custo potencial de uso antes de assinar.

Espero que os modelos híbridos se tornem mais comuns do que a precificação puramente baseada em resultados. O CFO que há em mim quer uma base previsível, e o CEO que há em mim precisa de uma precificação que reflita o uso real.

A Campfire captou US$ 35 milhões em uma rodada Série A e, poucas semanas depois, outros US$ 65 milhões em uma rodada Série B. O que mudou no mercado ou na demanda dos clientes nesse período que levou vocês a captar recursos de forma tão agressiva, e onde você vê a maior oportunidade para usar esse capital e acelerar o desenvolvimento do produto?

Já havia uma forte demanda antes da rodada Série A, mas a resposta se acelerou imediatamente após o fechamento. Empresas nos procuraram para solicitar demonstrações, muitas delas sem conhecer a Campfire, e ficou claro que a demanda superava o que havíamos previsto.

Isso nos deu a oportunidade de investir de forma mais agressiva para atender a essa demanda, especialmente à medida que as empresas se mostraram dispostas a abandonar plataformas antigas como NetSuite e Sage Intacct. Clientes como a Replit mostram por quê: a receita recorrente anual da empresa cresceu de US$ 10 milhões para mais de US$ 200 milhões sem que ela ampliasse sua equipe de contabilidade, composta por quatro pessoas, e o fechamento da receita passou de oito horas para 30 minutos.

Captamos US$ 35 milhões em nossa rodada Série A, liderada pela Accel, e, em seguida, US$ 65 milhões em uma rodada Série B co-liderada pela Accel e pela Ribbit, totalizando US$ 100 milhões em 12 semanas. Usamos esse capital para acompanhar a demanda e crescemos de 10 pessoas para mais de 150, distribuídas entre São Francisco, Nova York e Londres.

A contabilidade nativa de IA tornou-se rapidamente uma categoria competitiva, com empresas como Campfire e Rillet desafiando plataformas estabelecidas como QuickBooks, NetSuite e Sage Intacct. Se olharmos cinco anos à frente, que partes da contabilidade e do ERP você espera que os agentes de IA assumam quase por completo, e quais responsabilidades continuarão firmemente nas mãos de profissionais humanos de finanças?

Espero que os agentes assumam a maior parte do trabalho rotineiro: associar transações a pagamentos, classificá-las, fazer conciliações e apropriações e cuidar das tarefas mecânicas do fechamento e da elaboração de relatórios. É um trabalho repetitivo, baseado em regras, que o software pode aprender a executar.

O que continuará a cargo das pessoas são o discernimento e a responsabilidade. Os contadores decidirão quanto os agentes podem fazer de forma autônoma, analisarão as exceções, explicarão por que os números mudaram e aconselharão a empresa sobre os próximos passos. Alguém ainda precisa responder pelos livros contábeis.

Com o tempo, o caráter “nativo de IA” se tornará uma expectativa básica para os softwares financeiros. O diferencial será saber se as equipes financeiras confiam ao sistema seu livro-razão e conseguem ver exatamente como ele chegou às suas conclusões. Esse é o padrão que desenvolvemos a Campfire para atender, e mais de 400 empresas, incluindo Cursor, Clay, Polymarket e PostHog, já fazem sua contabilidade na plataforma.

Obrigado pela ótima entrevista. Leitores que desejam saber mais sobre contabilidade nativa de IA e planejamento de recursos empresariais devem visitar Campfire.