Capitalise or Expense: Accounting for Website and Software Development Costs

Some of it goes on the balance sheet. Most of the rest doesn’t. Which bucket a line item lands in depends on three things: what the work actually was, when in the project it happened, and which rulebook your accounts follow. Under both US GAAP and IFRS, the money spent building working functionality can usually be capitalised. The money spent deciding what to build, writing the copy, training the team, and keeping the thing alive afterwards usually cannot.

That’s the short answer. The rest of this explains how to defend it.

(US readers search this as “capitalize.” Same question, same answer — we’ve used the British spelling throughout because most of our clients are outside the US.)

Why this post exists, and why it was wrong until now

We’re a software development studio. We send the invoices that trigger this question. Roughly once a quarter, a client’s finance lead emails us asking whether they can capitalise our last three invoices, and what documentation they’ll need when the auditor asks.

Every page ranking on Google for this question is written by an accounting firm. That’s useful, but it’s the view from the other side of the table. Nobody writing about this has actually had to reconstruct, eighteen months later, which sprint a particular workstream belonged to.

This post was first published in 2020. It was accurate then. It is not accurate now, and we’ve rewritten it from scratch rather than patching it, because two of the rules underneath it have been replaced. If you read the old version and acted on it, the “spread your website costs over three years” advice in particular is obsolete — see the corrections note at the end.

This is guidance, not advice. It will get you to a well-informed conversation with your controller or auditor. It does not replace one. The judgements below are genuinely judgements, and your auditor’s view of your specific facts is the one that counts.

What changed in the last 24 months

Three things, and all three matter.

1. FASB replaced the three-stage model for internal-use software. On 18 September 2025, FASB issued ASU 2025-06, Intangibles — Goodwill and Other — Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software. It removes every reference to project stages from ASC 350-40 and supersedes ASC 350-50 (Website Development Costs) entirely, folding website guidance into ASC 350-40. If you have ever seen the “preliminary project stage / application development stage / post-implementation stage” diagram, that diagram is on its way out. (FASB; summarised at Deloitte DART, 18 September 2025.)

2. The US restored immediate tax deduction for domestic software development. The One Big Beautiful Bill Act, signed 4 July 2025, created IRC §174A, allowing domestic research and experimental expenditure — which includes software development — to be deducted in the year incurred, for tax years beginning after 31 December 2024. Foreign development still amortises over 15 years under §174. (IRS; procedural guidance in Rev. Proc. 2025-28, released 29 August 2025.)

3. The UK collapsed its two R&D schemes into one. The merged RDEC scheme — a 20% above-the-line expenditure credit — applies to accounting periods beginning on or after 1 April 2024. (GOV.UK.)

Most of the content ranking for this question predates at least one of these.

The bit everyone gets wrong first: book is not tax

Before any of the rules, get this straight, because half the confusion in this topic comes from mixing the two.

Book treatment is what appears in your financial statements — the accounts your investors, lenders and auditors read. It’s governed by US GAAP or IFRS.

Tax treatment is what appears on your tax return. It’s governed by the tax code of each country you file in.

They are different systems answering different questions, and they routinely disagree about the same invoice. In the US right now they disagree quite dramatically: under §174A you can deduct domestic software development immediately on the tax return, while ASC 350-40 still requires you to capitalise qualifying development costs in the accounts.

That gap is a temporary difference, not a permanent one. The total deduction over the asset’s life is the same either way — only the timing differs — so it generates a deferred tax liability rather than a permanent saving. Your accountant will handle the mechanics. Your job is to not assume that “my accountant expensed it for tax” means “it’s expensed.”

US GAAP: what the rules say now, and what they said until recently

Three codification topics govern software costs in US GAAP, and which one applies depends on what you’re building it for.

Internal-use software and websites: the old model

Until ASU 2025-06 takes effect, ASC 350-40 splits a project into three stages:

• Preliminary project stage — evaluating alternatives, choosing vendors, deciding what to build. Expensed.
• Application development stage — coding, configuring, installing hardware, testing. Capitalised.
• Post-implementation and operation stage — training, maintenance, running the thing. Expensed.

