A personal blog post by Casper Zhao
I almost walked away from a deal back in the day.
Not as a participant. As an advisor. The target company had
$14 million in ARR, a product that enterprise customers genuinely loved, and a
team that had built something real. The PE firm I was working with had signed
an LOI at a valuation that would have changed the founder's life. We were three
weeks from close.
Then the quality of earnings review started.
What we found was not fraud. It was not incompetence in the
way most people imagine incompetence. It was something more common and more
dangerous. It was a finance function that had grown through accretion rather
than architecture. Each time the business hit a new complexity threshold,
someone added a spreadsheet, a manual workaround, or a well-intentioned patch.
None of these patches were wrong in isolation. All of them were wrong in
aggregate.
The deferred revenue subledger did not tie to the general
ledger. It had not tied for two and a half years. The variance was 4 percent,
which sounds small until you realize that 4 percent of $8 million in deferred
revenue is $320,000 of unexplained discrepancy. The revenue recognition policy
memo had been written when the company sold only annual subscriptions, but the
company had since introduced usage-based contracts with minimum commitments,
hybrid pricing, and bundled professional services. The memo described a company
that no longer existed. Commission capitalization schedules existed but the
benefit period assumptions had never been documented, meaning the technical
accounting advisor could challenge them and the company would have no defense.
The deal did not collapse. It retraded. The purchase price
came down by $3 million. The closing timeline extended by five weeks. The
founder hired a technical accounting consultant at his own expense to oversee
remediation. The earnout structure was modified to include thresholds that
became harder to hit after the standalone selling price methodology was
revised.
I remember sitting in the conference room after the
retrading call, looking at the financial statements spread across the table,
and thinking: this was entirely preventable. Every single issue we found could
have been addressed in an afternoon if someone had known to address it two
years earlier. But no one knew. The controller was competent and honest. The
CFO was experienced. The founder was smart. They simply did not have the
framework to anticipate what would matter when scrutiny arrived.
That was the moment this book started forming in my mind.
Not as a book. As a question. Why does the same pattern repeat across hundreds
of transactions, dozens of audit engagements, and countless fundraising
processes? Why do finance functions that seem to work fine under normal
conditions collapse under the specific pressure of due diligence, audit, or IPO
preparation? And why do smart, capable finance leaders consistently fail to see
the gaps until a forcing event exposes them?
The answer, I realized, was that the knowledge required to
build a SaaS finance function that withstands scrutiny exists in fragments. ASC
606 guidance lives in accounting firm white papers. Metric definitions live in
investor blog posts. Technology evaluation lives in vendor comparison reports.
Operational process design lives in the heads of individual practitioners who
learned it through trial and error. No single source integrates all of these
dimensions into a coherent framework that a finance leader can implement.
So I decided to write that source. What started as a
question became an outline. What started as an outline became a forty-chapter
manuscript. What started as a manuscript became the book that I am now writing
about in this post.
The process of writing it took longer than I expected and
taught me more than I anticipated. I want to share some of what I learned,
because the lessons extend beyond the book itself.
The Pattern That Repeats
Across the transactions I worked on, the same failure modes
appeared with predictable regularity. I started keeping a list, not because I
planned to write a book, but because I wanted to understand whether what I was
seeing was systematic or coincidental.
It was systematic.
Deferred revenue reconciliations that do not tie. Revenue
recognition policies that were written once and never updated as the business
evolved. Commission capitalization schedules with undocumented benefit period
assumptions. Standalone selling price estimations that do not reflect actual
market pricing. Contract modifications processed in the billing system but
never reflected in revenue recognition schedules. Customer acquisition costs
calculated differently by the finance team, the sales team, and the board. Net
revenue retention numbers that cannot be reproduced from underlying contract
data. Cohort analyses that suffer from survivorship bias or censoring errors.
Billing platforms selected based on feature checklists rather than actual
contract complexity. ERP implementations that replicate inefficient processes
rather than redesigning them. Close processes that take fifteen days because no
one has invested in pre-close activities or automation.
None of these are exotic problems. They are the ordinary
consequences of building a finance function incrementally under growth
pressure. When you are hiring your third sales representative, closing your
first enterprise deal, and onboarding your second product line simultaneously,
you do not stop to redesign your revenue recognition policy memo. You add a
spreadsheet and move on. When you are processing five hundred invoices a month
and your billing platform cannot handle proration for mid-term upgrades, you do
not evaluate three alternative platforms. You calculate the proration manually
and move on.
Each decision is rational in context. The accumulation is
irrational in aggregate. And the accumulation remains invisible because growth
masks it. Revenue is increasing. Cash is accumulating. Investors are satisfied.
The board is happy. Everything looks fine because the forcing event has not
arrived.
The forcing event is the moment when someone examines your
finance function with forensic intent. An auditor testing revenue recognition
across a sample of contracts. A quality of earnings advisor tracing deferred
revenue from contract origination through modification through recognition. An
IPO readiness assessment evaluating internal controls against SOX requirements.
A due diligence team requesting cohort data that you have never properly
captured.
At that moment, the patches fail. The spreadsheets do not
tie. The policy memos do not address current contract types. The
reconciliations have variances that no one can explain. The metrics cannot be
reproduced. And the cost of fixing these problems under time pressure, with a
deal or a funding round or a public offering hanging in the balance, vastly
exceeds the cost of preventing them.
I have watched this pattern repeat enough times to know that
it is not bad luck. It is structural. The knowledge to prevent it exists, but
it is not accessible in a form that practicing finance leaders can use. That is
the gap this book attempts to close.
What I Learned Writing It
I expected writing this book to be an exercise in organizing
knowledge I already possessed. I was wrong. The process of structuring the
material revealed gaps in my own understanding that years of practice had
allowed me to overlook.
The first gap was in how I thought about the relationship
between accounting standards and business strategy. I had always treated ASC
606 as a compliance framework. You identify contracts, identify performance
obligations, determine transaction prices, allocate prices, and recognize
revenue. The steps are mechanical. The application requires judgment, but the
framework is fixed.
Writing Chapter 2, I realized that this view is incomplete.
ASC 606 is not merely a compliance framework. It is the technical architecture
that shapes every financial statement, every board presentation, and every
investor conversation. The way you identify performance obligations determines
your revenue recognition profile. The way you estimate standalone selling
prices determines how revenue flows between subscription and professional
services. The way you handle contract modifications determines whether upgrades
accelerate or defer revenue. These are not compliance decisions. They are
strategic decisions that affect how the business is perceived and valued.
A finance leader who treats ASC 606 as compliance will make
decisions that are technically defensible but strategically suboptimal. A
finance leader who treats ASC 606 as architecture will structure contracts,
pricing, and modifications to optimize both compliance and business outcomes.
The difference is not in accounting knowledge. It is in mental model.
The second gap was in how I thought about technology. I have
implemented ERP systems, evaluated billing platforms, and built API
integrations. I considered myself technology-fluent. Writing the technology
chapters, I realized that my fluency was operational rather than architectural.
I knew how to use the tools. I had not fully articulated the principles that
govern how the tools should be selected, integrated, and governed.
The distinction matters because operational fluency enables
you to execute projects that someone else has designed. Architectural fluency
enables you to design projects that someone else will execute. A finance leader
who relies on IT or engineering to design finance technology architecture will
get whatever IT or engineering prioritizes, which may not align with finance
needs. A finance leader who can articulate the business requirements, evaluate
vendor proposals, and govern integration architecture will get a finance
technology stack that serves the function.
The third gap was in how I thought about leadership. I had
managed finance teams through transformations, audits, and system
implementations. I considered myself an effective leader. Writing the
leadership chapters, I realized that I had been effective in spite of an
incomplete framework, not because of a complete one.
Change management, I discovered, is not a soft skill that
some leaders possess intuitively and others lack. It is a discipline with
identifiable components: stakeholder mapping, communication planning,
resistance diagnosis, training design, adoption measurement, and continuous
improvement. A leader who applies these components systematically will achieve
better transformation outcomes than a leader who relies on charisma and
instinct. The book forced me to articulate these components explicitly, which has
already improved my own practice.
The fourth gap was in how I thought about the future. I had
been watching the emergence of autonomous accounting platforms, generative AI
in finance, and real-time payment infrastructure with professional interest but
without strategic framework. Writing the emerging fintech chapter, I realized
that these technologies are not incremental improvements to existing processes.
They are transformative shifts that will redefine what finance functions do and
who does it.
A finance leader who views AI as a tool that will help their
team work faster is thinking too small. AI will eliminate most transaction
processing work within five years. The question is not how to use AI to do the
same work more efficiently. The question is what the finance function becomes
when transaction processing is no longer its primary activity. The answer, I
believe, is that finance becomes an analytical and strategic function that
focuses entirely on interpretation, judgment, and influence. The teams that
prepare for this transition now will thrive. The teams that resist it will be
automated into irrelevance.
Writing the book made me a better practitioner. Not because
I learned new facts. Because I was forced to organize what I knew into a
framework that others could follow, and the act of framework construction
exposed the inconsistencies and gaps in my own thinking.
The Question I Get Asked Most
When I tell people I have written a technical book about
SaaS finance, the most common question is: who is this book for?
The answer is narrower than it appears and broader than most
people expect.
The narrow answer is that the book is for finance leaders in
subscription-based technology companies. Controllers, VP Finance, CFOs, and
revenue accounting specialists who are responsible for building and operating
finance functions that serve SaaS organizations. These readers will find the
most direct application of the material, because the book addresses their
specific challenges with their specific context.
The broader answer is that the book is for anyone who
participates in the evaluation, financing, or acquisition of subscription
businesses. Private equity associates conducting due diligence on SaaS targets.
Venture capital analysts evaluating unit economics of portfolio companies.
Investment bankers preparing companies for public offerings. Audit partners
specializing in technology clients. Corporate development teams at strategic
acquirers. These readers will not implement the frameworks, but they will use
them to assess whether the companies they evaluate have implemented them.
The unexpected answer is that the book is for founders and
CEOs who do not have a finance background but are responsible for the financial
trajectory of their companies. These readers may skip the technical accounting
chapters and focus on the metric framework, the unit economics deep dive, the
pricing strategy chapter, and the leadership chapters. They will not become
accountants by reading these sections, but they will become better consumers of
financial information and better evaluators of finance talent.
I considered writing different books for different
audiences. A technical manual for controllers. A strategic guide for CFOs. An
investor's primer for due diligence teams. I decided against this because the
fragmentation of knowledge across audiences is part of the problem. Controllers
who do not understand what investors care about build functions that satisfy
auditors but fail due diligence. CFOs who do not understand the technical
accounting details make strategic decisions that create compliance problems.
Investors who do not understand operational finance make valuation decisions
based on metrics they cannot properly evaluate.
The book integrates these perspectives because the finance
leader's job integrates them. A controller who reads only the operational
chapters will miss the strategic context that gives their work meaning. A CFO
who reads only the strategic chapters will lack the technical foundation that
makes strategy executable. The comprehensive scope is not a marketing feature.
It is a structural requirement for the book to achieve its purpose.
What I Hope It Changes
I do not expect this book to become a bestseller in the way
that business books become bestsellers. It is too technical for casual readers,
too dense for airport bookstores, and too specific to a particular business
model for general business audiences. I am comfortable with this because the
book was not written for casual readers. It was written for practitioners who
need a reference that matches the complexity of their work.
What I do expect is that the book will change how specific
finance leaders approach specific decisions. A controller who reads the
deferred revenue chapter will implement a monthly reconciliation that they had
been performing annually. A VP Finance who reads the technology chapters will
evaluate billing platforms using their actual contract scenarios rather than
vendor demos. A CFO who reads the unit economics chapter will segment their CAC
by channel and discover that their most expensive channel produces their
lowest-LTV customers. A founder who reads the IPO readiness chapter will begin
SOX preparation eighteen months before their anticipated offering rather than
six.
Each of these changes prevents a specific failure mode that
I have watched cost companies money, time, and reputation. The aggregate impact
of these changes across the readers who implement them is the measure of the
book's success. Not copies sold. Not reviews posted. Not speaking invitations
generated. The number of finance functions that operate more effectively
because someone read this book and applied what they learned.
I also hope the book changes how finance leaders think about
their role. The stereotype of the finance function as a backward-looking
custodian of historical records is persistent and damaging. It attracts talent
that prefers predictability to impact. It encourages leaders to optimize for
accuracy rather than influence. It produces functions that are competent but
invisible, reliable but irrelevant to strategic decisions.
The finance leader who reads this book will recognize that
their role is not to report what happened but to shape what happens next. The
accounting standards are the foundation, not the ceiling. The technology is the
enabler, not the purpose. The metrics are the language, not the message. The
leadership is the capability that transforms all of these into business
outcomes.
This is the finance leader that subscription companies need.
This is the finance leader that the subscription economy rewards. This is the
finance leader that I hope this book helps create.
What Comes Next
The book is done. The work is not.
The subscription economy continues to evolve. New business
models emerge. New accounting standards are proposed. New technologies mature.
New regulations expand. The specific guidance in this book will require
updating as these changes occur. I plan to maintain the book through periodic
revisions, incorporating new developments and refining existing guidance based
on reader feedback.
I am also building a practice around the frameworks the book
describes. StackedCFO was founded to deliver the kind of finance leadership
that the book advocates. Not traditional accounting oversight, but integrated
finance architecture that combines accounting standards, technology systems,
analytical frameworks, and strategic partnership. The book provides the
knowledge. The practice applies it.
If you are a finance leader in a subscription business, I
hope you read the book. I hope you find it useful. I hope you implement the
frameworks that apply to your context. I hope you reach out with questions,
challenges, and counterarguments. The book is a starting point, not a final
answer. The conversation it starts is more valuable than the text it contains.
If you are a founder, CEO, or investor evaluating
subscription businesses, I hope the book gives you the analytical vocabulary to
assess finance functions with the same rigor you apply to product, market, and
team. The finance function is not a cost center to be minimized. It is a
capability to be evaluated, invested in, and leveraged. Companies that
understand this build finance functions that create competitive advantage.
Companies that do not build finance functions that create remediation costs.
The Monday morning email that I described in the prologue
does not have to arrive. The retrading, the delays, the remediation, the
reputation damage. These are not inevitable consequences of growth. They are
preventable outcomes of inadequate infrastructure. The infrastructure can be
built before it is needed. The knowledge required to build it is now available.
The decision to apply it belongs to you.
Comments