Development Effort and Capitalisation

Software development effort is frequently split between expensed and capitalised, and the split is made from time records that were not designed to support it.

General orientation, not accounting advice. Rules differ by framework and jurisdiction.

What the rules generally ask

Research is expensed. Investigating whether something is feasible.

Development may be capitalised once defined criteria are met — technical feasibility, intention and ability to complete, and probable future benefit, broadly speaking.

Maintenance and support are expensed.

Training and administration are expensed.

The boundaries are matters of judgement, and the auditor will ask how the judgement was applied.

The structural problem

Most category lists are organised by project, not by the nature of the work.

So at year end someone estimates the split from memory or from a proportion, and that estimate is what the accounts rest on.

An auditor asking how the split was derived receives an answer about a percentage applied across the board, which is weak.

The fix is in the category design, months earlier: the activity-type dimension needs to distinguish the qualifying work from the rest.

Designing for it

Activity types that map to the accounting boundary: investigation, build, fix, support, administration.

Not accounting language on the timesheet. People should record what they did in their own words; the mapping to the accounting category happens behind the form.

One mapping table, owned by finance, versioned, so the basis for a past period can be explained.

A date boundary per project for when capitalisation began, since work before the criteria were met is expensed regardless of its nature.

What goes wrong

A single project code with no activity split, so the whole question is answered by estimation.

People recording "development" for everything, including fixing last year's release.

The capitalisation start date not recorded, so the boundary is reconstructed.

Post-release work coded as build, which is the most common misclassification and the one auditors look for.

A mapping changed without versioning, so prior periods cannot be reproduced.

The honest caution

Time records are self-reported and the split has a financial consequence, which is a combination that invites optimism.

Do not attach any incentive to the capitalised proportion, at any level. If teams learn that build time is preferred, the records will show more of it.

Sample and test: take a set of entries coded as qualifying and check them against what was actually delivered.

Report the split with its basis, including the proportion derived from direct records against the proportion estimated.

What to report

Effort by activity type per project, which is the evidence.

Proportion of the split derived directly against estimated.

Capitalisation start dates, recorded rather than inferred.

The mapping version in force for the period.

Sample test results, which is what turns the figure from an assertion into something an auditor can rely on.

Sampling the split

The test that turns a capitalisation figure into something an auditor can rely on.

Take entries coded as qualifying development.

Check them against what was actually delivered in that period.

Look for post-release fixing coded as build, which is the most common misclassification.

Report the proportion of the split derived from direct records against the proportion estimated.

Attach no incentive to the capitalised proportion, at any level, or the records will show more of it within a quarter.

Recording the start date

A detail that is trivial to capture and impossible to reconstruct.

Capitalisation begins when defined criteria are met, and work before that point is expensed regardless of its nature.

Record the date per project, at the time, with who decided and on what basis.

Not inferred at year end from when the project code was created.

An auditor asks for this, and an answer involving a reconstruction from memory is the weakest available.

One field, one decision, recorded once.

A concrete product reference

When translating this principle into a buying test, the software-team use case provides a concrete feature and workflow reference. Verify the relevant behaviour in a trial, retain the exported evidence and judge it against the purpose and limits described above.