Capitalisation began when the preliminary stage finished and it was probable the project would be completed and used as intended.

Internal-use software and websites: the new model

ASU 2025-06 throws out the stages. Under amended ASC 350-40-25-12, capitalisation begins when both of these are true:

1. Management with the relevant authority authorises and commits to funding the software project — implicitly or explicitly; and
2. It is probable the project will be completed and the software will be used to perform the function intended. FASB calls this the probable-to-complete recognition threshold.

Then there’s a brake. New paragraph ASC 350-40-25-12A blocks capitalisation — costs keep going to the income statement — if there is significant development uncertainty. That exists when either:

• the software has technological innovations or novel, unique or unproven functions or features, and the uncertainty about them has not been resolved through coding and testing; or
• significant performance requirements have not been identified, or are still subject to substantial revision.

Read the first of those twice if you’re building anything AI-shaped. FASB expects it to push more costs into expense, not fewer. Several firms reviewing the ASU have flagged the same thing — PKF O’Connor Davies notes it is possible to see more costs expensed, and Forvis Mazars expects a decrease in capitalisation on SaaS arrangements. (Both are firm interpretations of the standard, not the standard itself.)

Which model applies to you, today

Both are live, depending on when you adopt.

ASU 2025-06 is effective for annual reporting periods beginning after 15 December 2027, including interim periods within those years, for all entities. Early adoption is permitted where financial statements have not yet been issued. Three transition methods are available: prospective, modified prospective, and retrospective. (ASC 350-40-65-4.)

So if your financial year begins in January, the mandatory date is your FY2028. Until you adopt, the stage model still governs. A lot of content published in the last twelve months gets this wrong in one direction or the other — either presenting the new rule as if it were already mandatory, or ignoring it entirely.

Software you sell to customers

ASC 985-20 is untouched by ASU 2025-06. It uses a different and generally later trigger: technological feasibility, which under ASC 985-20-25-2 is established when you have completed all planning, designing, coding and testing activities necessary to establish that the product can be produced to meet its design specifications. Everything before that point is research and development expense. Capitalisation stops at general release.

In practice this means product companies capitalise a narrow slice — often close to nothing — because feasibility frequently isn’t established until shortly before shipping. If you’re building a SaaS product, this is the topic that governs you, not 350-40.

IFRS: IAS 38 and SIC-32

IFRS has no equivalent of the stage model. It has one standard for intangible assets and one interpretation specifically about websites.

IAS 38 splits every project into a research phase and a development phase.

Research is always expensed. IAS 38.54 is unambiguous: no intangible asset arising from research shall be recognised. Investigating alternatives, evaluating technologies, exploring what’s possible — all expense, always.

Development is capitalised if — and only if — all six criteria in IAS 38.57 are met:

1. Technical feasibility of completing it
2. Intention to complete and use or sell it
3. Ability to use or sell it
4. How it will generate probable future economic benefits
5. Adequate technical, financial and other resources to complete it
6. Ability to measure the expenditure reliably

Note the wording: once all six are met, capitalisation is mandatory, not optional. This is a real difference from what many people assume, and a real difference from UK FRS 102, where capitalising development costs is an accounting policy choice, and FRS 105 (micro-entities), where it is prohibited outright.

IAS 38 also bans capitalising some things outright, regardless of how much you spent: internally generated brands, mastheads, publishing titles, customer lists, and internally generated goodwill.

SIC-32 applies IAS 38 specifically to website costs and remains in force (effective 25 March 2002). It maps a website project to IAS 38’s phases — planning is research and gets expensed; application and infrastructure development, graphical design and content development can be capitalised where the IAS 38.57 criteria are met; the operating stage is expensed.

And then it drops the sentence that catches out most companies:

All expenditure on developing a website solely or primarily for promoting and advertising the entity’s own products and services is recognised as an expense when incurred.

