
Internal audit for SaaS companies: what to test beyond AR and cash
Most internal audit programmes for SaaS companies were designed for an earlier business model. AR ageing and cash reconciliation are necessary but no longer enough. The places where SaaS-specific risk concentrates are different.
Internal audit for a SaaS business is a strange place. The auditor's standard playbook — accounts receivable ageing, cash reconciliation, payroll testing, fixed asset register — is necessary, but it covers maybe 40% of where the actual risk sits. The other 60% is in places that did not exist when the playbook was written. MRR roll-forward integrity. Deferred revenue waterfall. Customer churn cohort accuracy. ESOP grant tracking. R&D capitalisation policy. Free trial accounting. Discount policy enforcement.
These are not exotic. They are the centre of how SaaS companies make and report money. An internal audit that does not test them is producing comfort on the parts that no longer move and leaving the parts that do move unaudited.
Why SaaS audit looks different
Two things drive the difference.
First, the revenue model. A SaaS contract that is paid annually upfront but delivered ratably over twelve months produces deferred revenue, MRR, ARR, and recognised revenue numbers that have to reconcile to each other every period. Each of these numbers has a different source system, different roll-forward logic, and different risks of misstatement.
Second, the cost structure. A SaaS company that capitalises a meaningful share of its software development as intangible assets under Ind-AS 38 has a P&L that is sensitive to capitalisation policy. The accounting auditor reviews the policy. The internal auditor has to test how it is applied transaction by transaction.
Revenue recognition under Ind-AS 115
Indian SaaS companies report under Ind-AS 115 (Revenue from Contracts with Customers), which is converged with IFRS 15. The standard requires identifying performance obligations, allocating transaction price, and recognising revenue as the obligations are satisfied — either over time or at a point in time, depending on the nature of the obligation.
For a typical SaaS contract — software access for 12 months plus implementation services plus optional professional services — there are usually two or three performance obligations. Software access is recognised over time, ratably. Implementation, if it has standalone value, may be a separate obligation recognised at completion or over the implementation period. Professional services are usually separate.
What internal audit tests: does the contract-level revenue recognition match the standard's treatment? Pull a sample of 25 to 40 contracts. For each, identify the performance obligations, the allocated transaction price, the revenue recognition pattern actually applied, and reconcile to the GL.
The errors we find: a contract bundled as one obligation when implementation should have been separated. A point-in-time recognition for a service that has continuous delivery characteristics. Allocation of transaction price using standalone selling prices that were not the standard's prescribed approach.
MRR and ARR roll-forward to billed revenue
The MRR and ARR numbers are reported to the board, the investors, and (for listed SaaS companies) to the market. The numbers come out of the customer relationship management system or the subscription billing platform. The billed revenue number comes out of the GL. These two numbers should reconcile.
They often do not, by amounts that range from small (rounding, timing) to material (missing customer cohorts, double-counted upgrades).
The MRR roll-forward — opening MRR + new MRR + expansion MRR - contraction MRR - churned MRR = closing MRR — is a sequence of additions and subtractions that has to be auditable transaction by transaction. The internal audit tests whether each component is being measured against the same source data, with the same definition, period over period.
Common findings: contraction MRR being netted against expansion MRR with no separate tracking. Churned MRR including customers who downgraded rather than left, mixing two events. New MRR including expansion revenue from existing customers.
Deferred revenue waterfall
Deferred revenue on the balance sheet should equal the sum of unfulfilled performance obligations across all customer contracts. The deferred revenue waterfall — the schedule that shows how the deferred balance will recognise into revenue over time — is a foundational internal audit test.
The test: pull the deferred revenue balance at period end. Independently rebuild the balance by computing unfulfilled obligations from each open contract. Reconcile.
The errors: contracts where the deferred revenue was not adjusted when a customer churned mid-term. Annual contracts where the recognition pattern accelerated incorrectly due to a system configuration error. Contracts with usage-based components where the unfulfilled obligation calculation depends on usage assumptions that may have changed.
Customer churn cohort accuracy
Churn is the lifeblood metric of SaaS. Cohort-level churn — the percentage of customers from a given period who are still customers N months later — is reported to investors and informs valuation. The number is built from the customer database.
Internal audit tests: is the cohort being measured consistently? Customers who paused for three months and returned — are they counted as churned or retained? Customers who downgraded to a free plan — churned at the paid level, retained at the free level? Customers acquired through an acquisition of another company — included in or excluded from the acquirer's cohorts?
Each of these is a definitional choice. The choice has to be documented and applied consistently. If the definition changes period over period, the trend lines that investors read are not comparable. The internal audit verifies that the definitions match across periods.
Free trial accounting
Many SaaS products offer a free trial period — 14 days, 30 days, sometimes 90 days. The accounting treatment depends on whether the trial creates a performance obligation and whether revenue is recognised during the trial.
The audit test: when does the contract start, accounting-wise? When does revenue recognition begin? Are users on trial counted in MRR? In customer count?
Different SaaS companies treat this differently. The internal audit confirms that the chosen treatment is documented in the revenue recognition policy and applied consistently.
Professional services revenue separation
Professional services attached to a SaaS contract — implementation, customisation, training, integration — have to be evaluated as separate performance obligations or bundled into the subscription, depending on whether the services have standalone value.
The audit test: the bundled vs separate determination. If the services are bundled with the subscription, the implementation revenue is recognised ratably with the subscription. If separate, the implementation is recognised on delivery.
The error pattern: implementation services that have standalone value (i.e., a customer could buy them from a third party) being bundled into the subscription, deferring revenue that should be recognised earlier.
ESOP grant tracking
SaaS companies hire on equity. The ESOP pool is a material component of the cap-table and the P&L (ESOP expense under Ind-AS 102 hits the P&L over the vesting period). Internal audit's role:
Grant register completeness. Every ESOP grant approved by the compensation committee is reflected in the grant register, with grant date, vesting schedule, exercise price, and recipient.
Vesting accuracy. The vesting that has accrued on each grant matches the schedule. Cliff vesting, monthly vesting after cliff, performance-vesting where applicable — each calculated correctly.
Expense recognition. The Ind-AS 102 expense for each grant is computed correctly, with the right fair value methodology (Black-Scholes is standard) and the right vesting curve.
Exercise and lapse tracking. Exercises are recorded with the correct share issuance and tax treatment. Grants that lapse on departure are removed from the schedule.
R&D capitalisation policy
Under Ind-AS 38, software development costs can be capitalised once the project crosses defined technical and commercial feasibility thresholds. Before that, the costs are expensed. Most SaaS companies have a capitalisation policy that defines the threshold and the cost categories.
The internal audit test: is the policy being applied consistently?
Common findings: costs being capitalised that should have been expensed (research vs development confusion). Costs being expensed that should have been capitalised (post-feasibility development being run through P&L). Different projects being treated differently with no documented justification.
The implication is material. A 10% shift in the capitalisation share can move EBITDA by single-digit percentage points for a development-heavy SaaS firm.
CAC payback and gross margin by SKU
Two numbers that are SaaS-investor-facing and increasingly audit-worthy.
CAC payback — how many months of gross margin does it take to recover the customer acquisition cost? The number depends on the definition of CAC (which sales and marketing costs are included) and the definition of gross margin (which costs are subtracted from revenue).
Gross margin by SKU — the margin profile of each product line. Pricing decisions, sales compensation, and investor messaging depend on this number being accurate. Internal audit tests whether the cost allocation is consistent and whether the SKU-level revenue is correctly attributed.
These are not regulated metrics. But for a SaaS company preparing for an IPO or a strategic exit, they will be examined by the buyer's diligence team. Internal audit can either get there first or wait for the buyer to find the inconsistencies.
Discount policy adherence
SaaS sales teams operate within a discount policy. Discounts above a threshold require manager approval. Discounts above a higher threshold require VP approval. Some companies have CEO-approval thresholds for the largest discounts.
The audit test: pull all contracts above a defined discount level. For each, verify that the approval matches the policy.
The findings cluster in two places. Contracts where the discount was approved by the right level but the approval is undocumented. Contracts where the discount exceeded the threshold and the approval came after the contract was signed, retroactively.
Neither is fraudulent. Both are control gaps that produce revenue numbers the audit committee should know about.
What we tell SaaS CFOs
Two things.
First, the standard AR and cash testing is necessary but not sufficient. Add the eight tests above. The cost of adding them is modest; the value of catching a revenue recognition or MRR roll-forward error before the audit committee, the auditor, or the investor finds it is high.
Second, the internal audit team has to understand the SaaS revenue model. A generalist internal auditor who learned audit on manufacturing or trading companies will not catch the SaaS-specific issues. Either the team has someone with SaaS-specific experience, or the firm running the audit does.
A SaaS internal audit that does not test the MRR roll-forward, the deferred revenue waterfall, and the cohort definitions is auditing the back office while the front office numbers — the ones the board, the investors, and the next buyer actually look at — are unaudited. The risk concentration has moved, and the audit programme has to move with it.
References

