In most states, a custom software sales tax exemption applies when the buyer is paying for a developer’s original coding and analysis rather than buying an off-the-shelf product. Roughly three dozen states treat genuinely custom software as a nontaxable professional service; about a dozen tax it regardless of how it’s built or delivered. Whether your project actually qualifies depends on how your jurisdiction classifies the transaction, how the contract and invoices are structured, and whether your paper trail can survive an audit.
What Qualifies as Custom Software
The cleanest definition comes from the Streamlined Sales and Use Tax Agreement, which 24 states have adopted. Under the SSUTA, prewritten software is any program “not designed and developed by the author or other creator to the specifications of a specific purchaser.”1Alaska Remote Sellers Sales Tax Commission. Streamlined Sales and Use Tax Agreement – Article I Definitions Custom software is the opposite: a program built from scratch for one buyer’s requirements after an assessment of that buyer’s needs.
Auditors look for specific markers before accepting a custom classification. The developer should have performed original coding and systems analysis, not simply installed or configured an existing product. A discovery phase documenting the buyer’s unique requirements strengthens the position. Intellectual property that transfers to the buyer, or an exclusive license for that buyer’s use, supports it further. Contracts should make clear the software is not intended for resale or general distribution.
That last point matters more than most buyers realize. Under the SSUTA, software originally built for a specific buyer becomes prewritten software the moment it’s sold to someone else.1Alaska Remote Sellers Sales Tax Commission. Streamlined Sales and Use Tax Agreement – Article I Definitions A developer who builds a custom inventory system for one client and later licenses a copy to a second client has created a taxable product on that second sale. Combining two or more prewritten programs also doesn’t produce custom software under the SSUTA.
Delivery method can matter too. Most exempting states preserve the exempt status whether the software arrives electronically, on physical media, or through on-site installation. A smaller group only exempts custom software when it’s delivered electronically, taxing the identical program if it’s handed over on a hard drive or disc.
When a transaction sits in a gray area, many taxing authorities apply a “true object test” to decide whether the buyer’s primary purpose was obtaining professional services or acquiring a tangible product.2Multistate Tax Commission. Taxation of Digital Products Uniformity Project – Draft White Paper on Bundling If the contract’s main goal is the developer’s engineering work, the transaction is typically exempt. If the main goal is receiving the finished product itself, it may be taxable. That sounds academic, but it’s how auditors evaluate large development contracts.
Modifications to Prewritten Software
Pure custom builds get the cleanest treatment. Hybrid projects are harder. When a developer takes existing software and modifies it for a specific buyer, the SSUTA draws a critical line: the prewritten software remains prewritten, but any separately stated charge for the modification work is not treated as prewritten software.1Alaska Remote Sellers Sales Tax Commission. Streamlined Sales and Use Tax Agreement – Article I Definitions “Separately stated” does the heavy lifting in that sentence.
In practice, invoice structure determines how much tax you owe. If the developer lists the base software license and the modification labor as separate line items, only the base software is taxable. If those charges are bundled into a single price, the entire amount is typically taxable. Same economic transaction, same total dollars, very different tax outcomes.
Some jurisdictions add a percentage threshold. If the modification work accounts for more than 50 percent of the total contract price and the charges are not separately stated, the entire package may qualify as custom software and escape tax altogether. That rule helps buyers who are paying primarily for engineering rather than for a license to someone else’s code. Relying on the threshold is riskier than simply separating the charges, though, since itemization works across far more jurisdictions and doesn’t require hitting a specific ratio.
Maintenance, Training, and Related Services
Post-deployment agreements create their own tax questions. The general rule turns on two factors: whether the contract is mandatory or optional, and whether it includes software updates or only human support.
A mandatory maintenance contract, one the buyer must purchase as a condition of the software sale, is almost universally treated as part of the software’s purchase price. If the underlying software is taxable, the mandatory maintenance is taxable too. Optional maintenance contracts split further:
- Contracts covering only help desk support, troubleshooting, and technical assistance, with no updates, are generally treated as nontaxable professional services.
- Contracts that entitle the buyer to future releases, patches, or upgrades are typically taxed as a sale of software.
- Contracts that bundle both without itemization are typically taxable in full. Separating the charges can preserve the exempt status of the support portion.
Training, data migration, workflow consulting, and system integration follow similar logic. These services are generally nontaxable when the computer serves merely as a tool to complete a professional engagement. Data processing services, where the vendor enters, stores, manipulates, or retrieves a customer’s data using its own systems, are taxable in a number of states.
Mixed contracts need careful allocation. The nontaxable portion has to be a distinct, identifiable service commonly offered on its own, and it must be billed separately. Some states apply a de minimis rule: if the taxable component is 5 percent or less of the total contract, no tax needs to be collected. Above that, the entire charge becomes taxable unless line items are broken out. The practical rule across every category of software spending is the same. Itemize everything. Lump-sum invoices are the single most common reason businesses overpay sales tax on software projects.
SaaS Sits Outside This Framework
Cloud-hosted software sold as a subscription doesn’t fit the custom-versus-prewritten framework at all. In a SaaS arrangement, no copy of the program is transferred; the buyer accesses the software remotely and the vendor keeps everything on its own servers.
States have taken widely different approaches. Roughly 25 jurisdictions tax SaaS in some form as of 2025, while the rest either exempt it or haven’t directly addressed it. Among the taxing states there’s no shared theory. Some classify SaaS as tangible personal property, others as a taxable digital service, others as a taxable data processing service. Some distinguish between business and personal use. At least one state taxes SaaS when provided under a license agreement but may exempt it when structured as a service agreement.
Even if the underlying software was custom-built, the SaaS delivery model can trigger a different tax classification entirely. A business shifting from on-premise custom software to a cloud-hosted model needs to reassess its position in every state where it has users.
Which State’s Tax Applies
For sellers operating across state lines, knowing which state’s tax applies matters as much as knowing whether the transaction is taxable. Under SSUTA sourcing rules, tax on software is generally determined by where the buyer receives the software, not where the developer is located. For electronically delivered software, “receipt” typically means where the buyer first downloads or uses it. When receipt isn’t clear, the SSUTA runs through a hierarchy: the seller’s business location if delivery happened there, then the buyer’s location, then the buyer’s address in the seller’s records, then the payment instrument address, and finally the transmission origin.3Streamlined Sales Tax Governing Board. Rules and Procedures Not every state follows the SSUTA framework; a small number use origin-based sourcing, where the seller’s location controls.
Documentation the Exemption Depends On
An exemption is only as strong as the paper trail behind it. When an auditor reviews a software purchase, they’re looking for evidence that the project was genuinely custom and that the charges were properly structured. Build the documentation during the project, not after an audit notice arrives.
The core records are a Master Service Agreement and a detailed Statement of Work that describe the buyer’s specific business requirements, the scope of original development, and the technical approach. These should make clear the developer is performing original coding, not installing or configuring an existing product. Invoices need to match the contract, breaking out hourly rates for engineering labor separately from any flat fees for prewritten software licenses. When customization is itemized at reasonable rates and stated separately from software license fees, the customization charges are generally exempt.
Consistency across the contract, invoices, and any exemption certificate is what keeps an audit from turning into a dispute.
How to Claim the Exemption or Get a Refund
The simplest approach is to give your vendor a completed exemption certificate before the transaction closes, which prevents tax from being collected in the first place. The Streamlined Sales Tax Certificate of Exemption is accepted across all 24 SSUTA member states. Non-member states have their own forms available through the state revenue department. When completing the form, select the category for professional services or custom software development, and use language that matches the terms in your Master Service Agreement.
If tax was already collected on a project that should have been exempt, most states allow a refund claim filed directly with the state revenue department, typically through an online tax portal or by certified mail to the refund division. Most states impose a three- to four-year window from the date of purchase to file. Missing that window forfeits the refund, no matter how clear the exemption is. For projects paid in installments, the deadline may run separately from each payment rather than from the contract signing date, so track each payment’s refund window.
After submission, expect a review that can stretch several months. The state may issue a verification inquiry or run a limited audit to confirm the software meets custom definitions, and agents will review the technical specifications, labor hours, and contract structure from the original development agreement. Having that documentation already organized is what separates a routine review from a prolonged dispute.