Capitalized Software Costs: ASC 350-40 vs IAS 38
Published on Clarity With AI | By Muhammad Faisal Gurmani, CA Finalist | Last updated: September 2026
Capitalized software costs (ASC 350-40 vs IAS 38): Under US GAAP (ASC 350-40), internal-use software costs are capitalized once management funds the project and completion is probable; ASU 2025-06 replaces the old project stages (mandatory from 2028). Under IFRS, IAS 38 requires six development criteria to be met first. Earlier costs are expensed under both.
If you've ever wondered why one company puts its developers' salaries on the balance sheet while another expenses every dollar, this is usually where the answer lives. Both are following the rules. The rules just change depending on whether you report under US GAAP or IFRS.
Here's how I'd explain it to a friend across the table. We'll go through what each standard actually says, what just changed in the US, the journal entries, and the spots where people slip up. One quick note first: I'm a CA finalist, not a US CPA, so treat this as a practical guide and check the ASC text and your auditor before booking anything real.
Which standard applies to your software?
Before comparing anything, sort your software into the right bucket, because that decides which rulebook you're in.
- Built or bought for your own use (an internal finance system, a customer portal, your company website): ASC 350-40 under US GAAP.
- Built to sell, lease or license to customers: ASC 985-20 under US GAAP. It uses a technological feasibility test, and until you reach that point, development costs are expensed as R&D. ASU 2025-06 didn't touch this guidance.
- Under IFRS: IAS 38 covers internally generated intangible assets, software included. There's no IFRS that deals only with internal-use software the way ASC 350-40 does.
So when people compare ASC 350-40 with IAS 38, they're really comparing the US internal-use rules with IFRS's general intangibles rules. It's a slightly lopsided pair, and that's exactly why the details differ.
How US GAAP treats internal-use software today: the three stages
Until a company adopts ASU 2025-06, the older model still applies. It splits a software project into three stages:
- Preliminary project stage: brainstorming, comparing vendors, deciding what you need. Expense it.
- Application development stage: designing, coding, installing, testing. Capitalize it, once management has authorized and committed to funding the project and it's probable the software will be completed and used as intended.
- Post-implementation and operation stage: training, maintenance, bug fixes. Expense it.
What goes into the capitalized cost? External direct costs for materials and services, payroll for the people working directly on the project, and interest capitalized under ASC 835-20. Training, data conversion (other than building software to convert data) and general overhead stay out. Upgrades that add new functionality can be capitalized, while plain maintenance is expensed.
Capitalizing stops once the software is substantially complete and ready for its intended use. That's also when amortization begins, usually straight-line over the useful life.
What ASU 2025-06 changes in ASC 350-40
In September 2025, FASB issued ASU 2025-06, and it removes every reference to project stages from ASC 350-40. The reasoning is simple. Agile teams don't work in tidy phases. In a single two-week sprint, a team can plan, code and test at the same time, so pinpointing the day the preliminary stage ended became a judgment call that companies answered differently.
Under the new wording, you begin capitalizing when both of these are true:
- Management, with the relevant authority, authorizes and commits to funding the project.
- It's probable the project will be completed and the software will perform the function it's meant to. FASB calls this the probable-to-complete recognition threshold.
There's also a new idea to watch: significant development uncertainty. If the project still has big open questions, like unproven functionality or performance requirements that keep changing, you generally can't say completion is probable yet, so nothing gets capitalized. The ASU includes examples, and they're worth reading before you write your policy.
On timing, the ASU is mandatory for annual periods beginning after December 15, 2027, which means January 1, 2028 for calendar-year companies. You can adopt early at the start of any annual period, and you can choose a prospective, modified or retrospective transition.
What doesn't change: the external-use rules in ASC 985-20 and the cloud implementation cost rules from ASU 2018-15. FASB expects some companies to capitalize less than they do today, especially on iterative or AI-heavy projects. Less capitalized means more expense sooner, and that can move EBITDA, margins and debt covenants, so model the impact before your adoption year.
How IFRS treats software development costs (IAS 38)
IAS 38 skips stages and uses two phases instead. Everything in the research phase is expensed. Development costs are capitalized only when you can show all six of these:
- Technical feasibility of completing the software so it can be used or sold.
- Intention to complete it and use or sell it.
- Ability to use or sell it.
- Probable future economic benefits, for example cost savings or revenue.
- Adequate technical, financial and other resources to finish.
- Ability to measure the development spending reliably.
Miss one and the cost stays in expense. And "show" is the important word. Keep the business case, budget approval, technical design and resource plan on file, because that's what your auditor will ask for.
Amortization starts when the software is available for use. The method should follow the pattern in which you expect to use up the benefits, with straight-line as the fallback if you can't pin that pattern down.
ASC 350-40 vs IAS 38 side by side
| Feature | US GAAP (ASC 350-40) | IFRS (IAS 38) |
|---|---|---|
| Scope | Internal-use software (ASC 985-20 for software to be sold) | Internally generated intangibles, software included |
| Framework | Three stages until ASU 2025-06 is adopted, then two recognition conditions | Research phase and development phase with six criteria |
| Capitalization trigger | Management funds the project and completion is probable | All six criteria demonstrated |
| Early-phase costs | Expensed | Research costs expensed |
| Interest | ASC 835-20 | IAS 23 for qualifying assets |
| Amortization starts | Ready for intended use | Available for use |
| Impairment reversal | Not permitted | Permitted under IAS 36, with a cap |
| Revaluation | Cost model only | Only with an active market, which is rare for software |
| Cloud and SaaS implementation costs | ASU 2018-15: eligible costs can be capitalized | Often expensed, depends on whether you control the software |
Journal entries for capitalized software costs
Say a company's developers work on a qualifying project, and $45,000 of their payroll meets the capitalization criteria. Payroll was already booked to salaries expense during the month, so you reclassify it.
| Account | Debit ($) | Credit ($) |
|---|---|---|
| Capitalized software (balance sheet) | 45,000 | |
| Salaries expense | 45,000 |
Once the software is ready for use, you start amortizing. With a 36 month useful life, that's $45,000 divided by 36, or $1,250 a month.
| Account | Debit ($) | Credit ($) |
|---|---|---|
| Amortization expense, software (P&L) | 1,250 | |
| Accumulated amortization, software (balance sheet) | 1,250 |
The entries are the same under both frameworks. Only the test for getting to the first entry is different. And if payroll was accrued at month-end but not paid yet, that's an accrued expense, so if the difference still feels fuzzy, this guide on prepaid vs accrued expenses clears it up.
Cloud and SaaS implementation costs
This is where a lot of finance teams get tripped up, because a SaaS subscription isn't software you own. Under US GAAP, ASU 2018-15 says the implementation costs of a cloud service contract follow the same capitalization thinking as internal-use software. The capitalized amount shows up in the same balance sheet line as prepayments of the hosting fees, and the amortization runs through the same income statement line as those fees, over the term of the arrangement. That's why these costs so often end up sitting with prepaids. If that area feels shaky, here's how prepaid expenses are treated under GAAP and IFRS.
IFRS tends to be stricter in practice. After an IFRIC agenda decision on configuration and customization costs in SaaS arrangements, many companies conclude they don't control the software, so those costs get expensed as the service is received instead of capitalized. The facts of each contract matter, so check with your auditor.
Impairment and revaluation
Impairment works like a one-way street in the US and a two-way street under IFRS.
Under US GAAP, if it stops being probable that the software will be completed and placed in service, you write it down right away. And once you've written it down, you can't write it back up. Under IFRS, IAS 36 makes you check at each reporting date whether an earlier impairment may have reversed. If the estimates improved, you can reverse it, but only up to the carrying amount the asset would have had, net of amortization, if you'd never impaired it.
Revaluation is a smaller point. US GAAP uses the cost model only. IAS 38 allows revaluation only when there's an active market for the asset, and there almost never is for software.
Common mistakes with software capitalization
- Capitalizing training and data conversion. Both are expensed in almost every case.
- Not tracking developer time by project. If you can't support the payroll you capitalized, you'll have a hard conversation at audit. Project codes on timesheets solve most of it.
- Coding contractor invoices to expense by default. If invoices pile up, an automated setup like the AI invoice processing system I built in n8n can pull project codes straight from each invoice so nothing gets missed.
- Forgetting to stop capitalizing at go-live. Costs after the software is ready for use are maintenance, not asset cost.
- Treating SaaS implementation like owned software. Different rules, different balance sheet line.
- Waiting until your adoption year for ASU 2025-06. Model the impact early, especially if you have covenants.
- Ignoring group differences. If a US GAAP parent consolidates IFRS subsidiaries, expect conversion adjustments on capitalized development costs.
Frequently asked questions
Does ASU 2025-06 change how cloud or SaaS implementation costs are treated?
No. Implementation costs for cloud computing arrangements that are service contracts continue to follow the ASU 2018-15 guidance in ASC 350-40.
Can you reverse an impairment loss on capitalized software?
Not under US GAAP. Under IFRS, IAS 36 requires you to assess whether an earlier impairment loss should be reversed, up to the carrying amount the asset would have had without the impairment.
What is the difference between ASC 350-40 and ASC 985-20?
ASC 350-40 covers software built or bought for internal use. ASC 985-20 covers software to be sold, leased or marketed, where costs are expensed as R&D until technological feasibility is established.
When does ASU 2025-06 take effect?
For annual periods beginning after December 15, 2027, including interim periods within them. Early adoption is permitted at the start of any annual reporting period.
Are research costs capitalized under IAS 38?
No. Research phase costs are expensed as incurred. Only development costs that meet all six IAS 38 criteria are capitalized.
Does IFRS have a separate standard for internal-use software?
No. IAS 38 covers internally generated intangible assets, including software, so there's no IFRS equivalent to ASC 350-40.
Final thoughts
If you remember one thing, make it this. Both frameworks want proof that the software will actually get finished and pay off before costs reach the balance sheet. US GAAP asks for management commitment plus probable completion, and IFRS asks for six specific criteria. The journal entries look the same either way.
If you like seeing where the two frameworks split, I've also covered whether a right-of-use asset is current or non-current and how LIFO vs FIFO works under GAAP and IFRS.
This is a practical guide, not accounting advice. Read the ASU itself on FASB's site and confirm treatment with your auditor before you adopt a policy.
Further reading on ASU 2025-06: BDO's summary of the ASU and Deloitte's Heads Up on the amendments.