Hours on the Balance Sheet

Where software or product development is capitalised, the asset's value is largely staff cost, and staff cost comes from timesheets. Where a jurisdiction offers relief for qualifying research or development, the claim's largest line is usually the same.

The record described in “Hours on the Balance Sheet” should be created close enough to the work that people are not reconstructing a polished week from memory. When teams assess this workforce platform for hourly timesheet template, they should keep entry, project selection and correction simple, while explaining which optional activity data is collected and how employees can review it.

Both depend on a distinction — between work that qualifies and work that does not — which is made in accounting or tax terms and recorded, if at all, by engineers choosing a code on a Friday.

For a separate benchmark relevant to “Hours on the Balance Sheet”, consult the FASB accounting standards. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

The distinction the standards require

Capitalisation typically requires that the project is past a feasibility threshold, that the entity intends and is able to complete it, and that the expenditure is directly attributable to creating the asset. Research is expensed; development after the threshold may be capitalised.

In practice this means some hours on a project qualify and others do not, and the boundary runs through a single person's week. Investigating whether an approach will work is one side; building the approach once chosen is the other. Maintenance, bug fixing on released software, general improvement and support are usually the wrong side.

Relief regimes apply their own test — commonly an advance in a field and an uncertainty that a competent professional could not readily resolve — which is a different boundary again, drawn through the same week.

What goes wrong

The blanket percentage. A team recorded at a fixed capitalised proportion every month for a year, set once by somebody senior. It is the most common pattern and the first thing an auditor asks about, because real development work does not maintain a constant ratio across a release cycle.

Codes that do not carry the distinction. If the code list has one entry per project, nothing in the record says which hours were which, and the split is produced afterwards by estimate.

Engineers deciding an accounting question. A developer choosing between two codes is making a capitalisation judgement, usually without having been told what the criteria are. They will choose consistently and possibly wrongly.

Post-release work absorbed into the project code. The project continues, the code stays open, and maintenance accumulates on the asset.

Building the distinction into the codes

Give each project at least two codes reflecting the boundary, named in terms the engineers understand rather than in accounting language. "Build" and "investigate" works; "capitalisable" and "non-capitalisable" does not, because it asks them to make the judgement.

Write a short guide with examples from the team's own work — this ticket is build, that one is maintenance — and keep it where the codes are chosen. Half a page, with five real examples, outperforms any amount of policy text.

And close project codes at release, opening a separate maintenance code. Nothing else prevents the slow drift of support hours onto the asset.

The reviews worth having

Monthly, as part of close: the capitalised proportion by project, with a look at any that has not moved. Movement is the normal state; stability is the thing to question.

At release: confirm the code closed and the maintenance code opened.

Annually, before the audit: sample the hours on both sides of the boundary and check the narratives support the classification. This is the same exercise an auditor will perform and it is far better run internally first.

The point about who decides

The accounting judgement belongs to finance, the knowledge of the work belongs to engineering, and the record is created by neither acting alone.

The arrangement that works is finance setting the criteria and the code structure, engineering applying it at the point of recording, and a joint review at the boundary cases. Where finance derives the split from the records afterwards with no engineering input, the number is an estimate presented as a measurement, and it will be treated as one when it is examined.

When the same hours do both

A development project that is both capitalised and the subject of a relief claim has two different tests applied to the same week, and the two boundaries are not the same. Work can qualify for relief and not be capitalisable, or the reverse.

Trying to serve both with one split produces a number that is wrong for at least one of them. Where both apply, the codes need to carry enough detail for each test to be applied separately afterwards, which usually means a second dimension rather than more codes on the first. It is worth designing before the first claim rather than reverse-engineering at the second.