Whether software is a good or a service depends on how it is delivered and how much of the price pays for the code itself versus someone’s labor. A boxed program or a one-time download of a standard application is usually treated as a good under Article 2 of the Uniform Commercial Code. A cloud subscription or a custom-built program is usually treated as a service under common law. The classification is not academic: it decides what warranties come with the software, how long you have to sue, and in many states whether sales tax applies.
The Predominant Purpose Test
UCC Article 2 governs the sale of goods, which the statute defines as things that are movable at the time they are identified to the contract.1Legal Information Institute. UCC 2-105 – Definitions: Transferability; Goods; Future Goods; Lot; Commercial Unit Software deals rarely fit neatly on one side. A company buying accounting software often pays for installation, data migration, and training in the same contract.
When goods and services are bundled, courts apply the predominant purpose test to decide which body of law governs the whole agreement. The question is simple: was the main point of the contract to acquire a finished product, or to pay for someone’s labor and expertise? Courts look at the language of the agreement, how the price breaks down between the software and the surrounding services, and whether those services are merely incidental to delivering the product. If most of the value sits in the code rather than the consulting, the UCC usually applies.2Michigan Law Review. Installation Failure: How the Predominant Purpose Test Has Perpetuated Softwares Uncertain Legal Status Under the Uniform Commercial Code
When Software Is a Good
Software looks most like a good when it is mass-produced, sold in a standard form, and delivered in a finished state before any particular customer shows up. The industry calls this “canned” software. A one-time download of a standard application, or a boxed copy off a shelf, sits comfortably in this category.
The leading case is Advent Systems Ltd. v. Unisys Corp., in which the Third Circuit held that software qualifies as a good under the UCC. The court reasoned that while a program originates as intellectual work, once it is embedded in a medium and distributed commercially it becomes a tangible, movable commodity similar to a book or a music recording. The court also pointed out that the UCC’s definition of goods explicitly includes specially manufactured items, so the fact that a program can be tailored does not by itself remove it from Article 2.3Justia. Advent Systems Limited v. Unisys Corporation, 925 F2d 670
One wrinkle: most commercial software transactions are structured as licenses rather than outright sales. The box says “License Agreement,” not “Bill of Sale.” Courts have generally treated that as a labeling question. When the economic reality is that the buyer receives a copy of finished software and uses it indefinitely, courts tend to apply UCC Article 2 whether the paperwork calls the deal a license or a sale.3Justia. Advent Systems Limited v. Unisys Corporation, 925 F2d 670
When Software Is a Service
Cloud-based subscriptions are the clearest example of software treated as a service. In a SaaS arrangement, the user never receives a permanent copy of anything. The code runs on the provider’s servers, and the buyer is paying for ongoing access, maintenance, security patches, and hosting. Cancel the subscription and the software goes away. The value of the deal is continuous performance, not a delivered object.
Custom-built software falls on the same side of the line for a different reason. When a business hires a developer to write a program from scratch, the buyer is paying for skilled labor: analyzing requirements, writing unique code, debugging, and integrating the result. No finished product exists when the contract is signed. Because the essence of the deal is the developer’s expertise, common law service rules govern and the UCC steps aside.
Both categories sit outside Article 2, but they create different legal relationships. A SaaS provider’s obligations are defined almost entirely by the subscription agreement and any service-level terms. A custom development dispute turns on whether the developer performed the work competently.
What Changes When Software Is a Good vs. a Service
The classification is worth arguing about because three things move with it: what warranties come along automatically, what you can do if the software is defective, and how long you have to bring a claim.
Implied Warranties
When software qualifies as a good, the seller automatically guarantees that it is fit for the ordinary purposes for which such products are used.4Legal Information Institute. UCC 2-314 – Implied Warranty: Merchantability; Usage of Trade This implied warranty of merchantability applies even if the contract never mentions it. If a word processor crashes every time a user tries to print, or a payroll application miscalculates withholding, the buyer can pursue damages under this warranty without having to prove the seller was careless.
When software is a service, no implied warranty of merchantability attaches. Instead, the provider is held to a general standard of professional care. To recover, the buyer has to show the developer or provider fell below the skill level a reasonable professional in the same field would have met. That is a harder case, because the buyer must first establish the industry standard and then prove the provider failed to meet it.
Sellers of goods can disclaim the implied warranty of merchantability, but the UCC makes that deliberately hard. Any disclaimer must specifically use the word “merchantability,” and in a written contract it must be conspicuous.5Legal Information Institute. UCC 2-316 – Exclusion or Modification of Warranties Fine print buried in a dense paragraph will not do it. That is why so many software EULAs print their warranty disclaimers in all caps.
Rejection and the Seller’s Right to Cure
UCC Article 2 gives the buyer of goods the perfect tender rule. If the software fails to conform to the contract in any respect, the buyer can reject the whole delivery, accept the whole delivery, or accept part and reject the rest.6Legal Information Institute. UCC 2-601 – Buyers Rights on Improper Delivery “Any respect” is a low bar, and it gives buyers real leverage when software ships with bugs or missing features.
The seller gets a chance to fix things. If the time for performance has not yet run out, the seller can notify the buyer of an intent to cure the defect and then deliver a conforming version within the contract deadline. Even after the deadline, if the seller had reasonable grounds to believe the original delivery would be acceptable, it can take a further reasonable time to substitute a conforming version.7Legal Information Institute. UCC 2-508 – Cure by Seller of Improper Tender or Delivery; Replacement The back-and-forth between rejection and cure is a structured process that does not exist under common law service rules.
Service contracts have no equivalent to the perfect tender rule. Whether a custom developer’s work is deficient turns on a reasonableness analysis, and there is no automatic right to reject a deliverable outright over a minor shortcoming.
Filing Deadlines
The UCC sets a fixed four-year statute of limitations for contracts involving the sale of goods, running from the date the breach occurs. For a warranty breach, the clock starts when the software is delivered, unless the warranty explicitly extends to future performance. The parties can agree to shorten this window to as little as one year, but they cannot extend it.8Legal Information Institute. UCC 2-725 – Statute of Limitations in Contracts for Sale
Service contracts follow state-specific limitations periods that vary widely. Written service contracts typically carry deadlines ranging from four to six years in most states, while oral agreements are often limited to two to four years. The UCC’s uniform four-year period is one of the practical advantages of goods classification, because both sides know exactly how long exposure lasts regardless of which state’s law applies.
Sales Tax Treats Software on Its Own Terms
Tax authorities classify software independently of the UCC, and the categories do not always match. A program a court treats as a good for warranty purposes may be tax-exempt in one state and fully taxable in another.
A majority of states treat prewritten software as tangible personal property subject to sales tax, whether the buyer gets a physical disc or a download. Roughly 37 jurisdictions tax prewritten software delivered electronically. Combined state and local rates typically fall between 4% and 10%. A smaller number of states still draw a line at electronic delivery, taxing software shipped on physical media but exempting the same code delivered as a download. That distinction has been shrinking as states update their rules.
Custom software is generally exempt from sales tax in a majority of states. The logic tracks the UCC analysis: when the buyer pays primarily for a developer’s labor rather than a finished product, tax authorities treat the transaction as a nontaxable service. A handful of states tax all software regardless of customization, so the exemption is not universal.
SaaS is the most unsettled category. Roughly 24 states tax SaaS in some form, and the count has been rising as legislatures adapt to cloud business models. States that tax SaaS sometimes apply the full sales tax rate and sometimes create a separate, lower rate. Whether the subscriber is a business or a consumer can also matter. A SaaS company selling nationally has to track each state’s current rules individually.
Physical presence is not required for a sales tax obligation. After the Supreme Court’s 2018 decision in South Dakota v. Wayfair, states can require remote sellers to collect sales tax once they exceed a threshold level of activity in the state. The most common threshold is $100,000 in annual sales, and many states that originally paired that figure with a 200-transaction alternative have dropped the transaction count. For a SaaS company selling $15-per-month subscriptions across the country, crossing $100,000 in a given state triggers a collection obligation there. Missing the threshold means back taxes plus penalties and interest calculated from the date the obligation should have started.
Federal Income Tax Treatment Runs on a Different Track
Federal income tax rules treat software costs based on what the taxpayer is doing with the software: developing it, buying it, or subscribing to it.
For domestic software development, the One Big Beautiful Bill Act, signed in July 2025, restored immediate expensing for tax years beginning after December 31, 2024. Companies can now deduct domestic research and development expenditures, including software development costs, in the year they are incurred. This reverses the Tax Cuts and Jobs Act rule that had required capitalizing those costs and amortizing them over five years from 2022 through 2024. Developers who capitalized costs during those years may want to review whether amended returns or catch-up adjustments are available.
Software development performed outside the United States does not get the same treatment. Foreign research expenditures must still be capitalized and amortized over 15 years.9IRS.gov. Guidance on Amortization of Specified Research or Experimental Expenditures under Section 174 For companies that offshore development, the gap between immediate deduction and a 15-year amortization schedule is a real cash-flow difference.
Buying software is treated differently from developing it. The IRS does not consider purchasing and installing prewritten software to be a research or development activity, so Section 174 does not apply to those costs.9IRS.gov. Guidance on Amortization of Specified Research or Experimental Expenditures under Section 174 Purchased software is typically depreciated or amortized under separate rules. SaaS subscription fees are generally deductible as ordinary business expenses in the year paid, since the company is paying for a service rather than acquiring an asset.