The company had just closed a $60 million Series C at roughly a $400 million valuation. Enterprise SaaS, annual recurring revenue (ARR) north of $30 million, good founders, a real product, and a board that knew what it was doing. Nobody was pretending to build the next decacorn. They were trying to become a real company, and that's actually where the hardest finance problems start.
When I first got close to the situation, nothing looked obviously broken. That's usually how these things work. The company was growing, customers were signing, investors were happy, and everyone was too busy to notice how much operational risk was quietly building underneath.
The founders still operated like a Series A company emotionally. They could walk across the office and solve problems informally. Sales forecasting happened partly in Salesforce and partly in conversations. Finance was running critical processes in Excel because, honestly, Excel works pretty well until suddenly it doesn't.
The stack was familiar to anyone who's spent time around growth-stage startups: QuickBooks Enterprise, Salesforce with inconsistent hygiene, manual commission calculations, deferred revenue schedules in spreadsheets, no integrated planning model, HR data disconnected from forecasting, and no real governance around definitions. The company had simply evolved faster than the infrastructure underneath it.
The board question nobody could answer
The real pressure came about 6 months after the round closed, when the board started expecting the company to behave less like a promising startup and more like a mature organization. You could feel the shift in the tenor of meetings.
Earlier-stage investors mostly ask: “How fast are we growing?” Post-Series C investors start asking: “How predictable is the machine?” That's a very different conversation, and most growth-stage finance functions aren't built for it.
During one board prep session, the CEO got asked a simple question: “What happens to runway if enterprise implementations start slipping by 60 days?”
Crickets.
Nobody panicked. It was more like everyone in the room mentally arriving at the same realization simultaneously: the company didn't have a clean way to answer the question. Sales had one view of bookings. Finance had another. Customer success knew onboarding was getting overloaded. Engineering knew integrations were taking longer than forecasted. But none of those systems talked to each other cleanly enough to model the consequences with any confidence.
That's the point where finance infrastructure stops being accounting and starts being operational reality.
The commission problem
A few weeks later, commission costs exploded. The CRO had introduced all the normal late-stage startup complexity: accelerators, overlays, expansion incentives, multi-product bonuses. In the finance department, the logic lived inside a giant Excel workbook that my long-suffering analyst maintained through sheer force of will and prayers to the Virgin Mary.
Then we discovered some enterprise reps had been overpaid because implementation-triggered milestones were being treated like committed recurring ARR events. The numbers weren't enormous, but they were wrong, and once the CRO found out finance had been running commissions off a process he'd never fully signed off on, the conversation got tense fast. His position was that finance should have flagged the ambiguity before it became a payroll error. Finance's position was that the commission plan had been handed over without a clear definition of what “implementation complete” actually meant. Both were right.
Nobody was stealing money. Nobody was cooking the books. The company simply no longer had a clean connection between contracts, billing, revenue recognition, commissions, and operational delivery. Once that connection breaks, trust starts eroding between departments. Sales starts believing finance is slowing the business down. Finance starts believing sales is manufacturing optimism. Operations gets stuck in the middle trying to deliver commitments nobody modeled properly. The accounting error itself is fixable. The organizational friction that follows is much harder to unwind.
Then the auditors got uncomfortable. Not hostile, just cautious. In my experience, that's almost worse. Once auditors stop fully trusting the process, everything changes: every close takes longer, every number needs more backup, and review meetings start feeling a bit adversarial. Meanwhile, the company is still trying to grow 40% a year.
The ERP that made things worse before it made things better
Leadership approved a big systems initiative: NetSuite, planning tools, CRM redesign, outside consultants, workflow mapping. The whole bag of tricks. The implementation initially made things worse, which happens all the time.
Software doesn't magically create operational discipline. A new ERP usually exposes problems people were previously hiding from themselves. The implementation team kept asking questions nobody could answer consistently: What exactly counts as expansion ARR? When is a customer considered live? What defines “implementation complete”? Which churn metric is authoritative? Which pipeline stages actually correlate with close probability?
The consultants were getting frustrated. The internal team was getting defensive. And the project was starting to feel like it was generating more questions than answers. After one particularly unproductive working session, one of the implementation leads pulled me aside and said something I've thought about many times since: “We can build you anything you want. We just need you to tell us what you actually want.”
I eventually realized the company didn't have a software problem. It had a language problem.
The meeting that actually turned the corner
The moment I understood the real problem wasn't systems was during a forecast review after the Series C closed. The board had asked that runway sensitivity question about enterprise implementations slipping 60 days, and when I went back through the data, I found the same underlying disconnect everywhere: everybody had numbers, but nobody had the same reality.
So I pulled sales ops, RevOps, finance, and customer success into a room and said: we are no longer allowed to use the term ARR unless we can define exactly what operational event creates it.
That meeting was ugly.
Sales thought ARR started at contract signature. Finance tied it to billing commencement. Customer success thought it started at implementation completion. The board deck had mixed all 3 definitions depending on the quarter. Nobody had been lying. The company had just let 3 different definitions coexist and harden into departmental orthodoxy over about 18 months of fast growth.
The head of sales ops was the most resistant. From his perspective, using contract signature as the ARR trigger wasn't sloppy, it was how every sales team he'd ever worked on had done it, and he wasn't wrong that it's a common convention. The problem was that this company had long, complex enterprise implementations where “signed” and “live” could be separated by 90 days or more. Using signature as the trigger was inflating the near-term revenue picture in ways that made forecasting almost meaningless.
It took the better part of a day to get alignment on ARR alone. Churn took another half-day. By the end of the first week, people were tired and a little raw. But something had shifted. The arguments were about the business now, not about whose spreadsheet was right.
Before we touched another line of ERP configuration, we spent two painful weeks standardizing definitions: ARR, churn, active customer, implementation complete, expansion revenue, pipeline stage. Every term that crossed a departmental boundary got a written definition with a named operational trigger. It was unglamorous work, and there were more than a few tense conversations about whose definition “won.” Only after that did the systems work start actually succeeding.
What changed
Once the company operated from shared definitions, the emotional temperature dropped fast. Forecasts got better. Board meetings got calmer. Hiring plans became more disciplined. Customer success capacity started getting modeled alongside sales growth instead of as an afterthought 6 months later.
But the biggest change was cultural. People stopped arguing about whose numbers were right and started talking about the business again. That's usually the dividing line between a company that matures successfully out of a big raise and one that eventually gets trapped inside its own narrative.
The ERP helped, eventually. NetSuite is a genuinely better system than QuickBooks Enterprise for a company at that stage. But the systems work only succeeded because the definitional work came first. Flip that sequence and you're just encoding your confusion into more expensive software.
What this means if you're building a finance function right now
Most growth-stage companies that come to me thinking they need a new system actually need something harder: a shared operational language the whole company trusts. The system question is usually legitimate, but it's rarely first.
The finance leader who succeeds in a post-raise environment isn't the one who installs NetSuite fastest. It's the one who figures out early that their real job is creating a single version of reality that sales, finance, customer success, and the board can all work from. That's less about software selection and more about being willing to convene the uncomfortable meetings where people disagree about what words mean.
A few diagnostic questions worth asking before you sign the next software contract:
- Can your sales ops lead and your VP Finance give you the same ARR number independently, using the same definition?
- Do you know which pipeline stage has meaningful predictive value for close probability?
- Is “customer live” a real operational event with a defined trigger, or is it roughly when customer success stops feeling nervous?
If the answers are fuzzy, it's not the system that's the immediate problem you need to fix.
I've worked through this sequence enough times to know that the definitional work is always the part everyone wants to skip. It feels slow. It feels like a distraction from the “real” implementation work. But every company I've seen try to skip it has paid for that decision later, usually during a board meeting, usually when someone asks a question that should have a simple answer and doesn't.
The $60 million raise didn't create this company's problems. It just made them impossible to ignore.