ASC 350-40 internal-use software costs after ASU 2025-06 vs IAS 38
Under US GAAP, ASU 2025-06 replaces the stage-based model of ASC 350-40 with a single recognition threshold: an entity starts capitalizing internal-use software costs when management with the relevant authority authorizes and commits to funding the project and it is probable that the project will be completed and the software will be used to perform the function intended. Under IFRS, IAS 38 Intangible Assets reaches capitalization through a different route, separating a research phase that is always expensed from a development phase that is capitalized only once six conditions can be demonstrated.
The FASB issued ASU 2025-06, Targeted Improvements to the Accounting for Internal-Use Software, in September 2025. The amendments are effective for annual reporting periods beginning after December 15, 2027, and interim periods within those years, with early adoption permitted as of the beginning of an annual reporting period. A calendar-year company therefore applies the new model from January 1, 2028 at the latest, and many controllers are deciding now whether to adopt early and which transition method to use.
The worked example below follows two software projects through one year, separates the costs that are capitalized from those that are expensed, and shows the journal entries, the amortization and a transition adjustment. The amounts are illustrative and computed in Python, and the same facts are then read through IAS 38 to show where the two frameworks meet and where judgement can lead them apart.
··········
WHEN INTERNAL-USE SOFTWARE COSTS ARISE.
The question comes up whenever a company builds or buys software to run its own business and has no plan to market it. Typical cases include an in-house procurement platform, a customer portal, a data warehouse for management reporting, a pricing engine, or an automation layer that sits on top of the ERP system. Under US GAAP these projects fall under Subtopic 350-40. Software developed to be sold, leased or otherwise marketed follows separate guidance and is outside the scope discussed here.
The accounting choice has a direct effect on reported results. Every dollar capitalized moves out of operating expense in the year it is spent and comes back as amortization over the software's useful life. For a company with a large engineering team the difference between expensing and capitalizing payroll can change EBITDA materially, which is why auditors, lenders and investors pay close attention to the policy and to its consistent application.
Hosting arrangements are a related but distinct question. When a company pays for access to software that a vendor hosts, the implementation costs of that cloud computing arrangement follow their own rules, covered in our article on cloud computing and SaaS implementation costs under ASC 350-40 and IAS 38. The analysis below concerns software the entity develops or obtains and controls itself.
··········
HOW ASC 350-40 WORKED BEFORE ASU 2025-06.
The legacy model divided every software project into three sequential stages. Costs of the preliminary project stage, such as evaluating alternatives and selecting vendors, were expensed. Costs of the application development stage, such as design, coding, installation and testing, were capitalized once the preliminary stage was complete and management had committed to funding. Costs of the post-implementation and operation stage, such as training and maintenance, were expensed again.
That structure was written for linear, waterfall development. The FASB's summary to ASU 2025-06 observes that many entities have moved to an incremental and iterative approach, with agile as the common example, and that the existing requirements did not specifically address software developed that way. Teams that plan, code and test in short cycles do not move through clearly separated stages, so entities applied the legacy guidance inconsistently and spent significant effort mapping sprints to stages.
··········
THE ASU 2025-06 CAPITALIZATION THRESHOLD UNDER ASC 350-40.
ASU 2025-06 removes all references to prescriptive and sequential development stages from Subtopic 350-40, so the guidance is neutral to the development method used. In their place, capitalization begins when two conditions are both met. Management with the relevant authority must authorize and commit to funding the software project, and it must be probable that the project will be completed and the software will be used to perform the function intended.
The second condition is assessed against what the ASU calls significant development uncertainty. Such uncertainty exists when the software has technological innovations or novel, unique or unproven functions or features whose uncertainty has not been resolved through coding and testing. It also exists when the significant performance requirements of the software have not been identified, or when identified requirements continue to be substantially revised. While significant development uncertainty is present, the probable-to-complete threshold is not met and costs are expensed as incurred.
Once the threshold is met, the cost categories that can be capitalized are familiar from the legacy guidance:
........
Cost under ASC 350-40 | Treatment after the threshold is met |
External direct costs of materials and services | Capitalized |
Payroll of employees directly working on the project | Capitalized, for time spent on it |
Interest under Subtopic 835-20 | Capitalized when the criteria are met |
Software to access or convert old data | Capitalized |
Training | Expensed |
Data conversion, other than that software | Expensed |
General and administrative costs and overhead | Expensed |
Maintenance | Expensed |
........
The ASU also supersedes Subtopic 350-50 on website development costs and moves that guidance into Subtopic 350-40. Website hosting fees are generally expensed over the period of benefit, content input and search engine registration costs are expensed, and domain costs are evaluated under Subtopic 350-30.
··········
PRESENTATION, DISCLOSURE AND TRANSITION UNDER ASU 2025-06.
The amendments change which disclosures apply. The property, plant and equipment disclosures of Subtopic 360-10 are required for all capitalized internal-use software costs, regardless of how those costs are presented in the financial statements, and the intangible asset disclosures in paragraphs 350-30-50-1 through 50-3 do not apply to them. Companies that present capitalized software inside intangible assets on the balance sheet still provide the Subtopic 360-10 disclosures.
Three transition methods are available. The prospective method applies the new guidance to costs incurred after adoption on all projects, including projects in progress. The modified method also applies prospectively, except that capitalized costs of in-process projects that met the old requirements but do not meet the new ones are derecognized through a cumulative-effect adjustment to opening equity. The retrospective method recasts comparative periods, with a cumulative-effect adjustment as of the beginning of the first period presented. Each method carries its own transition disclosures.
··········
HOW IAS 38 TREATS INTERNALLY DEVELOPED SOFTWARE.
IFRS has no standard dedicated to internal-use software. Computer software that is not an integral part of related hardware is an intangible asset within IAS 38, while software that a machine cannot operate without, such as an operating system embedded in equipment, is treated as part of the related property, plant and equipment under IAS 16.
For an internally generated intangible, IAS 38 splits the project into a research phase and a development phase. Paragraph 54 states that no intangible asset arising from research, or from the research phase of an internal project, shall be recognized, so those costs are expensed. When the two phases cannot be distinguished, the whole expenditure is treated as research.
Development costs are recognized as an asset only when the entity can demonstrate all of the conditions in paragraph 57: the technical feasibility of completing the asset so that it will be available for use or sale; its intention to complete and use or sell it; its ability to use or sell it; how the asset will generate probable future economic benefits; the availability of adequate technical, financial and other resources to complete the development and to use or sell the asset; and its ability to measure reliably the expenditure attributable to the asset during development. Costs incurred before all six are met stay in profit or loss and cannot be reinstated later. Training, selling and administrative costs are excluded from the cost of the asset. The broader treatment of research spending is covered in our article on how research and development costs are treated in financial reporting.
The IASB is also looking at the area. Its intangible assets project has included board papers in 2026 on how agile software development could be described, so IFRS preparers may see proposals in the future. For now the paragraph 57 conditions apply unchanged.
··········
ASC 350-40 VS IAS 38: SOFTWARE CAPITALIZATION COMPARED.
........
Topic | ASC 350-40 after ASU 2025-06 | IAS 38 |
Scope | Internal-use software | All intangibles, incl. software |
Start of capitalization | Funding committed and probable to complete | All six development conditions met |
Main hurdle | Significant development uncertainty | Technical feasibility and benefits |
Project stages | Removed | Research vs development phases |
Earlier costs | Expensed | Expensed, never reinstated |
Training and overhead | Expensed | Excluded from cost |
Asset class for disclosure | Subtopic 360-10 disclosures | Intangible asset disclosures |
Later measurement | Cost less amortization and impairment | Cost model or, rarely, revaluation |
........
In practice the two thresholds often fall at a similar point for routine software, because both require a funded project that the entity expects to finish and use. They tend to differ for innovative work. Under US GAAP the test is framed around unresolved uncertainty about novel features or unsettled requirements; under IAS 38 the entity must positively demonstrate technical feasibility and future economic benefits. A project can meet one framework's condition at a different moment from the other's, so dual reporters document the assessment separately under each.
··········
[[ADPLUS_300x250_1]]
WORKED EXAMPLE: INTERNAL-USE SOFTWARE JOURNAL ENTRIES.
A calendar-year US company adopts ASU 2025-06 on January 1, 2028. During the first half of the year it runs two internal projects, both authorized and funded by management at the start of the year. Project A is a procurement workflow platform with standard, well-understood functions and agreed requirements. Project B is an invoice-matching tool built on a novel matching approach that the team has not used before. Coding and testing resolve the uncertainty on Project B partway through the period. Both projects are ready for their intended use on July 1, 2028, with a useful life of five years and straight-line amortization.
........
Illustrative cost (USD) | Amount | Treatment |
Project A external developers | 240,000 | Capitalized |
Project A employee payroll | 360,000 | Capitalized |
Training of users | 25,000 | Expensed |
Data conversion | 30,000 | Expensed |
Allocated overhead | 40,000 | Expensed |
Project B before uncertainty resolved | 150,000 | Expensed |
Project B after uncertainty resolved | 210,000 | Capitalized |
Total | 1,055,000 |
........
Project A meets the threshold from the start because management has committed to funding it and it carries no significant development uncertainty, so its direct external and payroll costs of 600,000 are capitalized. Project B does not meet the probable-to-complete threshold until coding and testing resolve its novel feature, so the first 150,000 is expensed and only the later 210,000 is capitalized. Training, data conversion and overhead of 95,000 are expensed on both projects. Total capitalized cost is 810,000 and total expense before amortization is 245,000.
Annual amortization is 810,000 divided by five years, or 162,000. For the six months from July 1 to December 31, 2028 the charge is 81,000, leaving a carrying amount of 729,000 at year-end.
........
Entry | Account | Debit | Credit |
1. Project A costs | Software in development | 600,000 | |
Accounts payable | 240,000 | ||
Accrued payroll | 360,000 | ||
2. Training, conversion, overhead | Training expense | 25,000 | |
Data conversion expense | 30,000 | ||
General and administrative expense | 40,000 | ||
Cash | 95,000 | ||
3. Project B before threshold | Software development expense | 150,000 | |
Cash | 150,000 | ||
4. Project B after threshold | Software in development | 210,000 | |
Cash | 210,000 | ||
5. Ready for use, July 1 | Capitalized internal-use software | 810,000 | |
Software in development | 810,000 | ||
6. Amortization, July to December | Amortization expense | 81,000 | |
Accumulated amortization | 81,000 |
........
Debits and credits in the six entries each total 1,946,000. The schedule mechanics for an amortizing asset can be built in a spreadsheet in the same way as our capex and depreciation schedule in Excel.
Under IAS 38 the same facts can produce the same numbers if the company can demonstrate all six development conditions for Project A from the start and for Project B at the moment its uncertainty is resolved. If the IFRS assessment concluded that technical feasibility for Project B was demonstrated later than the US GAAP threshold was met, more of Project B's cost would be expensed under IFRS and the carrying amount would be lower.
For transition, suppose the company also had an in-process project with 120,000 capitalized under the legacy stage model, and that project still carries significant development uncertainty on January 1, 2028. Under the modified method the balance no longer qualifies and is derecognized against opening equity:
........
Account | Debit | Credit |
Retained earnings, opening (before tax effects) | 120,000 | |
Software in development | 120,000 |
........
Under the prospective method the 120,000 would remain on the balance sheet and only costs incurred after January 1, 2028 would follow the new threshold.
··········
COMMON ERRORS IN SOFTWARE CAPITALIZATION.
The most frequent error is capitalizing payroll on the basis of headcount rather than time actually spent on the project. Both frameworks limit capitalized payroll to employees directly working on the software and to the time they devote to it, so companies need time records or sprint logs that support the allocation. Allocated overhead and general administrative costs are a related trap, since neither framework lets them into the asset.
A second error is treating the start of a project as the start of capitalization. Under ASU 2025-06, funding approval alone is insufficient when the project includes unproven features or requirements that keep changing; under IAS 38, intention alone is insufficient without evidence of technical feasibility. A third is forgetting to start amortization when the software is ready for its intended use, especially when the team continues to add features after go-live. Ongoing enhancements need their own analysis, while maintenance is expensed.
Impairment also deserves attention. A project that is abandoned, or software that is no longer expected to be used as intended, must be assessed for impairment, and under IFRS an intangible not yet available for use is tested annually. The mechanics are covered in our article on how goodwill and intangible assets are tested for impairment under IAS 36 and ASC 350.
··········
INTERNAL-USE SOFTWARE CHECKLIST FOR CONTROLLERS.
Before closing the books on a software project, the finance team can work through a short list. Confirm that the project is internal-use and not a hosting arrangement or software to be sold. Record the date management with authority committed funding and keep the approval. Document whether any feature is novel or unproven and when coding and testing resolved it, and whether the significant performance requirements are identified and stable. Track payroll by time spent on the project. Separate training, data conversion, overhead and maintenance from capitalizable cost. Record the date the software is ready for intended use and set the useful life. For IFRS reporting, document each of the six IAS 38 development conditions with its own evidence and date.
··········
ASU 2025-06 AND IAS 38: WHERE JUDGEMENT REMAINS.
ASU 2025-06 settles the mechanics of the US model: stages are gone, capitalization starts at a funded, probable-to-complete project, significant development uncertainty defers it, Subtopic 350-50 is folded into Subtopic 350-40, and Subtopic 360-10 disclosures apply to all capitalized internal-use software. The effective date for annual periods beginning after December 15, 2027 and the three transition methods are fixed in the standard.
The open questions sit in the facts of each project. Whether a feature is novel or unproven, when testing has resolved the uncertainty, how stable the requirements are and how much engineering time is really spent on the software are judgements that the entity has to evidence. Under IAS 38 the equivalent judgement is when technical feasibility and probable future benefits can be demonstrated. Companies reporting under both frameworks will often reach the same carrying amount for routine projects and different ones for innovative work, and the documentation behind each date is what auditors will examine first.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
