The CFO's Stack in 2025: A Realistic Audit

A CFO at a $30M company is typically managing a general ledger, a CRM, a billing platform, a contract management tool, an FP&A tool, and at least two spreadsheet models that no one else fully understands. The stack has accumulated over years of legitimate decisions, each solving a real problem. What it adds up to is a finance operation that costs more to run than it should and produces data that’s less reliable than it looks.

The finance technology stack at most mid-market companies is not designed. It’s accumulated. Each piece was added to solve a problem that the existing stack couldn’t address. The problem was solved, and the piece stayed. Over time, the stack reflects the history of the company’s pain points more than any coherent architectural vision.

Auditing that stack — honestly, with full accounting of cost and risk — is one of the more valuable things a CFO can do in a year. Most find that the stack is more expensive and more fragile than they realized.

What a typical $30M stack looks like

The anchor is the GL and ERP, usually QuickBooks, Xero, or a lower-tier NetSuite implementation. The CRM is typically Salesforce or HubSpot, bought when the sales team needed pipeline management. Billing is handled by whatever generates invoices — sometimes the ERP, sometimes Chargebee or Stripe if there are subscriptions. Contracts live in DocuSign or a shared drive. Expenses are processed in Expensify or Concur. FP&A happens in Excel, or in Adaptive Insights if someone invested in it at some point.

That’s six systems. Six vendors. Six contracts to manage. Six sources of data that need to agree on the financial picture of the business. In between each pair of systems is either an integration that needs to be maintained or a human being who carries information across manually.

The hidden cost inventory

The direct costs — licenses and subscriptions — are visible. The indirect costs are harder to see but often larger. They include:

The time finance team members spend on reconciliation between systems that don’t automatically agree. The time IT or ops spends maintaining integrations when something breaks. The opportunity cost of FP&A work that gets squeezed by the time consumed by data gathering. The audit preparation time when the transaction trail is spread across four systems and needs to be reconstructed. The risk cost — harder to quantify — of making decisions on data that’s current as of the last sync job, not current as of right now.¹

When these indirect costs are estimated and added to direct costs, most mid-market finance stacks cost significantly more to operate than the license fees suggest. A stack that costs $8,000 a month in software licenses often requires $20,000–$30,000 a month in labor to operate correctly.

What the audit reveals

A structured finance stack audit asks, for each tool: What does this do that couldn’t be done without it? What does it cost in license and in operational overhead? What data does it produce that other systems need, and how reliably does that data transfer? What would break if we turned it off tomorrow?

The answers are usually clarifying. Some tools earn their place unambiguously — the capability and the cost make sense. Others exist because they were purchased at some point and the contract auto-renewed and nobody ever asked whether they were still necessary. A few turn out to be load-bearing in ways that weren’t obvious — the thing nobody thinks is critical until it goes offline.

The consolidation opportunity

The output of the audit is typically a map: tools that should stay, tools that should be replaced with something that integrates better, and tools that should be eliminated. The consolidation opportunity is real at most companies — not because the individual tools are bad, but because the operational overhead of running many separate tools exceeds the incremental value each one provides over a more integrated alternative.

The conversation the audit starts is: what would the stack look like if we were designing it today, knowing what we know about our processes and our reporting needs? That conversation is worth having before it’s forced by a system failure or a scaling crisis.

Sources