John Glasgow, CEO, CFO, and Founder of Campfire – Interview Series

John Glasgow is CEO, CFO, and founder of Campfire, bringing experience across finance, technology mergers and acquisitions, and corporate strategy. Before founding the company, he worked at Adobe, Invoice2go, and Bill.com, including helping guide Invoice2go through its $625 million acquisition. His work inside finance organizations shaped his focus on replacing spreadsheet-dependent processes with accounting systems that retain transaction-level detail and support automation.

Campfire develops an AI-native enterprise resource planning platform for finance and accounting teams, bringing together the general ledger, revenue automation, reporting, and close management. Its Ember agents work with underlying accounting data to support tasks such as reconciliation and transaction categorization, while Forecast separates posted actuals, committed amounts, and AI-generated estimates. In this interview, Glasgow discusses the architecture behind AI-native accounting, the boundaries between agent autonomy and human approval, and how finance teams can maintain traceability as automation expands.

Your career has spanned finance, technology M&A, strategy at Adobe, Invoice2go, and Bill.com before you founded Campfire. What did you repeatedly see inside finance organizations that convinced you the underlying ERP needed to be rebuilt rather than simply improved with another layer of software?

Selling Invoice2go to Bill.com for $625 million showed me the problem up close. During diligence, I handled more than 500 requests out of spreadsheets because our revenue accounting, SaaS reporting, and consolidations lived there instead of in a system. A company of that size was still running critical finance work out of spreadsheets.

At Bill, where I led strategic partnerships and worked closely with the CFO, I saw the same problem across customers. Payroll, spend management, and AP/AR had been modernized, but finance teams still had to go back into an ERP that was built for an earlier era.

The problem is the ledger itself. Legacy ERPs receive summarized entries from billing, payments, payroll, and other systems, so the transaction detail is gone by the time it reaches the ledger. Adding another layer of software can't fix missing data. I wanted a ledger that kept the detail and could do the work, which meant rebuilding the ERP from the ground up.

“AI-native” is becoming a common description across enterprise software. Architecturally, what makes an AI-native ERP fundamentally different from a traditional ERP that adds a large language model or AI copilot on top of an existing system?

The fundamental difference is that an AI-native ERP is built around the data that AI workflows need to act upon.

A copilot can only read what a legacy ERP stores. If the ERP has monthly summaries instead of transaction-level detail, AI can find a number or draft an explanation, but it can't reliably match transactions, reconcile accounts, or explain how an entry was created. Campfire keeps the full transaction detail and owns both the general ledger and subledgers, giving its Ember agents the data they need to actually do the work.

Another difference is traceability. Every agent action links back to the underlying ledger data and can be reviewed before it posts.

The third is the model itself: Campfire's Accounting Intelligence is trained on accounting data and writes code to perform financial tasks, making the results reproducible. That's what allows agents to act rather than simply suggest.

Campfire recently launched Forecast, which separates the current month into actual, committed, and AI-estimated figures rather than asking AI to predict the entire period. Why did you design it this way, and where do you think AI is genuinely useful in financial forecasting versus where deterministic accounting data should remain in control?

As a CFO, I’m asking where the month will land five or more days before it ends, and by then much of it is already known. Asking AI to predict the entire period would replace known numbers with guesses. So Forecast separates the month into three layers:

Actual: what has already posted to the general ledger.

Committed: known future dollars from contracts, bills, assets, and leases that have not posted yet.

Estimated: Ember's projection for the genuinely unknown portion, based on the company's history and seasonality.

That's where I think AI belongs in forecasting: the part nobody can know yet. Deterministic accounting data should control everything that is already known. Blending the two makes it harder to tell facts from estimates. If the two are blended, you can’t tell which numbers you can stand behind when you take the forecast to the board.

When someone asks how I got the number, I can open any figure and show the actual, committed, and estimated components, along with Ember's assumptions. Forecast is advisory; nothing it produces posts to the ledger automatically, but it gives finance a heads-up on where the month is heading in time to make business decisions before the month closes.

Forecast allows Ember to estimate the unknown portion of the month using historical trends and seasonality, while also explaining the assumptions behind those estimates. How do you handle situations where historical patterns suddenly stop being useful, such as rapid growth, a major customer loss, an acquisition, or another unusual event?

Those are the months a CFO most needs a forecast, and that’s why they’re split into layers. Only the estimated portion of Forecast depends on historical trends and seasonality. The committed layer comes from contracts, bills, assets, and leases already in Campfire’s ledger, so an acquisition, customer loss, or rapid growth doesn't change what is already known.

When the pattern does change, the finance team usually knows why before the data shows it, so they can provide the context. They can add a note about what changed, attach something like a headcount plan, or connect a source such as a CRM or HRIS through our MCP integration. Ember uses that context to re-estimate the unknown portion.

Every estimate also includes a one-sentence explanation of its assumptions, so when I present the forecast, I can show what is fact, what is committed, and what is being projected.

Campfire has developed its own Large Accounting Model, or LAM, rather than relying entirely on general-purpose models. What have you learned about the limitations of general-purpose AI for accounting, and what does a specialized model need to understand that a conventional LLM typically does not?

