Under US GAAP, development costs are expensed as incurred, with software as the main exception; under IFRS, development costs must be capitalized as an intangible asset once a project meets six specific criteria. That single difference is the heart of the development costs question in GAAP vs. IFRS, and it can push two otherwise identical companies to report very different earnings, asset bases, and cash flow profiles.
Research and Development Are Not the Same Thing
Both frameworks split R&D spending into two phases, and the split drives the accounting. Research is the exploratory work: lab experiments, literature reviews, testing new theoretical approaches. Development starts when a company takes what it learned and begins building something concrete, such as a prototype, a pilot plant, or a working software model.
The reason for the line is uncertainty. During research, no one can say whether the work will produce anything commercially useful. Once a project reaches development, the company has enough knowledge to aim at a specific product or process, which reduces (without eliminating) the risk that the spending will be wasted. That drop in uncertainty is what opens the door to capitalization under IFRS, and to the narrower software exceptions under US GAAP.
US GAAP: Expense R&D as Incurred
ASC 730, the FASB’s codified R&D standard, sets a blunt baseline. All R&D costs are charged to expense when incurred.1Internal Revenue Service. Appendix E – Directive Definitions That covers researcher salaries, materials consumed in testing, overhead allocated to R&D activities, and depreciation on equipment used solely for R&D. There is no general option to capitalize development costs the way IFRS provides.
The exceptions are narrow. ASC 730 does not apply to software development costs, R&D performed under contract for a third party, or intangible assets acquired in a business combination. Materials, equipment, and facilities with alternative future uses beyond a single R&D project can be capitalized and depreciated normally, with the R&D portion expensed as those assets are used.
IFRS: Capitalize Development Costs Once Six Criteria Are Met
Companies reporting under IFRS follow IAS 38, which takes a different route once a project leaves the research phase. Research costs are still expensed immediately. Development costs, however, must be capitalized as an intangible asset when the company can demonstrate all six of the following:
- Technical feasibility of completing the asset so it will be available for use or sale.
- Intent to complete the asset and either use it or sell it.
- Ability to use or sell it, supported by a market or a defined internal use.
- Probable future economic benefits, whether through revenue or cost savings, that exceed the development costs.
- Adequate financial, technical, and other resources to finish development and bring the asset to market.
- Reliable measurement of the expenditures attributable to the development phase.
All six must be met at the same time. Costs incurred before that point are expensed. Once the criteria are satisfied, capitalization is not optional; the company is required to begin recording qualifying development costs as an intangible asset. This mandatory capitalization is the single largest reason two identical companies can post very different earnings depending on which framework they report under.
Software Is Where US GAAP Diverges
Software is the biggest carve-out from the expense-everything default. The rules depend on whether the software is being built to sell or license to customers, or for the company’s own internal use.
Software Built for Sale or License
Under ASC 985-20, costs are expensed as R&D until the project reaches technological feasibility. The bar is precise and demanding: the company must have completed all planning, designing, coding, and testing needed to confirm the product can be built to meet its design specifications.2U.S. Securities and Exchange Commission. Note 1 – Summary of Significant Accounting Policies: Software Development Costs In practice, that means either a detailed program design that has been reviewed and validated, or a completed working model that has been tested against the product design.
After technological feasibility, the company capitalizes programmer salaries, testing, and materials until the product is available for general release. Costs incurred after release go back to expense. Because the feasibility bar is high, most software companies still expense the majority of their development spending. A beta release for customer testing is often the practical marker, though the required evidence depends on how the company develops the product.
Internal-Use Software
ASC 350-40 governs software built for the company’s own operations. Under the current stage-based framework:
- Preliminary project stage costs are expensed. This covers evaluating alternatives, selecting vendors, determining functionality, and deciding whether to proceed.
- Application development stage costs are capitalized when directly tied to building the software, including coding, configuration, testing, and direct employee labor. Training and data conversion are expensed even during this stage.
- Post-implementation costs are expensed. Routine maintenance, bug fixes, and minor tweaks do not extend the asset’s value.
Capitalization begins when the preliminary stage is complete, management has authorized and committed to funding the project, and it is probable the project will be completed and the software will perform its intended function. Capitalization ends when the software is substantially complete and ready for use.
Cloud Computing Arrangements
When a company accesses software through a hosting arrangement rather than owning it, ASC 350-40 still applies to the implementation costs. Custom coding, configuration, system integration, and data migration essential to bringing the system online can be capitalized during the application development stage. Ongoing subscription fees, staff training, and routine maintenance are expensed as incurred. Capitalized implementation costs are amortized over the term of the hosting arrangement rather than a traditional useful life.
ASU 2025-06 Removes the Stage Framework
The FASB issued ASU 2025-06 to simplify the internal-use software rules. The update removes all references to the three development stages, making the guidance neutral to how a company actually builds software, including agile and other non-linear methods.3FASB. FASB Issues Standard That Makes Targeted Improvements to Internal-Use Software Guidance Under the new rules, capitalization hinges on two criteria: management has authorized and committed to funding the project, and it is probable the project will be completed and used as intended. The update is effective for annual reporting periods beginning after December 15, 2027, with early adoption permitted.4FASB. Accounting Standards Update Effective Dates Companies that have not early adopted continue to apply the current stage-based framework through their 2027 fiscal year.
After Capitalization: Amortization and Impairment
Once development costs qualify for capitalization, they sit on the balance sheet as an intangible asset. That asset is then amortized, meaning its cost is spread as an expense across the periods that benefit from it.
The amortization method should reflect how the company actually consumes the asset’s economic benefits. Straight-line is standard when value is delivered relatively evenly over time. For software sold to customers, companies sometimes tie amortization to the ratio of current-period revenue to total expected revenue from the product, which front-loads the expense when sales are highest. Straight-line is the default when the consumption pattern cannot be reliably estimated.
The amortization period is the asset’s useful life. If a legal constraint such as a patent term is shorter than the expected useful life, the asset’s value effectively ends when the legal protection does, and the amortization period cannot exceed that limit. Useful life is reassessed at each reporting period. If circumstances change, the remaining carrying amount is amortized over the revised, shorter period going forward, treated as a change in estimate rather than a restatement.
Capitalized development costs are finite-lived intangibles, so they do not require annual impairment testing. Instead, a company tests for impairment when a triggering event signals that the carrying value might not be recoverable. Common triggers include a sharp drop in market value, a major change in how the asset is being used, negative shifts in the legal or competitive environment, costs running significantly over budget, or continuing operating losses tied to the asset.
When a trigger occurs, the company compares the asset’s carrying value to the undiscounted future cash flows it expects the asset to generate. If carrying value exceeds those cash flows, the asset is impaired and written down to fair value, with the difference recorded as an impairment loss. Under US GAAP, the write-down is one-way. Once reduced, the asset’s value cannot be written back up even if conditions later improve. A project that is genuinely abandoned is written off in full.
Tax Treatment Runs on Its Own Track
The tax rules for R&D operate independently of the accounting treatment, and the domestic-versus-foreign distinction now matters more than the book-versus-tax one.
Domestic research and experimental expenditures can be fully deducted in the year they are paid or incurred. Congress enacted Section 174A as part of the One Big Beautiful Bill Act, permanently restoring immediate expensing for domestic R&D spending for tax years beginning after December 31, 2024.5Office of the Law Revision Counsel. 26 U.S. Code 174A – Domestic Research or Experimental Expenditures That reversed the TCJA provision that had required five-year amortization of domestic R&D costs starting in 2022.
Foreign research and experimental expenditures do not get the same treatment. R&D costs attributable to research conducted outside the United States must still be capitalized and amortized over 15 years under Section 174. Companies with multinational R&D operations need to carefully allocate spending between domestic and foreign activities, because the tax impact runs in very different directions. Software development costs follow these same Section 174 rules for tax purposes regardless of how they are treated on the GAAP or IFRS financial statements.
Why the Framework Choice Moves the Numbers
The practical impact is larger than most people expect. Identical spending on the same type of project can produce very different reported earnings, cash flows, and asset bases depending on which framework the company follows. An IFRS company that capitalizes development costs shows higher current-period income, because those costs do not hit the income statement right away, but carries a larger intangible asset that eventually flows through as amortization expense. A US GAAP company expensing the same costs immediately reports lower current earnings and no future amortization drag.
For anyone comparing companies across frameworks, headline earnings are not directly comparable without adjusting for the R&D treatment. For finance teams deciding how aggressively to pursue capitalization, particularly for software, the classification affects reported profitability, EBITDA, and debt covenants tied to financial ratios. Getting it wrong in either direction, whether capitalizing costs that should be expensed or expensing costs that qualify for capitalization under IFRS, can trigger restatements and regulatory scrutiny.