There is a version of this story that ends badly. An audit finding that becomes a restatement. A restatement that spooks investors. Investors who start asking questions that the finance team cannot answer cleanly. A funding round that stalls at exactly the wrong moment.
This company got lucky. Not because the problem wasn’t serious – it was. But because someone on the finance team had the instinct to flag something uncomfortable before the auditors found it first. That instinct, and the work that followed, is what this story is actually about.
The company was a B2B SaaS business, five years old, growing steadily. They had moved beyond the early stage of manual processes driven by necessity into a more dangerous middle stage, where they still used those manual processes even though the volume had grown far beyond their original capacity.
Annual contracts were the norm. Some multi-year. Implementation fees on top of the subscription. A few professional services engagements running alongside. Enterprise software standards did not complicate the product mix, but enough complexity existed that someone had to carefully recognize revenue correctly each month by distinguishing what the company had earned from what it had merely invoiced.
That thinking was happening in a spreadsheet
Not a simple spreadsheet. By the time the problem surfaced, it was a sophisticated, carefully structured spreadsheet. Multiple tabs. Colour-coded columns. Lookup formulas pulling contract start dates from a separate tracker. It had been built by someone who genuinely understood what they were trying to do, and it had served its purpose for a while.
The problem with a spreadsheet doing this job is not usually that the logic is wrong. It’s that the spreadsheet doesn’t know anything the person maintaining it doesn’t tell it. Contracts get amended and the amendment doesn’t make it in. A customer churns early and the deferred balance sits there, uncleared, for two months before anyone notices. An implementation gets delayed and the revenue recognition schedule doesn’t shift to match. The spreadsheet stays static while the business keeps moving.
Every discrepancy between what the spreadsheet said and what had actually happened was a revenue timing error waiting to be found.
The finance lead – the person who eventually flagged the problem – had been with the company for about eighteen months when she started running parallel checks. She hadn’t been asked to. It was just something she did when something felt slightly off. The recognised revenue number for a given month, when she pushed on it, occasionally didn’t quite reconcile to what she’d have expected given the contracts she knew were in place.
She started digging.
What she found wasn’t fraud. It wasn’t negligence. A manually maintained process, driven by effort and attention instead of structure and automation, caused the issue and led to the company recognizing revenue in the wrong period. Not massively – not in a way that would have shown up in a top-level review – but consistently. Enough that over a trailing twelve-month period, the cumulative effect was material.
Specifically, there were two recurring patterns.
First, the team spread implementation fees across multi-year contracts as a simple subscription instead of recognizing them when implementation was actually completed. The fee structure and the recognition schedule had come apart, quietly, because nobody had set up a formal rule connecting the two – and the person maintaining the spreadsheet had been applying a reasonable but technically incorrect assumption.
The second involved churned contracts where teams did not promptly clear the remaining deferred revenue. When a customer cancelled, they should have released the deferred balance immediately. In practice, they processed the cancellation in the CRM and stopped invoicing the customer, but the spreadsheet retained the deferred revenue balance until the next monthly reconciliation cycle instead of clearing it at the point of cancellation. Depending on when in the month a customer churned, that was anywhere from one to four weeks of incorrectly held deferred revenue.
Neither pattern was alarming in isolation. Both of them happening simultaneously, consistently, across a growing customer base, added up to something the auditors were not going to find acceptable.
They decided to move the revenue recognition process entirely into NetSuite implementation before the year-end audit rather than after it.
This was not the path of least resistance. Building a proper revenue recognition configuration inside a system, with all the rules, schedules, and event triggers that entails, takes longer than leaving the spreadsheet in place for one more quarter. It requires decisions about how every contract type is handled, not just the common ones. It requires aligning finance, sales operations, and customer success on what events trigger what recognition actions – and those conversations are sometimes harder than the technical work.
The alternative was to go into the audit with the problem partially patched. EcobSoft’s recommendation was clear: partial fixes on a broken process don’t survive audit scrutiny. The right move was to fix the process completely.
The scope of the engagement covered four things
Contract data was migrated into NetSuite with proper structure – every active contract mapped to a customer record, with start dates, end dates, billing terms, and revenue schedules attached. Contracts that had been living in a CRM and partially reflected in a spreadsheet were, for the first time, represented fully and accurately in the system doing the netsuite implementation and accounting.
Revenue recognition rules were configured for every contract type in the product mix. Subscription revenue recognised ratably over the subscription period. Implementation fees recognised on a milestone basis, triggered by a defined completion event. Professional services recognised on a time-and-materials basis as actuals were logged. Each rule connected to the contract type automatically, without requiring a manual judgment call at the point of recognition.
We rebuilt the churn and amendment workflow. NetSuite terminates contracts and immediately clears the remaining deferred balance instead of waiting for the next reconciliation cycle. It amends contracts for upgrades, downgrades, or term changes and automatically updates the recognition schedule to reflect the new terms.
The team configured reporting to give the finance team visibility that spreadsheets had never provided: it now shows a real-time deferred revenue waterfall indicating what the company expects to recognize in each future period, a contract-level breakdown of recognized versus deferred revenue at any point in time, and enables the finance team to produce a reconciliation report in minutes instead of hours.
That last point matters more than it might seem. When you can reconcile revenue recognition in minutes, you do it more often, catch problems early, and fix them cleanly. The spreadsheet process had led to monthly reconciliations because monthly was all the bandwidth allowed. Monthly reconciliations meant problems had up to four weeks to compound before anyone found them.
The year-end audit was the first clean one the company had experienced in at least three years.
Zero revenue timing adjustments. Not reduced – eliminated. The auditors reviewed the recognition logic, traced a sample of contracts through from booking to recognition, and found nothing to flag. The deferred revenue balance reconciled exactly to the contract data. The waterfall tied to the prior period actuals.
The audit conversation, which had historically involved a series of uncomfortable questions and an extended back-and-forth over adjustments, finished faster than anyone could remember.
What changed inside the finance function was perhaps more significant than the audit outcome.
The person who had been maintaining the spreadsheet – and had been carrying the cognitive load of an increasingly complex manual process on top of everything else her role required – now had that time back. Revenue recognition, which had been consuming several days of close effort each month, became a process that largely ran itself. Her attention could go to analysis that actually required her judgment, rather than reconciliations that required her patience.
The finance lead who had initially flagged the problem described the change in terms that stuck: the team had stopped being reactive and started being accurate. The spreadsheet process had always been slightly behind reality – catching up to contract changes, chasing down cancellation notifications, correcting figures from the previous month. The new process was current. What the system showed on any given day was what was actually true on that day.
That sounds like a modest improvement. For a company at the stage of having investor conversations, preparing for a potential Series B, and being scrutinised on revenue quality and recognition consistency, it was not modest at all.
The SaaS revenue recognition problem is surprisingly common and surprisingly underestimated
Part of the reason is that the errors tend to be self-concealing. Revenue that is recognised in the wrong period doesn’t disappear – it shows up somewhere, just not in the right place. From the top line, the numbers often look reasonable. It’s only when you get to the contract level, and start asking whether the revenue in a given month actually corresponds to the obligations fulfilled in that month, that the picture becomes harder to defend.
The spreadsheet approach works only until it fails. A breaking point always arrives—usually driven by rising contract volume, increasing contract complexity, and the first auditor question no one can answer cleanly—when manual processes become unmanageable. The only uncertainty is whether that point comes before or after the damage is done.
The SaaS company in this story caught it before. By a narrower margin than anyone was comfortable admitting, but before. The institutional memory of the finance lead, combined with the decision to fix the problem properly rather than patch it, meant that the year-end audit became a proof point rather than a crisis.
Revenue recognition, done correctly, is not a complicated concept. You recognise revenue when you’ve earned it, not when you’ve invoiced it. What makes it complicated in practice is the operational machinery required to apply that principle correctly, at scale, across a growing portfolio of contracts with varying terms and structures.
That machinery doesn’t belong in a spreadsheet. It belongs in the system doing the accounting – connected to the contracts, automated at the point of recognition, and visible enough that no finance lead has to run parallel checks in their spare time to find out whether the numbers are right.
They should just be right. That’s the point. EcobSoft helps SaaS and subscription businesses implement NetSuite in a way that makes revenue recognition accurate, auditable, and automatic. If your finance team is spending close week reconciling what the spreadsheet says against what actually happened, it might be time to have a different kind of conversation.
