Short answer: Software development costs can be either expensed (charged to the profit and loss account in the period incurred) or capitalised (recorded as an intangible asset on the balance sheet and amortised over time). The correct treatment depends on the phase of development and whether specific recognition criteria are met. Indian companies follow Ind AS 38 or AS 26 for intangible assets. This is general information — your CA should confirm the appropriate treatment for your specific circumstances.
Why the treatment of software costs matters
The decision to capitalise or expense software development costs is not simply an accounting technicality. It affects your reported profitability in the short term, your balance sheet, your tax position (to the extent accounting treatment influences tax computations), and how investors or lenders read your financial statements.
A business that expenses all development costs will show higher costs and lower profit in the years those costs are incurred. A business that capitalises eligible costs will show lower expenses in those years and report the costs as an asset, amortising them over the useful life of the software. Neither approach is inherently better — the right treatment is determined by the accounting standards that apply to your company and the facts of your situation.
The applicable standards: Ind AS 38 and AS 26
Indian companies that prepare financial statements under Indian Accounting Standards follow Ind AS 38 — Intangible Assets for the treatment of software development costs. Companies that have not transitioned to Ind AS (many smaller private companies) follow AS 26 — Intangible Assets, which covers broadly similar ground but with some differences in the detail.
Both standards draw a fundamental distinction between two phases of development: the research phase and the development phase.
Research phase: Activities undertaken to gain new knowledge, evaluate whether a project is feasible, search for alternatives. Costs incurred in the research phase are always expensed as incurred — they cannot be capitalised, because at this stage there is insufficient certainty that a future economic benefit will flow from the expenditure.
Development phase: Activities that involve applying research findings to a plan or design for the production of new or substantially improved products. Costs incurred in the development phase can be capitalised — but only if all of the recognition criteria are met.
The six criteria for capitalising development costs
Under Ind AS 38, development-phase costs can only be capitalised as an intangible asset if the entity can demonstrate all of the following:
- Technical feasibility — it is technically feasible to complete the intangible asset so that it will be available for use or sale
- Intention to complete — the entity intends to complete the asset and use or sell it
- Ability to use or sell — the entity has the ability to use or sell the intangible asset
- Probable future economic benefits — the asset will generate probable future economic benefits (either revenue or internal utility)
- Adequate resources — adequate technical, financial, and other resources are available to complete the development and use or sell the asset
- Reliable measurement — the expenditure attributable to the development phase can be reliably measured
If all six criteria are met, development-phase costs must be capitalised — it is not optional. If any one criterion is not met, the costs must be expensed. In practice, demonstrating all six criteria requires documentation: a project plan, a technical assessment of feasibility, evidence of funding, and a tracking system that separates research-phase from development-phase expenditure.
How this maps to a real software project
A typical custom software project does not come neatly pre-divided into research and development phases. In practice, the boundary is roughly:
| Activity | Phase | Treatment |
|---|---|---|
| Exploring whether software can solve a business problem | Research | Expense |
| Evaluating build vs. buy options | Research | Expense |
| Designing architecture and technical approach | Ambiguous | Often research |
| Writing code once technical feasibility is established | Development | Capitalise (if criteria met) |
| Testing and debugging during development | Development | Capitalise (if criteria met) |
| Post-launch bug fixes | Maintenance | Expense |
| Significant new features added post-launch | Development (new asset or enhancement) | Assess separately |
| Routine maintenance and minor updates | Maintenance | Expense |
The ambiguity at the boundary — particularly around architecture and design work — is where judgement is required and where guidance from a CA is valuable.
Purchased software versus internally developed software
The accounting treatment differs depending on whether the software was:
Purchased outright (you buy a licence to a finished software product, or commission a development agency and receive the completed software). If the software meets the definition of an intangible asset — it is identifiable, you control it, and it is expected to generate future economic benefits — it can generally be recognised at cost. This is why the IP ownership question discussed in our guide to software ownership has accounting consequences: if you do not actually own the software, you may not be able to recognise it as an asset.
Internally developed (your own employees build the software as part of their employment). The research/development phase distinction applies in full, and you need to track costs by phase.
SaaS subscription (you pay a recurring fee to use software hosted by a third party). These are typically expensed as incurred — they are service costs, not asset acquisition costs. You do not own the software or control it in the way the accounting standards require.
Amortisation: spreading the cost over useful life
Once development costs are capitalised as an intangible asset, they are not all charged to the P&L in the year they were incurred. Instead, they are amortised — spread — over the expected useful life of the software.
The useful life of business software is a judgement call. Ind AS 38 requires companies to assess whether the life is finite or indefinite. In practice, most business software has a finite useful life — it will be replaced, significantly upgraded, or become obsolete within some foreseeable horizon. Useful lives commonly used in practice range from 3 to 7 years, though your CA should assess the facts of your specific system.
The amortisation method should reflect how the economic benefits of the asset are consumed. Straight-line amortisation (equal annual charge) is most common and is acceptable where the pattern of benefits is not clearly different.
At each balance sheet date, the asset should be reviewed for impairment — if circumstances indicate the software may no longer generate the expected benefits (it has been abandoned, superseded, or is not performing as planned), an impairment loss may need to be recognised.
What you need to implement this correctly
Getting the accounting treatment right requires:
Cost tracking by phase. From the start of the project, time and expenditure should be tracked by activity and assigned to research or development phase. This is not onerous for a well-run project but is nearly impossible to reconstruct retrospectively.
Documentation of criteria. At the point when you begin capitalising, you should be able to produce a written document demonstrating that all six Ind AS 38 criteria are met. In practice, this might be a project approval document, a technical feasibility assessment, a funding plan, and a board or management resolution authorising the project.
Clear project scope. Capitalisation applies to the costs of developing a defined asset. If scope changes significantly mid-project, the question of whether you are still developing the same asset — or a different one — becomes relevant.
A CA who understands software projects. Many accountants are familiar with the general framework of AS 26 or Ind AS 38 but have not dealt with the specifics of software development accounting. Find one who has. The cost of getting this wrong — either by expensing costs that should be capitalised (understating assets, overstating expenses) or by capitalising costs that should be expensed (overstating assets, understating expenses) — is material.
The interaction with software ownership and commercial decisions
The accounting treatment of software costs connects directly to the commercial decisions described elsewhere in this cluster.
IP ownership matters for capitalisation. If you pay for software development but receive only a licence (not an assignment of copyright), you may not be able to capitalise the cost as an intangible asset that you own — because you do not control it in the way the standard requires. This is one more reason why the IP assignment clause in your development contract is commercially significant.
The build vs. buy decision has accounting implications. SaaS subscription costs are generally operating expenses. A capital purchase or a commissioned development that meets the capitalisation criteria becomes a balance sheet asset. Depending on your financial position and tax situation, one treatment may be preferable to the other — though tax and accounting advice should drive this decision, not accounting treatment preference alone.
Maintenance costs after launch are expensed. Routine maintenance, bug fixes, and minor updates to a capitalised software asset are expensed as incurred — they do not add to the carrying value of the asset. Significant enhancements or additions of new functionality may qualify as a new asset or a capital improvement to an existing one, if the criteria are met. The distinction between a routine update and a capital enhancement requires judgement and documentation. See our software maintenance cost guide for what ongoing costs typically look like.
| Cost type | Typical accounting treatment |
|---|---|
| Research phase (feasibility, evaluation) | Expense as incurred |
| Development phase (once criteria met) | Capitalise as intangible asset |
| Purchase of completed software (owned) | Capitalise at cost |
| SaaS subscription (no ownership) | Expense as incurred |
| Post-launch bug fixes and minor maintenance | Expense as incurred |
| Significant post-launch enhancements | Assess separately — may capitalise |
| Amortisation of capitalised software | Charge to P&L over useful life |
To summarise the practical implications: if you are commissioning or developing significant software for your business, speak to your CA at the planning stage — not after the invoice arrives. Setting up cost tracking by phase, documenting the feasibility criteria, and deciding the accounting treatment upfront is substantially easier and more accurate than trying to reconstruct it after the fact.
Planning a significant software investment? Talk to NexaEx about fixed-price engagements with full cost visibility from day one.
Frequently asked questions
When can an Indian company capitalise software development costs?
Under Ind AS 38 (or AS 26 for non-Ind AS companies), development-phase costs can be capitalised once six criteria are all met: technical feasibility, intention to complete, ability to use or sell, probable future economic benefits, adequate resources to complete, and reliable measurement of expenditure. Research-phase costs must always be expensed. The moment when the development phase begins and all six criteria are satisfied is a judgement that your CA should document at the time, not reconstruct afterwards.
What is the difference between expensing and capitalising software costs?
Expensing means the cost is charged to the profit and loss account in the period it is incurred, reducing reported profit immediately. Capitalising means the cost is recorded as an intangible asset on the balance sheet and amortised over the useful life of the software, typically three to seven years. This reduces the immediate P&L impact but creates an ongoing amortisation charge each year. The correct treatment is determined by the accounting standards and the facts of your project, not by which outcome is preferable.
Do SaaS subscription costs get capitalised?
Generally no. SaaS subscriptions are service costs — you are paying for access to software hosted by a third party, not acquiring an asset you own or control. Under Ind AS 38, an intangible asset must be identifiable and controlled by the entity. Because SaaS subscribers do not control the software in the required sense, subscription fees are typically expensed as operating costs in the period they are incurred. This is one reason the ownership question in your software agreements has accounting consequences.
Does IP ownership affect whether software can be capitalised on the balance sheet?
Yes, materially. To recognise software as an intangible asset, the accounting standards require that you control the asset, meaning you have the power to obtain the future economic benefits from it and can restrict others from access. If your development agreement gives you only a licence rather than an assignment of copyright, your ability to control the software in this sense may be limited. This is one of the accounting reasons why negotiating a full IP assignment in your development contract matters, not just legally but for balance sheet treatment.