Writing CapEx rationales (IFRS)

You classified the work correctly. The project was CapEx from day one — new capability, new platform, clear future economic benefit. Finance is happy. The auditors arrive. They ask: “Can you show us the rationale for capitalising this £1.2M of engineering effort?”

You open Jira. You gesture vaguely at a project board. You mention something about IAS 38. The auditor’s expression changes — because what they needed was a narrative, and what you have is ticket titles.

This play covers capitalisation under IFRS (IAS 38), which applies across the UK, EU, Australia, and 140+ countries. For US GAAP, see Writing CapEx rationales (US GAAP).

Classification gets you to the starting line. The rationale is what actually gets the cost on the balance sheet.

The job

Under IAS 38, capitalising development costs requires demonstrating that the work meets six recognition criteria. The standard says you must show:

Technical feasibility of completing the asset
Intention to complete and use or sell it
Ability to use or sell the resulting asset
How the asset will generate future economic benefit
Availability of resources to complete it
Ability to reliably measure the expenditure

Most engineering leaders have heard this list. Few have written documents that address each point convincingly. The gap between “we classify CapEx properly” and “we can defend it under audit” is where money gets left on the table — or worse, where previously capitalised costs get written off.

A CapEx rationale is the document that bridges that gap. It’s the evidence that turns a classification decision into a defensible financial position.

Why it matters

The numbers are material. A 200-person engineering organisation spending £20M annually might capitalise 40-60% of that. That’s £8-12M that hits the balance sheet instead of the P&L. The difference between a strong rationale and a weak one isn’t whether the work qualifies — it’s whether you can prove it does.

Audit exposure. Auditors don’t challenge classification at random. They challenge it when the documentation is thin. A well-written rationale gets a nod and a tick. A missing rationale gets a follow-up, then a meeting, then a potential write-down. Write-downs don’t just affect the current period — they signal to your auditor that future capitalisation decisions need extra scrutiny.

Board and investor confidence. For PE-backed companies, the capitalisation ratio is a metric that operating partners watch. A high CapEx percentage tells a story about investment in future value. But only if the rationale holds up. If auditors force a reclassification, the P&L takes a hit and the story unravels publicly.

Finance trust. Every time engineering produces a clean, well-evidenced rationale without being chased, the relationship between engineering and finance gets stronger. Every time finance has to reconstruct the narrative from scraps, it erodes.

What good looks like

Mature practice:

Every capitalised project has a written rationale authored at kickoff and updated at major milestones
Rationales directly address each IAS 38 recognition criterion
Engineering managers write them as part of project setup — it’s a ten-minute job, not a compliance exercise
Auditors review rationales and move on. No follow-up meetings. No extended testing.
The capitalisation decision is defensible twelve months later without anyone having to remember the context

Struggling practice:

Classification happens at quarter-end based on retrospective judgement
Rationales are written after the fact by finance, based on conversations with engineers who’ve moved on
Audit queries generate scrambles, late nights and uncertain outcomes
The organisation capitalises conservatively because nobody’s confident the rationale will hold up — leaving legitimate CapEx on the P&L

The approach

Step 1: Know what a rationale actually needs to say

Strip away the accounting jargon and a CapEx rationale answers six questions about a specific project:

Can we build this? Technical feasibility. You have the architecture, the skills, the infrastructure. This isn’t aspirational — you’ve validated the approach.
Will we finish it? Management intends to complete and deploy this. It’s not an experiment that might get shelved. It has executive sponsorship, allocated resources, and a delivery timeline.
Will it generate value? The asset will produce revenue, reduce costs, or enable a capability the business needs. Be specific — “improves checkout conversion by an estimated 8-12%” is strong. “Provides business value” is worthless.
Do we have the resources? The team is staffed. The budget is allocated. This isn’t contingent on a future hiring round or a budget approval that hasn’t happened yet.
Can we measure the spend? You can attribute costs to this project — salaries, contractor time, AI tooling, infrastructure — with reasonable accuracy. If your CapEx/OpEx tracking is in place, this is straightforward.
When did development start? Under IAS 38, only costs incurred after the point at which all recognition criteria are met can be capitalised. Research and early feasibility work stays on the P&L. The rationale needs to identify the moment development formally began.

Step 2: Write the rationale at project kickoff

The best time to write a CapEx rationale is when the project starts — when the technical approach is clear, the team is being assembled, and the business case is fresh. The document doesn’t need to be long. One to two pages. Here’s a structure that works:

Project name and identifier. Match it to whatever your project management system uses. Auditors will cross-reference.

Business context. Two to three sentences on why this project exists. What problem it solves, what opportunity it captures. This anchors the “future economic benefit” criterion.

Technical approach. A paragraph on how you’re building it. Not a design doc — a summary that demonstrates feasibility. “We’re extending the existing event pipeline with a new scoring service, deployed on our existing Kubernetes infrastructure” tells an auditor this isn’t speculative.

