A generalist CFO will get your monthly close right, build a competent model, and produce a board pack that looks professional. Then a buyer's accountants open the file during diligence and find that annual contracts were recognised when invoiced, sales commissions were expensed in the month they were paid, and the backlog number in the deck was never a backlog number. None of those are exotic. They are the default answers, and for a SaaS company the default answers are wrong.
SaaS finance breaks in places a generalist will not think to look. This is what a CFO who has closed SaaS books before actually watches, and why each one matters before you raise or sell.
It is not that revenue is ratable
The common explanation for why SaaS accounting is hard is that revenue has to be spread over the contract rather than booked on invoice. That part is genuinely straightforward, and software handles it. Getting it wrong is a setup error, not a judgment error.
The hard parts sit underneath. ASC 606 is a judgment standard rather than a procedure, and the judgments are yours to make and document. A bookkeeper executes a revenue policy. A SaaS CFO writes one and defends it.
Your product is a service, not a licence, and that changes things
Hosted software is usually not a licence for accounting purposes at all. It only counts as one if the customer can take possession of the software without significant penalty and could feasibly run or host it themselves. Almost no SaaS arrangement clears both tests, so it is accounted for as a service.
That single classification has consequences that surprise people. Revenue is recognised over time rather than at a point in time. Updates and maintenance generally are not separate obligations, because you are maintaining your own platform rather than delivering something to the customer. And the usage-based royalty shortcut available to licences of intellectual property is not available to you, which matters as soon as any part of your pricing is consumption-based.
Usage-based pricing and the relief that makes it workable
If part of your revenue is metered, the default position is uncomfortable: you would have to estimate total usage across the contract at inception and constrain it. The way out is an allocation exception that lets a variable amount be assigned entirely to the period it relates to, provided the payment terms relate specifically to that period's service and the allocation still reflects value delivered.
In practice that means a flat per-unit fee, consistent across the contract and settled within each period, can usually be recognised in the month the usage happens without forecasting the year. What breaks it is a minimum or a rate that is measured across the whole contract, because then this month's overage relates to cumulative usage rather than to this month, and you are back to estimating. Two contracts with identical economics can land on opposite accounting treatments purely on where the measurement window sits, which is why the CFO needs to be in the room when pricing is designed rather than after.
Commissions almost never amortise over the contract term
This is the one that catches nearly everyone, and it is a live audit issue. Incremental costs of winning a contract, principally sales commissions, are capitalised and then amortised over the period of benefit, which is not the same as the contract term. If you expect customers to renew, the period of benefit includes those anticipated renewals.
The test is whether the renewal commission is commensurate with the initial one, and it is judged on economics rather than on effort. The common structure of paying, say, five percent on new business and one percent on renewals fails that test, which means the new-business commission has to be amortised over the initial term plus expected renewals rather than over the twelve-month contract.
Notice what that implies. The design of your sales compensation plan determines your accounting treatment, and defending the amortisation period requires a cohort-derived estimate of customer life. Comp design, retention analysis, and a balance sheet asset turn out to be one connected problem, and the CFO is the only person who sees all three.
Deferred revenue, contract liabilities, and the RPO trap
Deferred revenue is the everyday word; contract liability is the accounting one, and it is triggered when payment is received or becomes due, whichever comes first. Invoicing an annual contract at signature can create the liability before the cash lands.
The trap is remaining performance obligations. RPO covers only the non-cancellable portion of your contracts. A three-year deal terminable on thirty days' notice contributes thirty days to RPO, not three years. Companies that put total contract value in a deck and call it backlog are not describing RPO, and the correction tends to arrive at the worst possible moment.
You capitalise your own product under the internal-use rules
One more classification that surprises founders: because your customers never take possession of the software, your own product development is accounted for under the internal-use software rules rather than the rules for software you sell. That decides when capitalisation starts and stops.
This area is changing. A 2025 standard removes the old sequential development-stage model, which never fitted agile work, and replaces it with a test based on whether funding is committed and completion is probable, with capitalisation held back while significant development uncertainty remains. It takes effect for annual periods beginning after 15 December 2027, with early adoption permitted, and the expectation is that it will reduce capitalisation for cloud products specifically. The current model still governs until then, so the practical job is knowing which one you are on and when you switch.
The metrics that come with the territory
Beyond the accounting, a SaaS CFO owns a reporting set a generalist will not build: an ARR bridge separating new, expansion, contraction, and churn; cohort retention rather than a blended churn rate; CAC payback; and burn multiple. The bridge matters most, because it is what turns a growth number into a diagnosis.
It is also worth knowing that ARR and GAAP revenue will not agree, and that this is expected rather than a problem. ARR is a forward-looking run rate with no authoritative definition; revenue is backward-looking and audited. The CFO's job is producing the reconciliation between them, and being able to explain it on demand. See net revenue retention for the metric where churn shows up first.
Where Zinance fits
Zinance runs SaaS finance as one function: daily-closed books, revenue recognition handled as a policy rather than an afterthought, R&D credits captured through the year, and CFO-level reporting built from the same ledger. For companies in this segment specifically, see our SaaS practice.
This article is educational and general, not accounting, tax, or legal advice, and it creates no client relationship. Revenue recognition and software cost treatment depend on your specific contracts and facts, and several of the areas described here involve genuine judgment on which qualified professionals reach different conclusions. Confirm your positions with your own accountants and auditors.