SaaS Revenue Recognition Under Ind AS 115
AS | Ankit Sarawagi|Founder, CFOmatrix·July 2026·9 min read | Rev-Rec explained |
- Recognise over time, not on invoice. Subscription revenue is earned as the service is delivered, spread evenly across the subscription period.
- Ind AS 115 is a five-step model. Identify the contract, the obligations and the price, allocate the price, then recognise as each obligation is satisfied.
- Deferred revenue is a liability. Cash collected upfront that you have not yet earned is an obligation to keep serving, not profit.
- Usage is recognised as consumed; implementation over time or at milestones. Different revenue types follow different patterns.
- Clean rev-rec is a top diligence item. Investors check it early, and it must tie to your ARR, MRR and the general ledger.
| 5 steps The Ind AS 115 recognition model | 1/12 Of an annual plan recognised each month | #1 Skeleton auditors open in diligence |
The Principle: Recognise As You Deliver, Not When You Invoice
The single idea behind SaaS revenue recognition is this: revenue is earned as you deliver the service, not when you raise the invoice and not when the money lands. Sell a customer an annual plan for ₹12 lakh and collect it all on day one, and you have still earned nothing on day one. You earn it by keeping the software running and available, month after month, so you recognise ₹1 lakh a month across the twelve-month term.
This is the difference between three numbers founders routinely blur. Bookings is what the customer has committed to (the signed contract). Billings is what you have invoiced. Revenue is what you have actually earned and can recognise this period. They can all be different in the same month, and confusing them is how a founder feels flush with cash while overstating the profit and loss account.
| Event | When | Amount |
| Invoice raised (billing) | Day 1 | ₹12,00,000 |
| Cash collected | Day 1 | ₹12,00,000 |
| Revenue recognised | Day 1 | ₹0 |
| Revenue recognised | Each month (1 to 12) | ₹1,00,000 |
| Total revenue by month 12 | End of term | ₹12,00,000 |
Bookings is what the customer committed to, billings is what you invoiced, revenue is what you earned this period. A new ₹12 lakh annual deal signed on 1 July is ₹12 lakh of bookings, ₹12 lakh of billings, but only ₹1 lakh of July revenue. Report all three, and never call a booking revenue.
What Ind AS 115 Says, in Plain Language
Ind AS 115, Revenue from Contracts with Customers, is India’s revenue recognition standard, converged with the global IFRS 15. It replaced the older, patchier revenue guidance with a single, consistent five-step model that applies to every contract, including your SaaS subscriptions. Here it is without the jargon.
Step 5 is where SaaS lands on the over-time answer. Because the customer receives and consumes the benefit of the software continuously (they have access every day of the term), the performance obligation is satisfied over time rather than at a point in time, so revenue is recognised as the term elapses. That is the accounting root of everything else in this guide.
How Deferred Revenue Arises
Once you recognise over time but collect upfront, a gap opens between the cash you hold and the revenue you have earned. That gap is deferred revenue (also called unearned revenue): a liability on your balance sheet representing the service you still owe the customer. It is not your money to keep yet.
Follow the same ₹12 lakh annual plan. On day one you hold ₹12 lakh of cash and ₹12 lakh of deferred revenue, a matched liability. Every month you deliver, you release ₹1 lakh from deferred revenue into recognised revenue. By month twelve the liability is zero and the full ₹12 lakh has been earned.
| After month | Recognised to date | Deferred revenue balance | Bar |
| Day 1 | ₹0 | ₹12,00,000 | |
| Month 3 | ₹3,00,000 | ₹9,00,000 | |
| Month 6 | ₹6,00,000 | ₹6,00,000 | |
| Month 9 | ₹9,00,000 | ₹3,00,000 | |
| Month 12 | ₹12,00,000 | ₹0 | empty |
A rising deferred revenue balance means you have collected cash for services you will deliver later: it funds runway and locks the customer in. Read it alongside your deferred revenue and billing mechanics, because the same balance that flatters your bank account is a liability you must be able to service.
Usage and Implementation Revenue
Not all SaaS revenue is a flat monthly subscription. Two other streams follow their own recognition patterns, and AI SaaS in particular leans heavily on the first.
Usage or consumption revenue is recognised as it is consumed: in the period the units are actually used, not spread evenly and not upfront. If a customer draws 40 lakh API calls in July, that usage is July revenue. Where the customer prepays into a wallet or top-up, the prepayment is deferred revenue when paid and is drawn down into recognised revenue as consumption happens. Implementation, onboarding and professional-services fees are a separate performance obligation from the subscription: recognise them over time as the work is performed, or at milestones as each stage is accepted. Do not book a large setup fee upfront just because you invoiced it.
| Revenue type | When recognised | Pattern |
| Subscription | Over the subscription term | Evenly, straight-line across the period |
| Usage / consumption | As units are consumed | Variable, in the period of use; wallet is deferred until drawn |
| Implementation / services | As work is performed | Over time (percentage of completion) or at milestones |
In the AI SaaS companies I have worked with, consumption is a large and genuinely variable share of revenue, so recognition depends entirely on clean usage metering. Bake per-customer metering into the product from day one: it is what lets you recognise usage in the right period, reconcile a prepaid wallet, and read per-customer margin at the same time. Without it, usage rev-rec becomes guesswork.
Why Clean Rev-Rec Is a Top Diligence Item
Revenue recognition is one of the first skeletons investors and their auditors open in due diligence, for a simple reason: if the top line is recognised wrongly, every metric built on it is wrong too. They will check that you have a documented rev-rec policy, that it follows Ind AS 115, that it has been applied consistently, and that recognised revenue, deferred revenue and your ARR and MRR all reconcile back to the general ledger.
Recognising annual subscriptions upfront, a setup fee booked in one shot, metrics that do not tie to the books, or a policy that changed silently between years: any of these can cut your valuation or stall the deal. Fixing rev-rec retrospectively, mid-diligence, is painful and erodes investor trust. Set the policy correctly at the start.
“Revenue recognition is the first thing a serious diligence team pulls apart. If your recognised revenue, your deferred revenue and your ARR do not tie back to the ledger, everything else you claim gets doubted. Clean rev-rec is quiet proof the rest of the numbers are real.”
Ankit Sarawagi, from working across SaaS and AI SaaS startupsThe practical takeaway: write the policy down early, apply it every month, and make sure your metrics reconcile to your accounts. That is exactly what a good finance function installs before you ever open a data room. Go deeper on the related pieces: deferred revenue and billing, GST for SaaS and export of services, and the data room and diligence checklist. The full context sits in the SaaS finance pillar guide.
Frequently Asked Questions
When do I recognise SaaS revenue?
You recognise SaaS subscription revenue as you deliver the service, evenly over the subscription period, not when you invoice or collect. Bill ₹12 lakh for an annual plan on day one and you recognise one-twelfth (₹1 lakh) each month. The invoice date and cash date do not drive revenue; the passage of the service period does. This is the over-time model under Ind AS 115.
What is Ind AS 115?
Ind AS 115 is India’s revenue recognition standard, converged with IFRS 15, titled Revenue from Contracts with Customers. It applies a single five-step model: identify the contract, identify the performance obligations, determine the transaction price, allocate the price, and recognise revenue as each obligation is satisfied. For a SaaS subscription the obligation, continuous access to the software, is satisfied over time, so revenue is spread across the period.
How does deferred revenue arise?
Deferred revenue arises whenever you collect cash before delivering the service. Bill ₹12 lakh upfront and, on day one, you have earned none of it, so the whole amount sits as deferred revenue, a liability. Each month you deliver, you move one-twelfth into recognised revenue. It is an obligation to keep serving the customer, which is why SaaS runs on negative working capital.
How do I recognise usage or consumption revenue?
Recognise it as the customer consumes it, in the period the units are used, not spread evenly and not upfront. If a customer draws 40 lakh API calls in July, you recognise July’s usage in July. A prepaid wallet or top-up is deferred revenue when paid and is drawn down into recognised revenue as usage occurs. This matters most for AI SaaS, where a large share of revenue is consumption-based.
How do I treat implementation or onboarding fees?
They are a separate performance obligation from the subscription. If the work is delivered over a period, recognise it over time as performed (percentage of completion); if delivered at defined stages, recognise it at each milestone as that stage is accepted. Do not book a large implementation fee upfront. Where onboarding is not distinct from the subscription, it may be bundled and recognised over the contract term.
Why does revenue recognition matter in diligence?
It is one of the first skeletons investors and auditors open. They check that you have a documented rev-rec policy, that it follows Ind AS 115, that it is applied consistently, and that recognised revenue, deferred revenue and your ARR and MRR tie back to the ledger. Upfront-recognised subscriptions, metrics that do not reconcile, or a silently changed policy are red flags that can cut your valuation or stall the deal.
Sources: Ind AS 115, Revenue from Contracts with Customers (converged with IFRS 15), and the author’s experience across SaaS and AI SaaS startups. This is general educational information for founders, current to mid-2026, and is not legal, tax or investment advice. Accounting rules (Ind AS) and their application to specific contracts change and depend on facts; verify the current position or consult a professional before acting on a specific matter.
GST for SaaS: Export of Services
The Data Room and Diligence
AS | Founder, CFOmatrix | Finance Strategy & Equity Compliance CFOmatrix is a knowledge platform focused on how finance actually works inside growing companies. This guide draws on hands-on experience across SaaS and AI SaaS startups, from revenue recognition and deferred revenue to metrics, pricing and investor-ready reporting. |