Accounting needs reproducible answers, not plausible ones. General-purpose models are good at generating language, but they can struggle with numerical reasoning and accounting classifications where the same inputs need to produce the same answer every time.

Rather than asking a model to reason directly over financial data, we have it write SQL or Python that performs the work. Code is reproducible, which matters for audit and allows companies to automate actions without requiring a person to approve every identical result.

Our Accounting Intelligence is trained on accounting data and understands things like chart-of-accounts structure, vendor patterns, and what a clean set of books looks like. It also learns from each customer's transaction history. Accuracy comes from the system around the model as much as from the model itself.

Finance teams have an unusually low tolerance for AI errors. As agents begin performing reconciliations, categorizing transactions, preparing entries, and interacting with the ledger, what should the boundary be between autonomous execution and human approval?

The boundary should depend on whether an action can be checked. If an entry is reproducible and traces to the underlying ledger data, a person shouldn't have to approve every instance. If it can't be explained or reproduced, a person should review it before it posts.

That's how we built Ember. Every agent action is logged, sourced to the underlying GL data, and reviewable. Teams set confidence thresholds that determine what Ember handles autonomously and what goes to a person, and they can expand that autonomy as the results earn trust.

People still own the judgment. Accountants decide how much Ember should handle, review exceptions, and explain why the numbers moved. The agents take on the repetitive matching, labeling, and reconciliation work. TwelveLabs is a good example: with three accountants covering the US and Korea, it cut its close time in half and saved over $300,000.

Campfire has also introduced an MCP store that allows Ember to interact with external systems such as payment, CRM, procurement, and HR platforms. Do you ultimately see ERP becoming less of a passive system of record and more of an orchestration layer where AI agents can work across the entire financial stack?

Yes, as long as the ledger remains the system of record. Historically, the ERP recorded work done elsewhere, so most of the answers sit outside the ledger: a renewal in the CRM, a new hire in the HRIS, a purchase order in procurement. If agents are going to do the work, they need that context too, so the ERP has to connect directly to those systems.

Finance teams have forecast this way for years, pulling pipeline from the CRM and headcount from the HRIS. With Forecast, Ember does that once a team connects those systems, and the ledger stays the source of truth for everything already known. The ledger remains the source of truth, while agents can work across the systems around it.

You have a particularly interesting view of AI economics because you are both CEO and CFO of an AI company serving other finance teams. What are you seeing in terms of how companies are budgeting for AI today, and do you expect enterprise AI pricing to move away from per-seat subscriptions toward usage, outcomes, or some other model?

We're seeing budgets shift from fixed seat-based spending toward variable AI consumption, and many finance teams aren't set up for that yet. As agents take on work that people used to do, companies may need fewer human seats while their AI usage increases. Vendors are also layering credits and overages onto seat fees, so finance teams need to model the potential usage cost before they sign.

I expect hybrid models to become more common than pure outcome-based pricing. The CFO in me wants a predictable base, and the CEO in me needs pricing that reflects actual usage.

Campfire raised a $35 million Series A followed by a $65 million Series B just weeks later. What changed in the market or in customer demand during that period that made you decide to capitalize the company so aggressively, and where do you see the biggest opportunity for that capital to accelerate the product?

We had strong demand before the Series A, but the response immediately accelerated after it closed. Companies reached out for demos, many of them new to Campfire, and it became clear that demand was ahead of what we had planned for.

That gave us an opportunity to invest more aggressively in meeting that demand, particularly as companies became willing to move off legacy platforms like NetSuite and Sage Intacct. Customers like Replit show why: it grew from $10 million to over $200 million in annual recurring revenue without adding to its four-person accounting team, and its revenue close dropped from eight hours to 30 minutes.

We raised $35 million in our Series A, led by Accel, followed by a $65 million Series B co-led by Accel and Ribbit, bringing the total to $100 million in 12 weeks. We’ve used it to keep up with that demand, growing from 10 people to more than 150 across San Francisco, New York, and London.

AI-native accounting has quickly become a competitive category, with companies such as Campfire and Rillet challenging established platforms like QuickBooks, NetSuite, and Sage Intacct. If we look five years ahead, which parts of accounting and ERP do you expect AI agents to handle almost entirely, and which responsibilities will remain firmly with human finance professionals?

I expect agents to handle most of the routine work: matching transactions to payments, labeling transactions, reconciliations, accruals, and the mechanical parts of close and reporting. It's repetitive, rules-based work that software can learn.

What stays with people is judgment and accountability. Accountants will decide how much agents can handle autonomously, review exceptions, explain why the numbers moved, and advise the business on what to do next. Someone still has to answer for the books.

Over time, "AI-native" will become a baseline expectation for financial software. The differentiator will be whether finance teams trust the system with their ledger and can see exactly how it reached its conclusions. That's the bar we built Campfire to clear, and more than 400 companies, including Cursor, Clay, Polymarket, and PostHog, already run their books on it.

Thank you for the great interview, readers who wish to learn more about AI-native accounting and enterprise resource planning should visit Campfire.