Not Every Asset Belongs on the Balance Sheet

One of the least glamorous jobs in a technical project is making the work understandable after the exciting part is over.

In the last few weeks, I have been preparing VEAI LAB projects for public review: rewriting READMEs, documenting architecture, correcting tests that no longer matched the real code, keeping non-anonymised care material out of public repositories, and recording what works, what is still in progress, and what should not be used as a production service.

None of that looks like a balance-sheet asset at first glance. It does not automatically become a capitalised intangible asset. But it changes what a team, client, or future maintainer can do with the work. It turns a one-off implementation into something that can be inspected, operated, improved, and trusted.

That is why I think ITIL, PMI, and accounting are useful together — provided we do not confuse their different meanings of “asset.”

The same word asks three different questions

In accounting, an asset is recognised only when it meets formal recognition and measurement rules. The boundary is deliberately narrower than “anything valuable to the business.” Under IAS 38 Intangible Assets, internally generated brands, publishing titles, customer lists, and similar items are not recognised as intangible assets. Research expenditure is expensed; development expenditure is capitalised only when specific criteria are met.

In ITIL, asset management is operational. The ITIL 4 Practitioner: IT Asset Management guidance is about managing the lifecycle of IT assets to maximise value, control cost, manage risk, and support decisions about acquisition, reuse, retirement, and disposal.

In PMI language, the related idea is often organisational process assets: the templates, knowledge, practices, and historical information that help a project perform or be governed. PMBOK 7 uses a broader project-environment framing, but the practical lesson remains: an organisation should not pay to learn the same lesson twice.

So the questions differ:

• Accounting: can this be recognised and measured under reporting rules?
• ITIL: does this asset help deliver and support a service at an acceptable cost and risk?
• PMI: will this knowledge or artefact help the next project make better decisions?

All three matter. None can stand in for the others.

A public repository is an operating asset, not just a portfolio page

ParkinSync is a useful example. It is a serverless pipeline that processes structured paper-care observations, combines them with environmental data, and prepares a dataset for exploration. Making it public was not a matter of uploading every file.

The repository needed a clear architecture description, a reproducible local-development path, tests, deployment guidance, explicit privacy boundaries, and a statement that the OCR step is human-verified rather than automatically trusted. Non-anonymised source documents were deliberately excluded; CI guards against common secret patterns and known private-document names.

That work creates value in several directions:

• a reviewer can assess the architecture without receiving sensitive data;
• a future contributor can understand what the pipeline is and is not designed to do;
• a client can see the distinction between an implemented component and an unsupported promise;
• I can revisit the project without reconstructing every decision from memory.

The README is not a balance-sheet line. It is still an asset in the ITIL and PMI senses because it reduces operational and delivery risk.

Assets create value only when their lifecycle is managed

ITIL’s asset lens is especially helpful here. Owning a repository, a cloud account, a domain, a CI workflow, a monitoring tool, or a SaaS licence does not create value by itself. Each has an owner, dependencies, a cost, a risk profile, and an eventual retirement decision.

The hard part is often the small, neglected asset:

• an old deployment credential copied into CI;
• a domain record nobody remembers changing;
• a test suite that verifies an earlier version of the interface;
• a source document that should never become public;
• an unused subscription or cloud resource;
• a support instruction that exists only in one person’s memory.

I encountered two versions of this in recent work. On ParkinSync, a test suite and a Lambda packaging configuration needed to be brought back into alignment with the handler that actually ran. On a Shopify-to-CloudFront migration, certificate validation and GitHub OIDC assumptions needed investigation rather than a blind rerun. In both cases, the asset was not only the code or cloud service. It was the accurate, current knowledge required to operate it safely.

IT asset management asks us to keep that lifecycle visible: what exists, what depends on it, who owns it, what risk it carries, and whether it should be renewed, changed, reused, or retired.

Project assets are the memory left after the project

When a project ends, the product is not the only thing it has made. It can leave behind an operating memory:

• acceptance-criteria patterns;
• architecture diagrams;
• risk and decision records;
• deployment checklists;
• incident or failure notes;
• test cases that describe real behaviour;
• a visible issue history connecting plan, work, review, and completion.

I use GitHub deliberately for this reason. In Social OS Debugger, user stories, milestones, labels, and issue-closing commits make the delivery trail available to a collaborator or client. AI-assisted tasks are labelled and reviewed by a human before they are accepted. The aim is not process theatre. It is to make the origin and verification of a change inspectable.

That matters more in a small team, not less. Without an intentional memory system, the project knowledge becomes one person’s temporary recall. The apparent efficiency is borrowed from the future, when someone has to rediscover the reason for a decision or recreate a missing operational step.

Do not mistake business value for accounting recognition

The Japanese note that prompted this article was right that knowledge, process maturity, stakeholder trust, and reusable delivery practices matter. The correction is that they do not simply appear on a balance sheet as intangible assets.

That is not an argument for ignoring them. It is an argument for managing them with the evidence that fits them.

A deployment runbook might be evaluated through reduced recovery time. A reusable template might be evaluated through less rework. A careful public README might be evaluated through the quality of a technical review or client conversation it enables. A retained decision record might matter when a supplier changes or a team member leaves. These are real effects even when accounting rules require the cost to be expensed.

What I want an IT project to leave behind

For every technical project, I now look for three outputs:

1. A working product or service — the visible outcome.
2. A better operating system — clearer delivery, support, security, monitoring, documentation, or ownership.
3. Reusable organisational memory — evidence and learning that reduce the cost and risk of the next project.

A strong balance sheet gives an organisation resilience and room to invest. But technical sustainability also depends on whether the organisation can preserve and improve its invisible assets: trustworthy documentation, safe deployment paths, clear ownership, learned judgment, and the habit of turning failures into better controls.

That is the asset practice I am building at VEAI LAB. The public repositories are part of the evidence — ParkinSync, CareReady, and Social OS Debugger — alongside a concise client-work profile at hire-veai.com.