If your new site is a marketing site — brochure pages, case studies, a contact form — SIC-32 says the whole build is an expense under IFRS. Not part of it. All of it. That is a materially different answer from US GAAP on identical facts, and it is the single most common IFRS mistake we see on website projects. (IFRS Foundation, SIC-32.)

Cloud and SaaS implementation costs: where the frameworks split hardest

You’re not buying software. You’re buying access to software someone else runs. So what happens to the $40,000 you paid a partner to configure it, migrate your data and integrate it with your ERP?

Under US GAAP, ASU 2018-15 added hosting-arrangement provisions to ASC 350-40. Implementation costs in a hosting arrangement that is a service contract are assessed using the internal-use software model — qualifying costs are capitalised. But the presentation is unusual and worth knowing:

• The capitalised asset is presented in the same balance sheet line as a prepayment of the hosting fees (ASC 350-40-45-2) — not as an intangible asset.
• It is amortised over the term of the hosting arrangement.
• The amortisation charge goes on the same income statement line as the hosting fee itself (ASC 350-40-45-1) — not in depreciation and amortisation.

That last point surprises people. It means capitalising SaaS implementation costs does not improve your EBITDA, because the amortisation sits above the line with the subscription cost.

Under IFRS, the answer is mostly the opposite. The IFRS Interpretations Committee published an agenda decision in March 2021 on configuration and customisation costs in a SaaS arrangement. In the typical fact pattern, the customer does not control any software, so no intangible asset is recognised and the costs are expensed. There are two narrow exceptions: where the work genuinely creates a separate resource the customer controls (a piece of code you own and could run elsewhere), and where the supplier performs configuration services that are not distinct from the access itself, in which case the cost is recognised over the SaaS term. The IASB did not object to the decision in April 2021, which gives it authoritative weight. (IFRS Foundation.)

The practical upshot: an identical ERP or CRM rollout produces a capitalised asset under US GAAP and an expense under IFRS. If you report under both — or if your group reports IFRS and your US subsidiary reports GAAP — you need two sets of numbers from the same project. Tell your implementation partner that before the project starts, not after.

US GAAP vs IFRS at a glance

The decision framework: run this on your invoice

Take the actual line items and walk each one through three questions.

Question 1 — What kind of software is this? Internal use or your own website → ASC 350-40 / IAS 38 + SIC-32. Something you’ll sell or license → ASC 985-20 / IAS 38. Someone else’s hosted product you’re configuring → ASC 350-40 hosting provisions / IFRIC 2021.

Question 2 — Had the project cleared the threshold when this cost was incurred? Under US GAAP: was funding committed and completion probable, with no significant development uncertainty outstanding? (Or, if you haven’t adopted ASU 2025-06 yet: was the preliminary stage complete?) Under IFRS: were all six IAS 38.57 criteria satisfied? If no — expense it, no matter what the work was.

Question 3 — Is this cost of a type that can be capitalised at all? Some costs are permanently excluded regardless of timing. Training is never capitalised. General and administrative overhead is never capitalised. Data conversion costs are expensed. Under IFRS, anything on a solely-promotional website is expensed no matter when it happened.

Only a “yes” at all three gates puts it on the balance sheet.

Line-by-line: what actually happens to each cost

This is the table to send your finance team.

The one that causes the most arguments is the last-but-two: enhancement versus maintenance. The test is whether the work adds functionality that wasn’t there before. Making an existing feature faster is usually maintenance. Adding a feature that didn’t exist is usually an enhancement, assessed as its own mini-project. Redesigning a page so it looks different but does the same thing is maintenance, and finance teams almost always want it to be an enhancement.

Worked example 1: a $60,000 website and portal rebuild

A US company reporting under US GAAP rebuilds its website. The new site has marketing pages and a logged-in customer portal where clients can view order status. The project is authorised and funded by the CTO in March; completion is judged probable; there’s nothing technically novel about it.

In plain terms: $39,000 goes to an intangible asset on the balance sheet and is amortised on a straight-line basis over its useful life. If the company assesses that at three years, that’s $13,000 a year hitting the income statement, starting when the site goes live and is ready for its intended use. The other $21,000 hits the income statement immediately.

