IRS Notice 2023-63 Software Development Safe Harbors

Notice 2023-63 explained

Section 174 no longer gives companies a choice about how to treat research and development costs. For software developers, that shift landed with unusual force, because IRS Notice 2023-63 is the government's attempt to explain what "capitalize your software development costs" means once you get past the statute and into the messy reality of internal tools, dual-purpose platforms, and code written under contract. Get the classification wrong and you haven't just shifted a deduction by a year or two. You've locked in the wrong answer for five years, or fifteen, with almost no path to undo it later.

The stakes trace back to a policy reversal buried inside the Tax Cuts and Jobs Act of 2017. Before TCJA, taxpayers had real flexibility: research and experimental expenditures could be deducted immediately, capitalized and amortized over a period no shorter than 60 months, or charged to a capital account entirely, whichever suited the business at the time. TCJA eliminated that choice. For taxable years beginning after December 31, 2021, SRE expenditures must be capitalized and amortized, no exceptions, with domestic costs spread over 5 years and foreign costs stretched across 15, starting at the midpoint of the year the costs are paid or incurred. The change that's easiest to miss, and the one that matters most here, is that TCJA folded software development directly into the statutory definition of SRE expenditures, a category that had never squarely applied to most software taxpayers before.

Released on September 8, 2023, the Notice is interim guidance. The IRS is signaling how it plans to write the eventual proposed regulations and inviting taxpayers to rely on that signal in the meantime. It applies to taxable years ending after September 8, 2023, though taxpayers can adopt it early if they want to.

The Notice covers seven areas: capitalization and amortization mechanics for SREs, the scope of what counts as an SRE expenditure, software development specifically, short taxable years, research performed under contract, disposition and retirement and abandonment of the underlying property, and long-term contracts under Section 460, alongside a companion discussion of cost-sharing arrangements under Section 482. That's a lot of ground for one notice to cover, and it reflects just how much TCJA left unanswered when it rewrote Section 174.

One procedural detail changes how much of this taxpayers actually have to swallow at once. As originally issued, the Notice demanded all-or-nothing reliance: adopt every provision consistently, or rely on none of it. Notice 2024-12 loosened that into a meaningful easing of the original all-or-nothing standard, letting taxpayers pick which provisions to follow, as long as whatever they adopt gets applied consistently from then on. That's a real shift in compliance posture. A company can now rely on the contract research rules in Section 6 without also committing to the dual-function software safe harbor, something the original notice simply didn't allow.

SRE expenditure inclusions and exclusions

The Notice lists categories of cost that count as SRE expenditures, and the list isn't exhaustive. That alone tells you the IRS wants this definition read broadly, not narrowly. Labor costs are the largest bucket, and they reach well past base salary: vacation pay, holiday pay, sick leave, payroll taxes, pension costs, and employee benefits all count. Severance is the one labor cost carved out. Materials and supplies count too, along with cost recovery allowances (depreciation, amortization, or depletion on property used in or supporting SRE activities), patent costs, certain operating and management costs like rent, utilities, insurance, taxes, repairs, and security on facilities supporting SRE work, and travel costs.

The exclusions tell you just as much. Interest expense used to finance research doesn't count as an SRE cost. Domain registration and website hosting sit outside the definition, which matters a great deal for any company that treats its web presence as core product infrastructure rather than overhead. General and administrative costs that only indirectly support research are excluded as a whole category: payroll staff cutting checks for research employees, HR staff hiring researchers, accounting staff booking research expenses. None of that counts, no matter how essential those functions feel to the business. Quality control, advertising, and promotion costs are excluded as well.

For software companies running large shared-services functions, that G&A exclusion isn't a footnote. It strips out an entire category of cost that would otherwise demand painstaking sub-allocation across research and non-research activities, sprint by sprint, team by team. What the Notice doesn't hand taxpayers, though, is a simplified method for the allocations that remain after the exclusions are applied. Companies still have to apply a "cause and effect" standard, the same facts-and-circumstances test borrowed from the UNICAP regulations, cost by cost, with no formula and no safe harbor to shortcut the work.

The Notice's definitions of "computer software" and "software development" for Section 174 purposes

Section 5.02(1) broadens the definition of "computer software" relative to prior guidance, and the update matters because it folds in cloud computing arrangements along with updates and enhancements to existing programs. "Upgrades and enhancements" get their own definition: modifications to existing software, including software the taxpayer bought rather than built, that add functionality or materially speed up or improve the program's efficiency. A patch that fixes a bug without adding capability or measurably improving performance sits outside that definition. A rewrite that adds a new feature or cuts processing time sits inside it. That distinction is not cosmetic; it decides whether an entire sprint's labor cost gets capitalized or expensed.

Section 5.03 spells out which activities count as "software development" under Section 174(c)(3): planning the development, designing it, building a model, writing source code, certain testing, and, only for software built to be sold or licensed to others, production of product masters. Development of updates and enhancements that add new functionality or materially increase speed or efficiency counts as well.

