Software Development Costs: Build Evidence Before Capitalizing

Writing software does not automatically create a capitalizable asset. Before considering capitalization, establish what the project is, which stage it has reached, which costs belong to it and whether the applicable recognition criteria are supported. A label such as “product development” in a timesheet is not enough by itself.

The IFRS Foundation’s IAS 38 summary distinguishes research expenditure, recognized as expense, from development expenditure meeting specified criteria. This guide focuses on the evidence workflow for an IFRS-oriented review. It is not an accounting conclusion for a particular project or guidance for every reporting framework.

Define the asset or project being assessed

Describe the intended software capability and the entity’s rights or control in terms finance can evaluate. A broad department budget may contain several projects, routine maintenance and unrelated operational work.

Separate internally developed software from purchased licenses, hosted services and customization arrangements that may require different analysis. Do not assume paying engineers rather than a vendor decides the accounting treatment.

Record the project boundary before allocating costs. If the scope changes materially, preserve the earlier definition and explain the change rather than rewriting the history to make every expense appear part of a successful asset.

Keep research uncertainty visible

Early work can involve exploring whether an approach is feasible, comparing architectures or investigating an unresolved technical problem. That work may be valuable even when it does not qualify for recognition as an asset.

Maintain a timeline of what was known and approved at the time. A later successful launch does not prove the same evidence existed during an earlier uncertain phase.

Avoid treating capitalization as a reward for useful engineering or expensing as evidence of failure. The accounting question concerns recognition criteria and cost attribution, not whether the team worked hard or learned something important.

Assemble a contemporaneous decision file

Finance may need evidence about feasibility, intended completion and use, expected benefits, available resources and reliable measurement, alongside other requirements in the applicable standard. Have qualified professionals evaluate the complete criteria.

Useful project records can include approved scope, technical review, delivery plan, budget authorization, ownership of rights and the proposed benefit mechanism. An optimistic presentation is not a substitute for the underlying facts.

Date the review and identify the point from which the conclusion is considered supported. Do not silently backdate eligibility because the accounting result is more convenient.

Track costs at a defensible grain

Use project and activity identifiers that distinguish assessed development from support, research, training and maintenance. Keep source payroll, contractor invoices and allocation methods traceable.

For an invented month, suppose a team records 400 hours: 240 on the assessed development work, 100 on maintenance and 60 on exploratory research. That split is an input to review, not automatic permission to capitalize 60% of all payroll and overhead.

The actual eligible cost base, allocation method and recognition date need professional assessment. Keep assumptions visible and avoid changing activity labels after seeing the desired profit result.

Distinguish maintenance from enhancement

Bug fixes, compatibility work and new functionality can overlap in one release. A release number or a feature flag does not decide whether every associated cost meets the relevant criteria.

Break substantial mixed work into understandable activities where practical. If a contractor invoice covers hosting support and a new module, obtain a reliable breakdown rather than assigning the whole invoice to whichever category is most favorable.

Do not manufacture precision. A detailed-looking allocation unsupported by actual records can be weaker than an honest explanation of missing evidence and the conservative treatment chosen by the responsible professionals.

Reconcile the asset’s later lifecycle

Recognition is not the end of the process. Finance needs to consider when the software is available for its intended use, useful life, amortization and impairment under the applicable rules.

Keep the engineering release record connected to the accounting record without equating a code merge with operational readiness. A merged module may still lack data migration, security review or the integration necessary for intended use.

If a project is paused, replaced or becomes obsolete, escalate the evidence promptly. Do not continue carrying a historical plan as though the original expected benefits remain unchanged.

Build a monthly reconciliation

Reconcile source costs, reviewed eligible additions, excluded activities and any later adjustments. Preserve a clear link from each material amount to the project, period and approved decision.

Have engineering confirm the factual activity description and finance own the accounting conclusion. This division avoids asking engineers to infer accounting rules from ticket labels or asking finance to guess technical feasibility from payroll totals.

For management reporting, show cash spending separately from accounting presentation. Capitalizing an eligible cost does not mean the cash was never spent or that the project has already generated revenue.

Conclusion

Build the project timeline and cost trail before considering capitalization. Distinguish research, assessed development and maintenance, use contemporaneous evidence and obtain a qualified conclusion under the reporting framework that actually applies.