Every year-end, the same conversation happens in finance teams across IFRS jurisdictions. The company has spent meaningfully on software development, data infrastructure, or process design. Someone asks whether any of it can be capitalised. The accountant points to IAS 38 and its recognition criteria. And the conversation stalls — not because the criteria cannot be met, but because nobody can produce the evidence that they have been. The spend is real, the asset is real, and the documentation does not exist.
This is the quiet failure mode of intangible asset accounting. IAS 38 is not the obstacle most finance teams believe it to be; it is a standard with clear tests, and businesses pass those tests far more often than their balance sheets suggest. What they fail is the paperwork. Capitalisation, amortisation, impairment review, and disclosure all depend on records that most companies never kept — what was built, when, at what cost, with what expected benefit, and on what assumptions. Opagio Intangibles addresses exactly that gap: it turns the intangible asset work a business does anyway into structured documentation that an accountant can take into an audit.
IAS 38 sets out three recognition hurdles for any intangible asset: it must be identifiable (separable from the business, or arising from contractual or legal rights), the entity must control it, and it must be expected to generate future economic benefits. For assets a company develops itself, the standard adds a stricter gate. Research-phase spend is always expensed. Development-phase spend can be capitalised only when all six of the criteria in IAS 38.57 are demonstrated: technical feasibility, intention to complete, ability to use or sell the asset, probable future economic benefit, availability of resources to complete it, and the ability to measure the development cost reliably.
Note the verb. The criteria must be demonstrated, not merely satisfied. An auditor does not take management's word that technical feasibility was established in March; they ask what evidence shows it. That distinction — between meeting a test and proving you met it — is where most capitalisation cases collapse.
IAS 38 rarely fails companies on substance. It fails them on evidence. The six development criteria are demonstrable for a large share of genuine product and process investment — but only if the demonstration was recorded at the time, not reconstructed at year-end.
The standard's demands continue after recognition. A capitalised asset needs a useful life estimate with a documented basis, an amortisation method, an annual impairment trigger review, and disclosure of the carrying amounts, movements, and assumptions in the notes. Each is a recurring documentation obligation, and each is routinely handled in a spreadsheet that one person understands and nobody reviews.
The problem is not unique to full IFRS reporters, though the rules differ in detail by regime. The table below summarises where the requirement bites. Treatment depends on the entity's reporting framework, so the first step in any capitalisation conversation is confirming which column applies.
| Regime | Standard | Internally generated intangibles | Practical effect |
|---|---|---|---|
| IFRS (UK listed, EU, AU, CA public) | IAS 38 | Development costs capitalised when all six IAS 38.57 criteria are demonstrated | Evidence-heavy; capitalisation available but under-used |
| UK GAAP (most UK SMEs) | FRS 102 Section 18 | Accounting policy choice — expense, or capitalise development costs meeting equivalent criteria | Many eligible SMEs default to expensing for lack of records |
| US GAAP | ASC 350 / ASC 730 | R&D expensed; main exception is internal-use and to-be-sold software | Narrower gate; documentation still decisive where it applies |
Across all three regimes the pattern repeats: where capitalisation is permitted, it is documentation that determines whether it is achievable. And the consequences of defaulting to expensing are not cosmetic. A business that has invested £2m in proprietary software over four years and expensed all of it shows weaker historical EBIT in those years, no corresponding asset, and — when a lender, investor, or acquirer reads the accounts — no visible trace that the investment happened. The balance sheet understates the business precisely where its value is concentrated, a gap explored in our complete guide to IAS 38.
Opagio was not built as an accounting tool, and it does not produce journal entries. What it produces is the layer underneath the accounting: a structured, dated record of what intangible assets exist, what they cost, what they are worth, and on what assumptions — organised so an accountant can map it onto the recognition and disclosure requirements of whichever standard applies. The work runs through four stages.
Guided asset discovery walks the business through The Opagio 12 taxonomy — technology, data, customer capital, process capital, and the other drivers — and captures every identifiable intangible asset into the Opagio Value Drivers Register™, the formal, auditable output of the discovery process. Each entry records what the asset is, which driver it belongs to, when it was created or acquired, and what evidences the company's control over it. That last field matters more than it looks: control is a recognition criterion in its own right, and "where is the contract, assignment, or policy that shows we own this?" is an audit question the register is designed to answer on day one.
With the register populated, each asset is screened against the structure of the recognition tests: identifiability, control, expected benefit — and for internally developed assets, the six development-phase criteria. The platform's questionnaire captures the supporting facts asset by asset: when technical feasibility was reached and what demonstrated it, what resources were committed, how the expected benefit was assessed. The output is not an accounting opinion. It is a screening file that shows, for every asset, which criteria look demonstrable, which look weak, and what evidence exists for each — exactly the brief an accountant needs to make the actual judgement efficiently.
The platform is precise about its role. It structures the facts and the evidence; the recognition decision, the accounting policy, and the financial statements belong to the company's accountant and auditor. Opagio's output is decision-support and documentation — it does not replace professional accounting advice, and it is not an audit opinion.
Assets that pass screening need reliable measurement, and assets that will never be capitalised still need values for the conversations that surround the accounts — lending, investment, exit. The platform's valuation engine applies named methods to each asset class: Relief from Royalty for brands and licensable technology, MPEEM for customer relationships, the cost approach for assembled workforce, internally developed software, and databases. Every valuation stores its inputs — royalty rates, discount rates, attrition, cost components — against the asset, dated. When an auditor asks "where did this number come from?", the answer is a recorded method and a recorded assumption set, not an archaeology project through a departed analyst's spreadsheet.
Everything in the first three stages accumulates into the register's history. Valuations are versioned, so the carrying-amount movements that IAS 38 requires in the notes have a source. Assumption changes are dated, so an impairment review can compare this year's basis against last year's. And because the same structure repeats every reporting cycle, the second year of compliance documentation costs a fraction of the first — the register rolls forward; only the changes need work.
A UK software business preparing for its first audited accounts under FRS 102 had expensed every pound of development since incorporation. Working through the register, the finance team and their accountant identified £1.4m of development spend over three years attributable to two platform modules, with feasibility milestones, committed resources, and revenue evidence captured asset by asset in the screening file. Their accountant concluded the criteria were demonstrable for roughly £900k of it from the date feasibility was evidenced. The directors adopted a capitalisation policy, the auditor's questions were answered from the register rather than from memory, and the balance sheet finally showed a technology asset where the company's value actually sat — a position that materially changed the tenor of the lending conversation that followed, as discussed in our guide to R&D capitalisation under IFRS.
Accountants and advisory practitioners use the platform across a client portfolio. For a practice, the register turns "should we be capitalising development costs?" — a question most SME clients have never been asked — into a structured, repeatable advisory service with the evidence-gathering already systematised. The practitioner makes the accounting judgement; the platform makes the judgement cheap to reach and easy to defend.
CFOs and finance teams use it to stop losing the documentation battle at year-end. The register is maintained as the work happens — when a module ships, when a dataset reaches production, when a process is documented — so the audit file builds itself during the year instead of being reconstructed in the two weeks before fieldwork.
Founders preparing for diligence or exit use it because the same file serves twice. The documentation that supports recognition under IAS 38 is substantially the documentation a buyer's diligence team requests when assessing what they are paying for — and in an acquisition it feeds directly into the purchase price allocation, where every separately identifiable intangible must be valued anyway. Companies that arrive with a maintained register walk into that process with the work already done.
The compliance file is not a cost of doing business — it is reusable capital. The same structured record serves the auditor at year-end, the lender at facility review, and the acquirer at diligence. Build it once, in the platform, and every downstream conversation starts from evidence instead of assertion.
It is easy to read IAS 38 as a constraint — a standard that makes companies prove things before letting them recognise what they already know is valuable. The more useful reading is the opposite. The standard's evidence requirements are a forcing function for exactly the discipline that intangible-heavy businesses need anyway: knowing what assets exist, what they cost, what they are worth, and how those answers change over time. Companies that build that discipline get the accounting benefit, but they also get the lending conversation, the diligence readiness, and the board-level visibility that come with it.
The platform's contribution is to make the discipline affordable. What was previously a bespoke documentation project — expensive enough that most SMEs simply defaulted to expensing — becomes a maintained register with screening, valuation, and history built in.
If you are starting from nothing, the fastest route into the workflow is the Intangibles Questionnaire, which builds the first asset profile, followed by the Intangible Asset Valuator walkthrough to put method-graded values against the assets you find. If you already hold a Value Drivers Register on the platform, the recognition screening layer is the natural next step before your next reporting cycle.
For accounting practices that want to run the workflow across a client base, the team runs working sessions that configure the register for your clients' sectors and reporting frameworks and leave you with a repeatable capitalisation-review service you can take to every engagement.
Estimate the value of your intangible assets using industry-standard methods like Relief from Royalty, MPEEM, and With & Without.
IAS 38 sets six criteria for capitalising development costs, but applying them to AI projects is fraught with ambiguity. This article maps each criterion to AI development realities and provides practical guidance for CFOs and accountants navigating the recognition question.
Read more →
At Capital.com, half the organisation was technology and the operational team was small. That operating model isn't fintech-specific — it's the template for any business where work can be turned into code. What it actually requires is a full redesign, not a workforce cut.
Read more →
A step-by-step guide to the Cost approach to intangible asset valuation — the method used to value assembled workforce, internally developed software, and proprietary databases. Learn the difference between replacement and reproduction cost, the role of obsolescence and developer's profit, and how the Asset Valuator module in Opagio Intangibles runs a defensible Cost valuation.
Read more →Get the latest insights on intangible asset growth and productivity delivered to your inbox.
Book a free consultation to see how Opagio Intangibles can help your business.