Capitalized software development costs are development spend booked as an asset and amortized over its life, instead of expensed in the period you pay for it. Two regimes matter here: IFRS (IAS 38), used by EU listed groups and UK IFRS reporters, and US GAAP (ASC 350-40), which changed in 2025. Your auditor decides how either applies to you, and that includes engineers who are contractors on a vendor invoice.
What does capitalizing software development costs mean?
The question is whether a given dollar of engineering spend is an asset or an expense. Expensed spend hits the income statement in the period you incur it. Capitalized spend sits on the balance sheet and reaches the income statement later, as amortization.
Operating profit and EBITDA look better in the build period. Amortization shows up afterwards, and it doesn't go away.
Cash flow presentation can differ too. Under US GAAP, Deloitte's statement of cash flows roadmap says implementation costs in a cloud computing arrangement are presented in the same cash flow category as the service fee, which is operating.
When do you capitalize under IFRS (IAS 38)?
Under IFRS, research is always expensed. Development spend is capitalized only when you can demonstrate all six criteria. PwC's IFRS and US GAAP comparison guide (section 6.6, dated 31 October 2024) lists them, and the IFRS Foundation's IAS 38 page adds the general recognition conditions: probable future economic benefits and a reliable measure of cost.
Here are the six criteria with the question a CFO can put to engineering:
| IAS 38 criterion | Question to ask engineering |
|---|---|
| Technical feasibility of completing the software | Has anyone built a working prototype, or do we still not know if this can be done? |
| Intention to complete it | Is there an approved scope and a team assigned, or is this a maybe? |
| Ability to use or sell it | Do we have the distribution, infrastructure and customers (or internal users) to put it to work? |
| Probable future economic benefits, or usefulness if used internally | What revenue or cost saving is this expected to produce, and who signed off on that? |
| Adequate technical and financial resources | Is the team funded through to completion, not only through next quarter? |
| Ability to measure the cost reliably | Can we trace hours and invoices to this project and nothing else? |
The last row matters most for outsourced work. If engineering can't tell you what a project cost, the other five criteria don't matter.
When do you capitalize under US GAAP after ASU 2025-06?
US GAAP is a different regime with different wording. Don't read the IAS 38 criteria into it.
The FASB issued ASU 2025-06 on 18 September 2025. According to Deloitte's DART Heads Up on the update, it removes the project stages from ASC 350-40 and replaces them with two tests. Capitalization starts when both are met:
- Management with the relevant authority has authorized and committed to funding the project.
- It's probable the project will be completed and the software used to perform the function intended.
There's a blocker. If the project has "significant development uncertainty", capitalization doesn't start. Deloitte describes two factors: novel or unproven functionality whose uncertainty coding and testing won't resolve, and significant performance requirements that are unidentified or still being substantially revised.
The effective date is annual periods beginning after 15 December 2027, with interim periods inside them. For a calendar-year company, that means the year starting 1 January 2028. Early adoption is allowed. Deloitte lists three transition methods: prospective, retrospective and modified prospective.
Once the software is ready for use, BDO's guidance on software costs says amortization is generally straight-line, unless another systematic and rational basis better reflects use, and impairment follows ASC 360-10-35.
What changed: the old three-stage model vs the new threshold
Older guides still teach the stage-based model, which is the pre-ASU rule. If you're reading one, check its date against ASU 2025-06 before you build a policy on it.
| Rule | Before ASU 2025-06 (US GAAP) | After ASU 2025-06 (US GAAP) |
|---|---|---|
| Trigger for capitalizing | Project stages in ASC 350-40 | Authorization and committed funding, plus probable completion and intended use |
| What blocks it | The stage you're in | Significant development uncertainty |
| Effective date | Applies until the entity adopts the ASU (required for annual periods beginning after 15 December 2027) | Annual periods beginning after 15 December 2027, early adoption allowed |
IFRS didn't move. IAS 38 still runs on the six criteria above, so a group reporting under both frameworks has two different tests running on the same project.
How are outsourced and nearshore engineering invoices treated?
A contractor invoice isn't treated differently from payroll because it's a contractor invoice. The standards test the activity and the phase of the project, not who employs the person. External direct costs can be part of the cost of the asset.
Deloitte's example has a company pay a third party time-and-materials fees to build functionality the provider hasn't delivered before. Those costs are expensed as incurred until the uncertainty is resolved through coding and testing. A licensed base layer in the same example is capitalized, along with eligible internal and external direct implementation costs. For the cost picture around those invoices, see software development cost guides and software development team cost in Europe.
What counts as "eligible" is for your auditor.
The checklist below is practice, not standard text. It's what makes the auditor's job easy:
- Invoice per project or per ticket group, not one monthly lump.
- Keep new-feature build separate from maintenance, bug fixes, support, training and overhead.
- Keep timesheets by project, tied to the invoice lines.
- When one invoice mixes capitalizable and non-capitalizable work, split it and write down why.
- Record the date the capitalization decision was made. Under the new US model, it shows when development uncertainty was resolved.
Our view: an invoice that shows hours by engineer and a stated margin is easier to allocate than a blended day rate. Whether the margin forms part of a capitalizable cost is the auditor's call, so don't assume it does.
What this means for your engineering budget
The decision is how engineering spend, nearshore invoices included, gets coded before the budget goes into the board pack. Capitalization changes EBITDA and the cash flow line, and it shouldn't be decided invoice by invoice after the fact.
Ask finance and your auditor three things: which framework applies to you, who decides when a project crosses from research or uncertainty into development, and what evidence they'll want. Then ask each vendor for per-project invoicing and timesheets in that format.
If you have a US parent, ASU 2025-06 is mandatory for annual periods beginning after 15 December 2027, but early adoption is allowed. That's a decision to make this year, not in 2028. Also check how the answer feeds your R&D spend as a percentage of revenue, because capitalized spend leaves the R&D expense line. For how vendor pricing models differ, see staff augmentation pricing.
Hiring nearshore engineers through HighCircl
HighCircl places senior engineers from seven countries: Poland, Hungary, Slovakia, Slovenia, Romania and Spain in the EU, plus Serbia, which isn't an EU member. The margin is 20%, capped, and shown separately from what the engineer earns. There's no recruitment fee and no subscription. If an engagement isn't working, we replace the engineer at no additional recruitment cost. To see how that works, hire nearshore engineers through HighCircl.
FAQ
When to capitalise software development costs?
It depends on the framework. Under IFRS (IAS 38), once you can show all six criteria for development, and never for research. Under US GAAP (ASC 350-40, after ASU 2025-06), once management has authorized and committed funding and it's probable the project will be completed and used as intended, provided significant development uncertainty has been resolved.
What are the GAAP rules for capitalizing software development costs?
ASU 2025-06, issued 18 September 2025, replaced the stage-based model in ASC 350-40 with two tests: authorization and committed funding, and probable completion and intended use. Significant development uncertainty blocks capitalization. It's effective for annual periods beginning after 15 December 2027, with early adoption permitted. Amortization starts when the software is ready for use and is generally straight-line, unless another systematic and rational basis better reflects use (BDO).
Can development costs be capitalized?
Yes, under both regimes, if the conditions are met. IAS 38 treats development meeting its criteria as an asset and research as an expense. US GAAP allows capitalization once the ASU 2025-06 conditions are met. Other local GAAPs differ, and your auditor decides what applies to you. Tax treatment is a separate question, covered for the UK in R&D tax relief for overseas contractors.
Is software amortized over 3 or 5 years?
Neither is a rule. The sources used here don't set a fixed period. Amortization starts when the software is ready for use and is generally straight-line, unless another systematic and rational basis better reflects use (BDO).
Sources
- Deloitte DART: Heads Up on ASU 2025-06, software costs guidance
- BDO: Accounting for software costs
- PwC Viewpoint: IFRS and US GAAP similarities and differences, 6.6 Internally developed intangibles
- Deloitte DART: Statement of cash flows roadmap 7.12, cloud computing arrangements
- IFRS Foundation: IAS 38 Intangible Assets