Why ASC 606 Is Harder for India SaaS Companies Than Anyone Tells You
If you're a finance leader at an India-based SaaS company selling to US or global customers, you've probably heard the same advice everywhere: "just follow the 5-step ASC 606 model." What almost nobody tells you is what happens when that model collides with GST, multi-year contracts billed in INR, and a finance team doing period close in a spreadsheet at 11pm.
This guide covers ASC 606 the way it actually shows up for India SaaS companies — not the textbook version.
What ASC 606 Actually Requires (The 5-Step Model, Briefly)
ASC 606 — and its international equivalent, IFRS 15 — governs when and how much revenue you're allowed to recognize from a customer contract. The five steps are:
- Identify the contract with a customer
- Identify the performance obligations — what you're actually promising to deliver
- Determine the transaction price — the total amount you expect to be entitled to
- Allocate the price across each performance obligation
- Recognize revenue as each obligation is satisfied
That's the theory. Here's where it actually gets complicated for a SaaS company billing annually or over multiple years.
The Real Problem: Invoice Date Is Not Recognition Date
The single most common mistake we see in India SaaS finance teams: treating the invoice date as the revenue recognition date.
If a customer signs a 3-year contract and pays ₹36,00,000 upfront, you have not earned ₹36,00,000 of revenue the day that invoice clears. Under ASC 606, that amount needs to be recognized ratably over the 3-year service period — typically month by month, as the service is actually delivered.
This means:
- The cash hits your bank account on day one
- The revenue is recognized gradually, over 36 months
- The difference sits on your balance sheet as deferred revenue — a liability, not income, until it's earned
Get this wrong, and your P&L looks nothing like your actual business performance — which becomes a serious problem the moment an investor, auditor, or board member asks to see your numbers.
Where GST Makes This Even Harder
Here's the part most ASC 606 guides — written for US audiences — never mention: your GST treatment and your revenue recognition schedule are two completely separate calculations, and conflating them is a common, costly mistake.
GST is charged and remitted based on the invoice date and the applicable GST treatment type (registered regular, unregistered, overseas/export, SEZ, and several others — India has roughly 10 distinct GST treatment scenarios that a B2B SaaS company can encounter). Revenue recognition under ASC 606 follows the performance obligation timeline, which has nothing to do with when GST becomes payable.
A finance team that tries to force these two into the same schedule usually ends up with either:
- GST filings that don't reconcile cleanly with revenue reports, or
- A revenue recognition schedule that's quietly being distorted to make the accounting "easier" — which is exactly the kind of thing that turns into a real problem at audit time
Multi-Year Contracts: The Escalation Clause Trap
Many India SaaS contracts include built-in price escalation — for example, a 3-year deal where the price increases 10% each renewal year. Under ASC 606, if that escalation is already specified in the original contract, it typically needs to be factored into the total transaction price calculation from day one — not treated as a fresh new sale each year.
This is a detail that's easy to miss manually, and one that compounds — a small error in year one of a 3-year schedule doesn't just misstate one month, it distorts the entire remaining recognition curve.
Period Close: Where This All Comes Together (Or Falls Apart)
At month-end, a finance team needs to answer, for every active contract:
- How much revenue was actually earned this period?
- How much remains deferred?
- Does any backdated entry (a late contract amendment, a correction) need special handling?
Most finance teams handle backdated or unusual entries with what we think of as a materiality-based decision:
- Small, immaterial adjustments — close automatically, no separate review needed
- Moderate adjustments — flagged for CFO review before the books close
- Material adjustments — require both CFO and controller sign-off before anything is finalized
The mistake we see most often isn't getting the accounting theory wrong — it's not having a consistent, repeatable process for making this judgment call every single month, which is exactly when errors creep in.
What This Actually Looks Like When It's Automated
This entire process — invoice-to-recognition separation, GST treatment applied independently of revenue timing, multi-year escalation clauses correctly modeled from contract signing, and a consistent materiality-based period close — is exactly what Fincelo was built to handle automatically for India SaaS companies, without asking your finance team to rebuild the logic in a spreadsheet every month.
If you're currently doing any part of this manually, it's worth seeing what a platform built specifically for this problem looks like.
 |
| ASC 606 revenue recognition waterfall chart for a SaaS company |
Start a 14-day free trial at fincelo.app →
Fincelo is an agentic AI-powered SaaS billing and revenue intelligence platform, built for Series A/B India SaaS companies and their CFOs.