The Notice draws one clean line through all of it. Work done before the software, or the update, or the enhancement, is released commercially falls inside the development definition. Work done after release generally does not. That line carries more weight than it looks like on paper. A team patching bugs in a shipped product after launch sits, in most cases, outside the capitalization regime for that specific work, while work on the next major version of that same product is squarely inside it.

The three-category framework: internal-use, dual-function, and non-IUS software, and its classification consequences

Notice 2023-63 doesn't invent a new taxonomy here. It carries forward a distinction that's existed in software tax law for years, sorting code into three buckets based on who actually uses it.

Internal-use software (IUS) is built for the taxpayer's own general and administrative functions, things like HR systems, payroll, and accounting platforms, and isn't meant for sale, lease, or license to outside parties. IUS has historically faced additional scrutiny under tax law, a distinction carried forward in how the Notice addresses software classification.

Non-IUS software, meaning code built to be sold or licensed to others, sits most cleanly inside the capitalization framework. The activities in Section 5.03, writing code, testing, producing product masters, map directly onto this category, since it's the paradigm case the relevant lawmakers had in mind when they folded software development into the SRE definition.

Dual-function software (DFS) is the hard case, and it's fast becoming the common one. One codebase serves two masters here: the company runs its own operations on it, and third parties use the same infrastructure as paying customers. A SaaS platform that both runs a company's internal operations and gets sold to customers as a subscription product is dual-function software, and untangling which lines of code, which sprints, which engineer-hours belong to the internal function versus the third-party function rarely comes apart cleanly when it's the same platform doing both jobs at once.

The dual-function software safe harbor in practice

Rather than force a full facts-and-circumstances split on every dual-function project, the Notice borrows a mechanism already built into the Section 41 research credit regulations. Under that framework, the taxpayer can include 25% of qualified research expenses in the dual-function pool (or a defined subset of DFS elements) when computing the credit, subject to certain conditions.

Notice 2023-63 imports that same logic into Section 174. Where a precise split between internal and third-party use isn't feasible, the safe harbor substitutes a fixed 25% figure for a line-by-line allocation exercise that would otherwise burn through enormous compliance resources.

A company that can actually substantiate a more precise breakdown of DFS costs by function may use its real numbers instead of the flat percentage; the safe harbor exists for the cases where that precision isn't achievable. It only applies, too, after a genuine attempt has been made to separate out third-party-use costs first. It applies to the portion of dual-function costs remaining after any identifiable third-party-use costs have been addressed, rather than the full gross cost of the dual-function project. Proper application of the safe harbor depends on following the framework as the Notice describes it, not treating the 25% figure as an unconditional default.

Contract research: when the party writing the code must capitalize its own costs

Section 174 itself says nothing explicit about research performed under contract, an odd gap given how much software development actually happens through outsourced or contracted teams. Section 6 of the Notice steps into that gap.

Two separate triggers force the research provider (the party actually hired to write the code or run the experiments) to capitalize its own costs as SRE expenditures. The first is financial risk: if the contract puts the risk of loss on the provider should it fail to deliver the promised product, that risk allocation alone requires capitalization. The second is exploitation rights: if the provider walks away with the right to use the resulting product in its own business, or to sell, lease, or license it further, without needing anyone else's sign-off, that right alone triggers capitalization too. Either trigger works on its own. A provider doesn't need both financial risk and exploitation rights to land in the capitalization regime, just one is enough.

Notice 2024-12 narrowed this. It clarified that a research provider has no SRE expenses if it bears no financial risk under the contract and any rights it picks up were either separately negotiated and paid for, or granted only for the limited purpose of letting it perform the contracted SRE work. That's a real refinement for contract developers and staffing arrangements, since it separates rights a contractor genuinely earns as compensation for risk from rights that are just incidental to doing the job it was hired to do.

Disposition, abandonment, and the problem of unrecovered capitalized costs

Section 174(d), as TCJA rewrote it, is blunt: no deduction is allowed for SRE expenditures just because the underlying property gets disposed of, retired, or abandoned. Amortization keeps running on its original schedule no matter what happens to the asset itself.

The Notice largely confirms that reading. Capitalized SRE costs keep amortizing over whatever period remains, even after the property has been sold or abandoned, and there's no mechanism to recover unamortized basis when the sale happens. The Notice identifies only a narrow exception to this rule, applicable in limited circumstances involving a corporation's cessation of existence.

Practitioners have pushed back on this reading, and the pushback holds up. Take a company that spends $100,000 developing a piece of software and later sells the resulting intellectual property for $80,000, a straight-up economic loss. Under the Notice's approach, that company can't offset the sale proceeds with its remaining unamortized cost basis, so the taxable gain calculated on the transaction diverges from the real economic outcome, sometimes showing a gain where the company actually lost money. Critics have argued that outcome sits uneasily with the statutory text of Section 174(d) itself, and in more extreme scenarios, with the constitutional definition of income underlying the whole federal income tax system. That tension remains unresolved. It's one of the clearest signs that Notice 2023-63, for all its detail, is a bridge to future regulations rather than a final answer, and taxpayers relying on it should plan for that bridge to move under them.