Originally published on rikuq.com. Republished here for Dev.to's readers.
The question I get most often from Indian CFOs about AI accounting goes something like: "we just paid OpenAI ₹40 lakh for the year. Capitalise or expense?" The short answer is expense — but the long answer is a structured test that produces the wrong answer if you don't actually run it, and the wrong answer here is the kind that statutory auditors flag at year-end and audit committees ask about in board meetings.
This post walks through the Ind AS 38 framework as applied to AI software at Indian mid-market scale, the narrow situations where capitalisation actually applies, the Section 32 tax overlay that creates timing differences when you do capitalise, and the misclassifications that show up repeatedly in audit review.
I'm Ravi. I run three production AI SaaS (Prism, Citare, BatchWise) and do advisory work on AI spend tax classification via rikuq services. The framework below is what I take into every CFO conversation about AI accounting under Ind AS.
TL;DR
| Default treatment for typical AI spend categories |
|---|
| SaaS subscription (Salesforce, Notion, GitHub, etc.) → Opex |
| Foundation model API consumption (OpenAI, Anthropic, Google, Azure OpenAI) → Opex |
| Fine-tuning on third-party API → Opex (criterion 3 fails) |
| Fine-tuning on self-hosted open-weight model → Opex by default, CapEx only if all 6 §57 criteria met |
| Purchased perpetual software licence → CapEx (amortise + 40% WDV tax depreciation) |
| Internally-developed AI capability → OpEx during research, CapEx during development if criteria met |
| Multi-year prepaid SaaS or cloud commitment → Prepaid expense (current asset), NOT opex in year 1 |
| Staff training to operate AI → OpEx (§69(b) explicit exclusion from capitalisation) |
| Post-deployment maintenance + updates → OpEx |
Most AI spend at Indian mid-market scale ends up opex. The capex window is narrow and specific.
The side-by-side classification table
| Spend category | Typical treatment | Why | Standards reference |
|---|---|---|---|
| SaaS subscription (monthly / annual) | OpEx — period expense | No control / no intangible asset created; access right ceases on non-renewal | Ind AS 38 §17 (control test) + Section 37 IT Act |
| Multi-year SaaS prepayment | Prepaid expense — amortise over commitment period | Pre-paid opex, not an intangible asset | Ind AS 38 (no asset) + Section 37 |
| Foundation model API consumption | OpEx — period expense | Pay-per-use; no asset; no control of underlying model | Ind AS 38 (no asset) + Section 37 |
| Fine-tuning on third-party API | OpEx | Resulting capability inseparable from provider's platform; criterion 3 fails | Ind AS 38 §57 + Section 37 |
| Fine-tuning on open-weight model self-hosted | OpEx default; CapEx if all 6 criteria met | Customer-controlled outputs possible; capitalisation requires §57 satisfaction | Ind AS 38 §57 + Section 32 (40% WDV) |
| Purchased perpetual licence (on-premise) | CapEx — capitalise + amortise | Control of asset; benefit extending beyond one period | Ind AS 38 §10-17 + Section 32 (40% WDV) |
| Internally-developed AI capability | OpEx in research phase; CapEx in development phase if criteria met | §54 (research) vs §57 (development); 6-criteria test | Ind AS 38 §54-57 + Section 32 |
| Post-deployment maintenance + updates | OpEx | Recurring maintenance; doesn't extend useful life | Ind AS 38 §69 + Section 37 |
| Staff training to operate AI | OpEx | Explicit exclusion from capitalisation | Ind AS 38 §69(b) + Section 37 |
| Cloud reserved-instance / committed-use prepayment | Prepaid expense (current + non-current portions) | Multi-period opex, not an asset | Ind AS 38 + Section 37 |
| Cloud labour at delivery (engineers building on cloud) | OpEx default; CapEx allocable to internally-developed asset if §57 met | Direct attributable cost capitalisable if asset criteria met | Ind AS 38 §66 |
The Ind AS 38 paragraph 57 six-criteria test
For any internally-generated intangible asset (including internally-developed AI capability), all six criteria must be demonstrably met before capitalisation is allowed:
- Technical feasibility of completing the intangible asset
- Intention to complete and use or sell it
- Ability to use or sell the intangible asset
- Demonstration of how the asset will generate probable future economic benefits
- Availability of adequate technical, financial, and other resources to complete development
- Ability to reliably measure expenditure attributable to the intangible asset
In my experience the criterion that most often fails for AI fine-tuning is criterion 3 — ability to use or sell. If the fine-tuning lives on a third-party API platform (the OpenAI fine-tuning endpoint, Anthropic's custom-model service, Google's PaLM tuning) and the entity cannot extract the resulting capability for use independently of the provider, criterion 3 fails. Capitalisation is precluded regardless of how well the other five criteria are satisfied.
For internally-developed AI capability on open-weight models (Llama, Mistral, etc.) hosted on the entity's own infrastructure, all six criteria can be satisfied. Capitalisation becomes possible, but you still have to run the test — it's not automatic.
The auditor will ask you to document the §57 evaluation. If you haven't run it, you've already lost the conversation.
The Section 32 tax overlay
Where Ind AS 38 capitalises a software asset, Section 32 of the Income Tax Act governs the tax depreciation:
- Computer software falls in the Block of Assets category attracting 40% depreciation on Written Down Value (WDV) basis
- Tax depreciation calculation is independent of book amortisation under Ind AS 38
- Book amortisation under Ind AS 38 is typically straight-line over useful life (2-5 years for purchased software licences); tax depreciation is 40% WDV
- The differential creates a timing difference under Ind AS 12 (Income Taxes) which gets recognised as a deferred tax line item
- For internally-developed AI capability capitalised under Ind AS 38, the tax treatment depends on classification — if the asset qualifies as "computer software," 40% WDV applies; otherwise the general intangibles regime applies
The practical implication: when you do capitalise (the narrow case), the tax depreciation is materially faster than book amortisation, so you end up with a deferred tax asset that unwinds over the asset's useful life. This isn't a problem — it's a normal Ind AS 12 mechanic — but it has to be calculated, disclosed, and reconciled. Skipping the deferred tax line is one of the more common findings in audit review.
The six misclassifications I see most often
These are the patterns that show up in mid-market entity books when AI spend classification hasn't been disciplined. Each one creates audit risk and most create tax inefficiency on top.
| Misclassification | Why it happens | Consequence |
|---|---|---|
| Multi-year SaaS prepayment expensed in year 1 | Bookkeeper treats full payment as period cost | Year 1 P&L overstated; subsequent years understated; current-asset balance understated |
| Custom AI model build expensed instead of capitalised | Finance team defaults all R&D to opex; doesn't run the §57 test | Section 32 depreciation claim lost; permanent tax disadvantage |
| Fine-tuning on third-party API capitalised in error | Finance team capitalises any "AI development" cost regardless of platform | Audit risk — capitalised asset that doesn't meet §57 criterion 3 |
| Reserved-instance cloud commitments expensed upfront | Bookkeeper treats full commitment as period cost | Year 1 P&L overstated; mismatch with consumption; prepaid asset balance missing |
| Staff training on AI tooling capitalised | Finance team includes training in "AI implementation cost" | Audit risk — §69(b) explicit exclusion violated |
| Configuration/customisation paid to SaaS vendor capitalised | Finance team treats one-time setup as asset creation | Audit risk — no control over the underlying SaaS |
The pattern: most misclassifications fall on the "over-capitalise" side, because finance teams treat AI work as analogous to traditional software development where capitalisation was more common. The Ind AS 38 framework actually pushes the other way for AI spend — the control test and §57 criteria are harder to satisfy than they were for traditional internally-developed software, so opex is the more common outcome.
The Indian audit-readiness angle
Indian audit committees and statutory auditors are increasingly scrutinising AI-augmented financial reporting on these dimensions:
- Whether AI software in financial statements is classified consistent with Ind AS 38 control test plus §57 criteria
- Whether SaaS and API consumption is correctly opex-classified (not erroneously capitalised)
- Whether internally-developed AI capability meeting §57 is correctly capitalised (not erroneously expensed, which loses the Section 32 claim)
- Whether deferred tax under Ind AS 12 correctly reflects book versus tax timing differences
- Whether multi-year prepayments are correctly classified as prepaid asset (not opex in year 1)
The operative frameworks are the DPDP Act 2023, ICAI voluntary practitioner guidance on AI assurance and audit evidence, and the EU AI Act for entities with European exposure. SEBI's June 2025 consultation paper on AI/ML in securities markets applies today to market infrastructure institutions, market intermediaries, and mutual funds; it's still in consultation for the broader market. The point is that misclassification under Ind AS 38 is audit risk independent of how the SEBI consultation hardens.
AI spend classification review under Ind AS 38 plus Section 32 is now part of normal audit-readiness work. Best done before the financial year closes, not at audit when the auditor surfaces it.
How Indian mid-market entities actually consume AI
For context on why the table above lands as it does, here's the practical pattern at Indian mid-market scale:
- Foundation model APIs (OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock) — opex by default
- SaaS tools with AI features (Notion AI, Salesforce Einstein, GitHub Copilot, Adobe Firefly) — opex as part of the SaaS subscription
- Internally-developed AI workflows using prompt engineering on third-party APIs — opex (no internally-generated intangible asset)
- Fine-tuning on third-party APIs (OpenAI fine-tuning, Anthropic custom models) — opex (§57 criterion 3 fails on the platform-dependency)
- Self-hosted open-weight models (Llama, Mistral on own infrastructure) — opex default; CapEx if internal development meets §57, which is a real case but requires careful documentation
- Cloud reserved capacity for AI workloads — prepaid expense, amortised over commitment period
The vast majority of AI spend at this scale is opex. CapEx applies in specific cases — purchased perpetual licences (increasingly rare), genuinely internally-developed AI capability with §57 satisfied, and certain customer-controlled customisation scenarios. The discipline is running the test rather than defaulting to either outcome.
What to do this week
If you're a CFO or finance lead at an Indian mid-market entity with material AI spend and you haven't formalised the classification framework:
- Run the §57 test on any AI spend currently classified as capex. If you can't document satisfaction of all six criteria, opex is the safer answer.
- Audit your multi-year SaaS prepayments. Confirm they're sitting in prepaid expense (current + non-current as appropriate), not opex in year 1.
- Verify your reserved-instance cloud commitments are prepaid asset, not opex upfront. This is the easiest one to find and fix.
- Confirm Ind AS 12 deferred tax reflects timing differences where you've correctly capitalised. The 40% WDV vs straight-line book amortisation differential creates deferred tax that has to be on the books.
If you want a written scope proposal for the tax-recovery side of this work — what an AI Spend & Tax Optimisation engagement would look like for your specific situation, including the Ind AS 38 review and any GST RCM / Section 195 work — the services page has both a Cal.com booking link and a Tally intake form.
What's next
This post focuses on the accounting and tax classification layer. The adjacent posts that go deeper on related dimensions:
- What is LLM FinOps? — the operational discipline that produces the consumption data this classification work depends on
- FinOps vs ITFM vs ITAM — where this classification work sits within the broader cost-management framework
- AI / Cloud FinOps Providers in India — provider selection for the FinOps and tax-recovery work
Top comments (0)