Your software company has spent months building a new product. Developers are writing code, the product team is testing features, and management expects the platform to generate subscription income for years. When finance prepares the accounts, a question arises: should the development spending reduce this year’s profit, or appear on the balance sheet as an asset?
The commercial argument may seem straightforward. The company is creating something valuable, so recording every dollar as an expense can feel inconsistent with the investment being made. However, expected future value alone does not establish that the expenditure qualifies for capitalisation.
For software businesses preparing for Audit Services, the answer depends on the applicable accounting framework, the nature of the project, and the evidence available at each stage. The assessment requires more than identifying developer invoices or describing the work as product development.
Confirm Which Accounting Requirements Apply
Start by confirming the financial reporting framework used by your company. This article focuses on the development-cost principles in IAS 38 and the corresponding full Singapore standards, FRS 38 and SFRS(I) 1-38. Other frameworks can have different requirements.
Also establish what the company is creating. Developing a product that the business controls is different from purchasing access to another provider’s software or delivering a bespoke application that belongs to a customer. Those arrangements require their own assessment.
For example, a company building its own subscription platform should not automatically apply the same treatment to all work performed by its development team. Customer implementation, internal tools, maintenance, and product development may involve different activities and accounting considerations.
Define the Product or Asset Being Developed
A broad description such as “technology investment” is difficult to assess. Management should identify the software, functionality, or project that the expenditure relates to and explain how the company expects to use or sell it.
Describe the intended users, commercial purpose, development plan, and rights held by the company. Where external developers are involved, review the agreement covering ownership, licences, and access to the resulting work.
This becomes particularly important when a project uses third-party components or shared technology. Paying for code does not, by itself, establish that the company controls all the rights needed to benefit from it. Clarify significant contractual questions before relying on an assumed asset in the accounts.
Separate Research From Development
Under the full standards discussed here, research expenditure is expensed. Development expenditure is capitalised only when the recognition requirements are met. If the research and development phases cannot be distinguished, the expenditure is treated as research.
Exploring alternative technical approaches, investigating feasibility, and testing whether an idea can work may differ from building a defined product after the relevant requirements have been demonstrated. The distinction depends on the activities and evidence, not simply the team’s job titles.
A functioning prototype can be useful evidence, but it does not automatically establish that every recognition condition has been satisfied. Equally, an internal project label such as “development phase” needs support from the facts. Finance and engineering should agree on what has actually been established.
Understand the Conditions for Capitalisation
For qualifying development expenditure, management must demonstrate all six conditions: technical feasibility of completion; intention to complete and use or sell the asset; ability to use or sell it; probable future economic benefits; adequate technical, financial, and other resources; and reliable measurement of attributable expenditure.
These requirements work together. A technically feasible product may still lack a credible route to market or sufficient funding to complete it. A promising market opportunity may exist while important technical uncertainty remains unresolved.
Prepare an assessment addressing each condition with evidence. Avoid using the existence of a budget or a management decision to proceed as a substitute for the full analysis. The conclusion should explain why the project meets the requirements at the date capitalisation begins.
Make the Commercial Case Specific
Management’s expectation of future benefits should be supported by more than an ambitious revenue target. Explain who will use the product, what problem it solves, and how the company expects to generate value from it.
Depending on the circumstances, relevant evidence could include customer research, pilot feedback, contractual discussions, a supported market assessment, or a credible plan for internal cost savings. Distinguish confirmed information from assumptions and explain significant uncertainty.
For example, a forecast assuming rapid subscription growth should identify the expected customer base, acquisition approach, and costs of providing the service. The objective is not to eliminate business risk. It is to support the recognition assessment with a reasoned explanation that another person can evaluate.
Identify When the Requirements Were First Met
The start date matters because a successful project does not automatically turn all earlier spending into an asset. Capitalisation begins when the relevant recognition requirements are first satisfied. Expenditure properly recognised as an expense beforehand is not subsequently reinstated merely because the project becomes successful.
Consider a simplified hypothetical project with S$240,000 of expenditure. Assume S$90,000 was incurred before all conditions were demonstrably met. A further S$150,000 was incurred afterwards, of which S$120,000 qualifies as directly attributable development cost and S$30,000 relates to activities that do not qualify.
On those assumptions, S$120,000 would be capitalised and S$120,000 expensed. The example excludes tax, amortisation, and impairment. The decisive point is the supported recognition date and nature of the costs, rather than the project’s total budget.
Keep Evidence of Decisions as They Happen
It is easier to support the capitalisation date when the company records milestones during the project. Trying to reconstruct the position at year-end can leave management relying on memories and documents prepared after the event.
Retain technical assessments, approved plans, funding information, commercial evaluations, and relevant meeting records. Explain what changed when the project moved from an uncertain concept to a stage that satisfied the accounting requirements.
A dated assessment does not need to become an excessive administrative exercise. It should connect the decision to the evidence available at the time. If an important condition remained unresolved, record that fact and the later development that addressed it.
Do Not Capitalise the Entire Technology Payroll Automatically
A developer may spend time on several activities within the same month. Product construction, exploratory work, customer support, maintenance, and internal administration should not all be assigned to the asset simply because the employee belongs to engineering.
Use a practical method for identifying relevant time and costs. Project records, task classifications, approved time allocations, and payroll reconciliation can help finance understand which expenditure belongs to the qualifying work.
For instance, an engineer might spend part of the month building a qualifying module and the remainder resolving support tickets for an existing product. A blanket allocation of the employee’s salary to the new asset would ignore that difference. Review allocations regularly as the work changes.
Examine External Invoices and Shared Costs
Supplier invoices can be too general to support the accounting treatment on their own. A monthly invoice labelled “software development services” may cover several projects or a mixture of development and operational support.
Connect invoices to the scope of work, deliverables, and project period. Where the supplier provides several services, obtain enough detail to identify the relevant expenditure rather than assigning the full amount to one asset.
Shared costs require similar care. A development tool or hosting environment may support both qualifying construction and other activities. Use a supportable allocation where appropriate, and check it against actual use. Avoid selecting a percentage solely because it produces the desired capitalised amount.
Distinguish Building the Product From Launching the Business
Product expenditure can sit alongside sales recruitment, advertising, customer training, and other launch activities. Their commercial importance does not mean they belong in the software asset.
Keep separate budgets and account codes for development, launch, and ongoing operations. The accounting assessment should follow the nature of each cost, even where management approves them within one overall investment plan.
For example, a product demonstration campaign may be essential to attracting early customers, but it is different from the technical work required to prepare the software for use. Clear records help finance apply the relevant treatment without treating the entire launch budget as one accounting category.
Account for Agile Development Without Losing the Evidence
Software teams often build, test, release, and revise in overlapping cycles. That workflow can make a single project-wide description too broad to explain the expenditure accurately.
Agree on a sensible level of tracking between finance and product management. Significant modules or workstreams may need separate consideration where their purpose, stage, and supporting evidence differ. Do not assume every sprint qualifies because the overall product is already in development.
An individual sprint might contain an enhancement, exploratory testing, and maintenance of existing functionality. The review should reflect those activities. Tracking should be detailed enough to support the accounting without forcing engineers to describe every minor task in financial terminology.
Identify When the Asset Is Available for Use
For a finite-life intangible asset, amortisation begins when it is available for its intended use. This may not be the same date as a public launch announcement, the first customer payment, or the point when management achieves its sales target.
Document the relevant readiness assessment. Record what the software can do, whether it is capable of operating as intended, and whether any outstanding work prevents that use or relates to later enhancements.
A product can be available for use while further improvements continue. Conversely, a demonstration version may still lack essential functionality. Finance needs a clear explanation from the technical team rather than relying on the marketing calendar to determine the accounting date.
Reassess the Asset When Expectations Change
Capitalisation does not establish that the recorded amount will remain recoverable indefinitely. A cancelled launch, major technical setback, lost customer opportunity, or weaker commercial outlook may require further assessment.
Under the full impairment framework, intangible assets not yet available for use are tested for impairment annually, as well as when relevant indicators arise. Once available for use, finite-life assets remain subject to impairment review when indicators exist.
Update forecasts and explain significant changes from the original plan. Where the product does not generate independent cash flows, the assessment may need to consider the appropriate wider group of assets. An impairment conclusion requires analysis, rather than assuming either that all delayed projects are worthless or that sunk expenditure will eventually be recovered.
Understand What Capitalisation Does to the Numbers
Capitalisation changes when expenditure affects reported profit. It does not recover the cash paid to developers or demonstrate that the product has become commercially successful.
Management should review cash spending alongside the capitalised balance, amortisation, impairment, and ongoing operating costs. A company may report lower current expenses while still consuming substantial funds to complete and support the product.
Keep investor and internal reporting clear about these distinctions. If management presents a measure that excludes certain costs, explain how it relates to the financial statements. A stronger-looking profit figure should not obscure funding needs or the uncertainty of future customer income.
Prepare a Clear File for the Audit
An audit review may require the project definition, recognition assessment, supporting milestones, cost schedules, relevant contracts, and reconciliation to the general ledger. The audit team may also ask about readiness for use, useful life, forecasts, and impairment.
Prepare a concise explanation of the significant judgements rather than providing only a large folder of invoices. Show how the records support the capitalisation date and why the included costs qualify.
Management is responsible for the accounting assessment and financial statements. The auditor independently evaluates the evidence; the audit does not guarantee that the product will succeed. Discussing significant judgements early can help identify missing information before the reporting deadline.
Discuss Your Software Development Accounting With Kazuma
Kazuma Public Accounting Corporation provides statutory and financial statement audits, as well as group and parent-company reporting-related audit work. Software development expenditure can be an important area to explain when planning those engagements.
Bring the project plan, development records, expenditure analysis, and management’s assessment to the discussion. If the company reports to an overseas parent, identify the applicable reporting requirements and any differences that need consideration rather than assuming the group’s existing treatment automatically applies locally.
For software businesses engaging Audit Services, the expense-or-asset question is ultimately an evidence question. Define what is being built, establish when the recognition requirements are met, and track the relevant costs from that point. This gives the accounting a defensible basis while helping management see both the investment being made and the obligations that remain.