Now run the same project under IFRS. The marketing pages exist solely to promote the company’s products. SIC-32 expenses them outright, so that $9,000 moves from capitalised to expensed. The customer portal has functionality beyond promotion, so it survives the IAS 38.57 test and stays capitalised. Result: $30,000 capitalised, $30,000 expensed.

Same project. Same invoices. A $9,000 difference in this year’s operating profit, purely because of which framework you report under. That is not a rounding error, and it’s why “can we capitalise the website” has no single answer.

Worked example 2: a $45,000 SaaS implementation

A company signs a three-year subscription for a hosted ERP platform at $90,000 a year, and pays an implementation partner $45,000.

Under US GAAP: $23,000 sits on the balance sheet alongside the hosting prepayment, amortised over the three-year term at roughly $7,667 a year — and that amortisation appears on the same income statement line as the $90,000 subscription, not in depreciation and amortisation.

Under IFRS: the $15,000 configuration is expensed because the company doesn’t control the hosted software. Only the $8,000 of integration code has a route to the balance sheet, and only if the company genuinely controls that code as a separate resource — meaning it could run it independently of the vendor’s platform. If it can’t, that’s expensed too, and the entire $45,000 hits this year’s profit and loss.

This pattern repeats on every ERP implementation and CRM rollout we work on. The framework you report under changes the answer by tens of thousands.

Tax: where each market diverges from the accounts

United States

Under IRC §174A, created by the One Big Beautiful Bill Act (signed 4 July 2025), domestic research and experimental expenditure — including software development — can be deducted in the year incurred, for tax years beginning after 31 December 2024. Foreign research and experimental expenditure remains subject to 15-year amortisation under §174.

Procedural guidance came in Rev. Proc. 2025-28 (released 29 August 2025). A retroactive election was available to eligible small businesses — those meeting the §448(c) gross receipts test, with average annual gross receipts of $31 million or less, applied with controlled-group aggregation — allowing amended returns for 2022 through 2024. That window closed on 6 July 2026. If you were eligible and didn’t file, it has gone.

One older rule worth naming because it appears in a lot of stale content, including the previous version of this post: Rev. Proc. 2000-50 Section 5, which permitted a 36-month amortisation of software development costs, was rendered obsolete for costs incurred in tax years after 2021. If a page tells you to spread website development over three years, it hasn’t been updated since 2021.

United Kingdom

HMRC’s guidance on website costs sits at BIM35815, with in-house software at BIM35822 and BIM35850. The underlying test is the classic capital-versus-revenue one: expenditure creating an asset of enduring benefit is capital; ongoing maintenance, updates and regular content refreshes are revenue and deductible as incurred. (HMRC Business Income Manual.)

For most companies the distinction bites less than you’d expect, because the intangible fixed assets regime in Part 8 of CTA 2009 generally makes the tax treatment follow the accounts for software created or acquired on or after 1 April 2002. Get the accounts right and the tax largely follows. (HMRC CIRD manual.)

On R&D relief, the merged RDEC scheme gives a 20% above-the-line credit, worth roughly 15–16.2% net of corporation tax depending on your rate, for accounting periods beginning on or after 1 April 2024.

Australia

The ATO addresses this directly in TR 2016/3, Income tax: deductibility of expenditure on a commercial website. It sorts website expenditure into three buckets: immediately deductible (routine operating costs, maintenance, domain renewals), deductible over time as in-house software (a five-year effective life for assets first used on or after 1 July 2015), or not deductible but added to a CGT asset cost base — which is where domain name rights typically land. The ruling contains 26 worked examples and is the most practically useful government document on this topic in any jurisdiction. (ATO.)

India

Ind AS 38 is substantively converged with IAS 38, and its appendix carries the SIC-32 website guidance. ICAI has published Educational Material on Ind AS 38. If you report under Ind AS, the IFRS section of this post applies to you with no meaningful modification. Companies still on the older AS 26 should check with their auditor, as the recognition wording differs.

Citation-ready facts

