Who it's for: accountants and controllers in SaaS companies deciding which engineering costs go on the balance sheet, and the finance assistants who prepare the monthly numbers.
What you'll get: the rules under IAS 38, FRS 102 and US GAAP in plain English, a monthly capitalisation process, a worked example from timesheets to amortisation, and a one-slide summary to take to your boss.
Reading time: about 12 minutes. Engineering may want to read it too, which is a first.
Why it matters
For most SaaS companies, engineering is the biggest cost line. Whether some of it is capitalised changes EBITDA, the balance sheet and sometimes covenant tests. Capitalise too much and profit is flattered; capitalise inconsistently and nobody trusts the numbers. Auditors look hard at this area, so the evidence matters as much as the answer.
Key terms
- Research: work to gain new knowledge, with no certainty it'll lead to a product. Always expensed.
- Development: applying knowledge to build a new or substantially improved product or feature. Can be capitalised if the criteria are met.
- Intangible asset: an asset without physical form, such as capitalised software, shown on the balance sheet.
- Technical feasibility: the point where the team is confident it can build the thing and make it work.
- Directly attributable costs: costs that go straight into building the asset, mainly engineers' pay, employer National Insurance and pension for time spent on the project, and some contractor costs.
- Amortisation: spreading the capitalised cost over the asset's useful life once it's in use.
- Impairment: writing the asset down when it's worth less than its carrying value, for example if the feature is dropped.
The rules, in plain English (as at October 2026)
| Framework | Capitalise development costs? | Key points |
|---|---|---|
| IAS 38 (IFRS) | Required once all the criteria are met | Research always expensed. Development capitalised only from the point the criteria are all met; earlier costs aren't added back later. |
| FRS 102 (Section 18) | Accounting policy choice: capitalise qualifying development costs or expense them | If capitalising, apply to all qualifying projects consistently. If useful life can't be reliably estimated, it's capped at 10 years. |
| US GAAP | See the US GAAP note below | Most SaaS platforms fall under the internal-use software rules (ASC 350-40), which are changing. |
Under IAS 38, and under FRS 102 where the company chooses to capitalise, the criteria are broadly the same. Paraphrased, a development project qualifies when the company can show:
- It's technically feasible to finish the software so it can be used or sold.
- It intends to finish it and use or sell it.
- It's able to use or sell it.
- How it will bring in future economic benefits (for example, a market for the feature or clear use internally).
- It has the technical, financial and other resources to finish it.
- It can reliably measure the costs spent on it.
All six need to be met and evidenced. In practice, "can reliably measure" is the one that trips teams up, because it depends on time tracking.
What usually qualifies
| Cost or activity | Usually capitalised? | Notes |
|---|---|---|
| Engineers building a new feature after feasibility is shown | Yes | Pay, employer NI and pension for the time spent |
| Contractors building that feature | Yes | Where invoices can be tied to the project |
| Discovery, prototyping, spikes to test if something's possible | No | This is research or pre-feasibility work |
| Bug fixes and routine maintenance | No | Keeps the existing product working rather than creating something new |
| Product managers and designers on the project | Sometimes | If their time is directly attributable and tracked; set a clear policy |
| Overheads, office costs, training, general management | No | Not directly attributable |
| Cloud hosting during development | Sometimes | Environments used only to build the feature may qualify; production hosting doesn't |
The monthly process
| Step | What "done" looks like | |
|---|---|---|
| ☐ | Keep a project register agreed with engineering | Each project has a name, status (research or development), feasibility date and expected go-live |
| ☐ | Get time data by person and project from the time tracking or ticketing tool | Hours or percentage of time per engineer, per project, for the month |
| ☐ | Get payroll cost per engineer: salary, employer NI, pension | Agreed to the payroll journal for the month |
| ☐ | Calculate capitalisable cost: time % × cost for qualifying projects only | Calculation saved with inputs and a check total |
| ☐ | Add qualifying contractor invoices | Each invoice linked to a project |
| ☐ | Post the capitalisation journal | Assets in the course of construction increase; payroll costs reduce |
| ☐ | Move finished projects to completed software and start amortisation | Go-live date confirmed by engineering |
| ☐ | Review for impairment: paused, cancelled or failed projects | Any project no longer meeting the criteria written off |
| ☐ | Agree the fixed asset register to the ledger and get sign-off | Signed reconciliation |
AI shortcut: give an approved AI tool the month's ticket export (ticket title, description, epic, assignee, hours) and your project register. Ask it to label each ticket as "new feature development", "maintenance or bug fix" or "research or spike", and summarise hours by project and label. An engineering lead reviews the labels before finance uses them. It turns a vague "about 40%" into something you can show an auditor.
Worked example: MonthEndClub Co Ltd builds a reporting module
MonthEndClub Co Ltd (fictional) reports under FRS 102 and has chosen to capitalise qualifying development costs. In August its engineering lead signs off a design document showing the new reporting module is technically feasible, the board has approved the budget, and sales has a list of customers waiting for it. The criteria are met from 1 September.
Step 1: work out the monthly cost
Five engineers cost £60,000 a month in total, including employer NI and pension. Time tracking for September shows:
| Activity | Share of time | Cost (£) |
|---|---|---|
| Reporting module (qualifying development) | 40% | 24,000 |
| Bug fixes and maintenance | 45% | 27,000 |
| Research spike on a possible AI feature | 15% | 9,000 |
| Total | 100% | 60,000 |
Only the £24,000 is capitalised. The research spike is expensed even though it might lead somewhere.
Step 2: capitalise each month
The same split applies in September, October and November. Each month:
| Account | Dr | Cr |
|---|---|---|
| Intangible assets: software in development | £24,000 | |
| Development costs capitalised (credit to staff costs) | £24,000 |
Many teams credit a separate "own work capitalised" line rather than reducing salaries directly, so the full payroll cost is still visible in the management accounts.
By 30 November, the asset in development is 3 × £24,000 = £72,000.
Step 3: go live and transfer
The module goes live on 1 December. The asset moves from "in development" to "completed software".
| Account | Dr | Cr |
|---|---|---|
| Intangible assets: completed software | £72,000 | |
| Intangible assets: software in development | £72,000 |
Step 4: amortise
The company's policy gives this kind of feature a useful life of three years. £72,000 ÷ 36 = £2,000 a month, from December.
| Account | Dr | Cr |
|---|---|---|
| Amortisation of software | £2,000 | |
| Intangible assets: accumulated amortisation | £2,000 |
At 31 December the carrying value is £72,000 − £2,000 = £70,000.
Step 5: what if the project is dropped?
Suppose instead that at the end of November, just before go-live, the board pauses the module indefinitely. At that point the criteria are no longer met. The £72,000 is written off.
| Account | Dr | Cr |
|---|---|---|
| Impairment of intangible assets | £72,000 | |
| Intangible assets: software in development | £72,000 |
AI shortcut: at each month-end, give an approved AI tool the project register and the latest product roadmap or board minutes, and ask it to flag any capitalised project that's been paused, re-scoped or not mentioned in two months. That's your impairment review list. The controller decides on each one.
If you report under US GAAP (ASC 606)
ASC 606 covers revenue, so software costs fall under other parts of US GAAP. Software used to deliver a SaaS product that customers don't take possession of is usually treated as internal-use software under ASC 350-40. As at October 2026, the FASB has issued ASU 2025-06, which removes the old project-stage model. Under the new approach, capitalisation starts once management has authorised and committed funding and it's probable the project will be completed and work as intended, and it's held back while there's significant development uncertainty. It's effective for annual periods beginning after 15 December 2027, with early adoption permitted. Software sold or licensed to customers falls under ASC 985-20 instead, which is unchanged and tends to result in little capitalisation. Check the current FASB text and your auditors' view before applying either.
Common mistakes and audit watch-outs
- Capitalising before feasibility. Costs from before the criteria are met stay expensed. They aren't added back later.
- No time tracking. A flat percentage nobody can support won't survive an audit. Use ticket or timesheet data.
- Capitalising maintenance. Bug fixes and keeping the lights on are expensed, however much effort they take.
- Forgetting to start amortisation. Projects sitting "in development" for months after go-live overstate assets and understate costs.
- No impairment review. Paused and abandoned projects need writing off promptly.
- Inconsistent policy under FRS 102. If the policy is to capitalise, it applies to all qualifying projects, not just the convenient ones.
- Mixing up accounting and tax. Capitalising costs in the accounts doesn't by itself stop them qualifying for R&D tax relief, but the two have different rules. Keep the analyses separate and check current HMRC guidance on gov.uk.
- Trusting AI ticket labels without review. AI only sees ticket text. A badly written ticket can be labelled wrongly. Engineering leads review the labels, and a sample is checked every month.
Tools that can help
Ticketing and time tracking tools hold the data that supports the capitalised amount. Payroll exports give cost per person. NetSuite and Sage have fixed asset modules for amortisation; Xero and QuickBooks have fixed asset registers that work for smaller volumes. Most teams do the time-by-cost calculation in Excel or Google Sheets. An approved AI assistant can label tickets and draft the project summary. None of these replace the judgement on feasibility or the review; they just make the evidence easier to gather.
Take it to your boss: one slide
Making software capitalisation audit-proof
The problem: our capitalised percentage is an estimate, the project list lives in someone's head, and finished projects aren't always moved into amortisation on time.
Three changes
- Project register: one list, agreed with engineering monthly, with feasibility and go-live dates.
- Time data from tickets: AI labels tickets by type; engineering leads review; finance uses the summary.
- Monthly impairment check: AI flags paused or re-scoped projects; the controller decides.
| Risk | Control |
|---|---|
| Over-capitalisation | Feasibility evidence per project; maintenance excluded |
| Unsupported percentages | Ticket or timesheet data, reviewed by engineering |
| Assets left on the books after projects stop | Monthly impairment review |
| AI mislabels work | Approved tools only; engineering review and monthly sample |
How we'll measure it: share of capitalised cost backed by ticket data, days from go-live to amortisation start, and audit adjustments in this area (aim for none).
Rates, thresholds and rules in this guide
Figures were checked against the pages below in October 2026. They change regularly (often each April or at Budget time), and we can't guarantee they're still current or right for your situation. Always check the official page before relying on them.
- R&D costs: why capital counts (BKL): IAS 38 requirement to capitalise, FRS 102 policy choice applied consistently, 10-year cap on useful life
- Software and website development costs (ACCA): the six FRS 102 capitalisation criteria
- ASU 2025-06, Internal-Use Software (Subtopic 350-40) (FASB): new US GAAP capitalisation criteria and effective date
- Check what R&D costs you can claim (GOV.UK): HMRC rules on R&D costs, which differ from the accounting tests
Key takeaways
- Research is always expensed. Development is capitalised only once all the criteria are met.
- IAS 38 requires capitalisation when the criteria are met; FRS 102 offers a policy choice applied consistently.
- Time data is the evidence. Without it, the number is a guess.
- Start amortisation at go-live and review for impairment monthly.
- US GAAP's internal-use software rules are changing under ASU 2025-06.
- Use AI to label tickets and flag stalled projects; people make the calls.
FAQs
What useful life do SaaS companies use for capitalised software?
Many use three to five years, reflecting how quickly features are replaced. The life is a judgement based on how long the feature is expected to bring benefits, and it's reviewed periodically. Under FRS 102, if it can't be reliably estimated, it's capped at 10 years.
Does capitalising development costs affect R&D tax relief?
Capitalised costs can still be relevant for R&D tax relief, but the tax rules on what qualifies are separate from the accounting rules. Check current HMRC guidance on gov.uk and keep the two analyses separate.
Can we capitalise costs for an agile team that ships every fortnight?
Yes, but it takes more care. Each feature or epic is assessed on its own, and the criteria are met at feature level. Ticket data by epic usually gives the cleanest evidence.
Can AI work out our capitalisation percentage?
It can label tickets and summarise time by project quickly, which is most of the legwork. It can't decide when feasibility is reached or whether a feature will bring benefits. Use approved tools only, have engineering review the labels, and keep sign-off with the controller.
Related guides
- R&D Tax Relief for UK SaaS: What Finance Teams Need to Know
- Capitalising Sales Commissions (Contract Costs)
- Payroll Journals and Bonus Accruals at Month-End
- Keeping Audit-Ready Working Papers Every Month
More in Costs and Accruals guides.
From the Club
Not capitalisable, but useful. The Team Mug · The Dad Hat
Join the Club. New guides, early access and members-only batches. Join here.
This guide is general information about common practice. It isn't tailored to any business, and standards, tax rules and figures change. Check your own circumstances, the latest rules and, where needed, a qualified professional before acting.
Last reviewed: October 2026.