Recognition criteria. Address each of the six criteria explicitly. This is where most organisations fail — they write a project description and assume the criteria are implied. Don’t assume. State it directly: “Technical feasibility: validated through a proof-of-concept completed in Sprint 3. The architecture review board approved the approach on [date].”

Development start date. The date from which costs should be capitalised. Usually the point at which the project moves from feasibility/research into active development.

Estimated cost and duration. The planned investment. This doesn’t need to be exact — it’s a forecast — but it demonstrates that the expenditure is measurable.

Step 3: Update at milestones, not monthly

Unlike R&D documentation, CapEx rationales don’t need monthly updates. They need milestone updates:

If scope changes materially — update the rationale to reflect the new scope and confirm the recognition criteria still hold
If the project pivots — document why, and whether the pivot means a new asset or a continuation of the existing one
At go-live — confirm the asset is complete and in use. This is when amortisation begins
If the project is shelved or cancelled — document the decision. The capitalised costs may need to be impaired or written off, and a clean rationale makes that conversation with the auditors straightforward rather than adversarial

Step 4: Build a rationale library

After a few quarters, you’ll have rationales for a dozen projects. These become templates. New rationales get faster to write because you’re not starting from scratch — you’re adapting a proven structure. Engineering managers start to internalise what a good rationale looks like.

This library also becomes a powerful reference for finance. When the CFO needs to explain the capitalisation position to the board, the rationales are the source material. When auditors arrive, the library is the first thing you hand them.

The conversations

With your CFO

Trust-building: “Every capitalised project has a written rationale that maps to IAS 38 criteria. They’re authored at kickoff and updated at milestones. Here’s the library for this year — your auditors should be able to work through them independently.”

Trust-eroding: “Yeah, we capitalised about 50% of engineering this year. I can probably explain why if you give me a few days to go through the Jira boards.”

With your auditors

Trust-building: “Each project in scope has a rationale document that addresses the six recognition criteria individually. Development start dates are documented, scope changes are tracked, and expenditure attribution ties back to our workforce data. Let me walk you through the first one and you can take it from there.”

Trust-eroding: “We think most of this work was new development. Can I get back to you with more detail?”

With your engineering managers

Trust-building: “When you spin up a capitalised project, I need a one-page rationale. Six questions, honest answers. It takes ten minutes and it protects millions of pounds on the balance sheet. Here’s an example from last quarter.”

Trust-eroding: “Finance needs you to justify every project’s capitalisation. I know, I know. Just do it.”

Common failure modes

Writing rationales that describe the project but don’t address the criteria. A beautiful technical summary is not a CapEx rationale. Auditors are checking specific boxes. If your document doesn’t explicitly address feasibility, intention, benefit, resources, measurability, and timing, it’s a project description — and the auditor will ask for the rationale on top of it.

Backdating rationales. Writing the rationale six months after the project started, claiming it was “always the plan.” Auditors can tell. Timestamps matter. If you missed the kickoff, write it now, be honest about when it was written, and do better next time.

Conflating CapEx rationale with business case. A business case argues for whether to do the work. A CapEx rationale argues for how to account for the cost of work you’ve already decided to do. They’re related but not the same document. The business case might say “we should rebuild the payments platform.” The CapEx rationale says “here’s why the costs of rebuilding the payments platform meet the recognition criteria for capitalisation.”

Ignoring the development start date. This is the most common technical error. Under IAS 38, research costs can’t be capitalised — only development costs incurred after all recognition criteria are met. If your rationale doesn’t identify when development began, the auditor has to decide for themselves. They will be conservative.

Over-capitalising to improve the P&L. It’s tempting. A higher CapEx ratio makes the current period look better. But aggressive capitalisation creates future amortisation charges and audit risk. Capitalise what genuinely qualifies, write honest rationales, and let the numbers land where they land.

Getting started

This week: Pull up the list of projects your organisation capitalised last year. For each one, ask: does a written rationale exist? If the answer is no for most of them, that’s your starting point.

This month: Write rationales for every currently active capitalised project. Yes, they’re already in flight — that’s fine. Capture the current state. It’s better than nothing and it sets the standard going forward.

This quarter: Make rationale writing part of project kickoff. Add it to whatever checklist or template you use when a new project starts. Review the first few with your finance team to calibrate — they’ll tell you if the language needs adjusting for your specific audit context.

The CapEx/OpEx Discipline — Classification is the prerequisite. This play picks up where that one stops — turning a correct classification into a defensible financial position.
R&D Investment Documentation — The same project can generate both a CapEx rationale and R&D documentation. They serve different purposes but draw from the same source material.
Investment Framing — The business case that justified the project is an input to the CapEx rationale. If you framed the investment well, the rationale practically writes itself.