If you’re extracting the load-bearing statements from this post, these are them:

1. ASU 2025-06, issued 18 September 2025, removes the three project-stage model from ASC 350-40 and supersedes ASC 350-50 for website development costs.
2. ASU 2025-06 is effective for annual periods beginning after 15 December 2027 for all entities, with early adoption permitted.
3. Under amended ASC 350-40-25-12, capitalisation begins when management commits funding and completion of the project is probable.
4. ASC 350-40-25-12A prevents capitalisation where significant development uncertainty exists, including novel or unproven functionality not yet resolved through coding and testing.
5. ASC 985-20 requires technological feasibility before capitalising software developed to be sold, leased or marketed, and was not amended by ASU 2025-06.
6. IAS 38.54 prohibits recognising any intangible asset arising from research; research costs are always expensed under IFRS.
7. SIC-32 requires all expenditure on a website developed solely or primarily to promote the entity’s own products to be expensed as incurred.
8. The IFRS Interpretations Committee’s March 2021 agenda decision concluded that SaaS configuration and customisation costs are generally expensed because the customer does not control the software.
9. Under ASC 350-40-45-1, amortisation of capitalised cloud implementation costs is presented on the same income statement line as the hosting fee, not within depreciation and amortisation.
10. IRC §174A, enacted 4 July 2025, permits immediate deduction of domestic research and experimental expenditure for US tax years beginning after 31 December 2024, while foreign expenditure remains on 15-year amortisation.
11. The UK merged RDEC scheme provides a 20% above-the-line expenditure credit for accounting periods beginning on or after 1 April 2024.
12. ATO ruling TR 2016/3 classifies commercial website expenditure as immediately deductible, in-house software with a five-year effective life, or a CGT cost base addition.

What we do on our side to make this easier

We’re the vendor. Some of the difficulty here is created by how development firms invoice, and it’s avoidable.

We line-item by workstream, not by month. “Development services — March: $18,000” is useless to a finance team eighteen months later. Discovery, build, content, migration, training and QA appear as separate lines with separate totals, because those lines map directly to different accounting treatments.

We record the date the build was authorised. Under both the old and new US GAAP models, and under IAS 38, the capitalisation clock starts at a specific, evidenced moment. A signed statement of work with a date on it is the cleanest evidence there is. Your auditor will ask for it.

We separate configuration from custom code on SaaS work. These have different answers under IFRS and sometimes under US GAAP. Splitting them at invoice time costs us nothing and saves a reconstruction exercise later.

We flag when requirements are still moving. Under ASC 350-40-25-12A, unresolved performance requirements block capitalisation. If a project is still in genuine flux, we say so in the status report, and that report is dated evidence.

We note whether work adds functionality or maintains it. Post-launch, this is the single most contested distinction. A one-line note on the ticket at the time is worth more than an argument at year-end.

If you want this level of documentation on a project, ask for it at kickoff. It’s a formatting decision, not extra work. You can book a call with us if you’d like to talk through how it would apply to a specific build.

Corrections to the previous version of this post

This page was published on 12 October 2020 and has been fully rewritten. Three things in the original are now wrong and are corrected above:

1. The three-stage model was presented as the definitive US GAAP answer. ASU 2025-06 removes it. The post now covers both the current model and the incoming one, with effective dates, because both are live depending on adoption.
2. The original recommended spreading outsourced website development costs over three years for US tax. That reflected Rev. Proc. 2000-50 Section 5, obsolete for tax years after 2021 and superseded again by §174A.
3. The original addressed only US treatment and blended book with tax. IFRS, UK, Australian and Indian treatment are now covered separately, and book and tax are kept apart throughout.

Cloud and SaaS implementation costs were not covered at all in the original and are now a full section.

Changelog — 4 September 2026: complete rewrite. Added ASU 2025-06, IRC §174A, IFRIC March 2021 SaaS agenda decision, SIC-32 promotional-website rule, UK/Australia/India treatment, two worked examples, and a line-item decision table. Removed obsolete three-year US tax amortisation guidance and the ASC 350-50 framing.