The Trade Agreements Act for Software Companies: Country of Origin, Explained
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
Sooner or later a reseller, a prime or a GSA Schedule offer asks your software company a question you may never have considered: where is your product from? The question comes from the Trade Agreements Act, and on many federal contracts the answer decides whether your product can be offered at all.
For a company whose engineers sit in the United States, the answer is usually easy. For a company with development teams spread across several countries, it takes some thought. This guide explains what the Trade Agreements Act requires, how origin is decided for software, how it relates to the Buy American rules, and how to certify with confidence.
What the Trade Agreements Act does
The Trade Agreements Act of 1979 lets the United States meet its commitments under international procurement agreements, chiefly the World Trade Organization Government Procurement Agreement and the government procurement chapters of US free trade agreements. In federal contracting it works as a restriction. On covered acquisitions, agencies may buy only US-made or designated country end products and services.
The rules live in FAR Subpart 25.4. Whether a particular acquisition is covered depends on its estimated value against a threshold the US Trade Representative adjusts every two years, plus a list of exceptions. Check the current figure in FAR 25.402 rather than relying on a number you remember.
Designated countries, and the ones that aren’t
Designated countries fall into four groups:
| Group | What it covers |
|---|---|
| WTO GPA countries | Countries that are parties to the Government Procurement Agreement |
| Free Trade Agreement countries | Countries with a US free trade agreement that includes government procurement |
| Least developed countries | Countries on the FAR’s least developed country list |
| Caribbean Basin countries | Countries designated under the Caribbean Basin trade programs |
The full list is in the FAR definitions at 25.003. The important point for software companies is who isn’t on it. Several large software development locations, including China and India, are not designated countries. A product that originates in a non-designated country generally can’t be offered on an acquisition the Act covers.
How origin is decided for software
For products, the FAR’s test is substantial transformation. A product originates in the country where it was wholly made, or, if it was made from parts from more than one country, where it was last transformed into a new and different article of commerce with a name, character or use distinct from what went into it.
Software doesn’t fit neatly into a test written for manufactured goods, so in practice companies rely on country-of-origin rulings from US Customs and Border Protection. Those rulings have generally looked to where the software is actually designed, written and compiled. Where the code is merely copied, loaded onto media or packaged hasn’t counted. Rulings depend on their facts, so read them as guidance, not as a rule that settles your case.
Services work differently. For services, FAR Part 25 looks at where the firm providing the service is established. Whether a contract treats your SaaS offering as a product or a service depends on how the solicitation and your contract describe it. Ask the contracting officer or your reseller how the offer will be classified before you assume either answer.
Three situations deserve a careful look:
- Offshore development teams. If substantial work on the product happens in a non-designated country, the origin answer may not be the United States, even for a US-headquartered company.
- Bundled hardware. Appliances, devices and peripherals sold with your software have their own origin, decided under the product test.
- Acquired code. A product built on a codebase you acquired carries the origin facts of where it was built, not just of where you maintain it now.
The Buy American rules are a separate test
The Buy American statute is a separate restriction, in FAR Subpart 25.1, that applies to supplies. Where the Trade Agreements Act covers an acquisition, its rules generally govern instead. Where it doesn’t, for example below the threshold, the Buy American rules apply and favor domestic end products.
For most commercial software the Buy American question is simpler than it sounds. Commercially available off-the-shelf items are generally exempt from the component test, so the question usually comes down to where the end product is made. Department of War contracts use their own versions of these clauses in DFARS Part 225, including DFARS 252.225-7021, Trade Agreements. Read the clause your solicitation actually contains.
Where the question reaches you
| Where | What you answer |
|---|---|
| GSA Multiple Award Schedule | GSA applies the Trade Agreements clause across Schedule contracts, so every product you offer must be US-made or from a designated country |
| Individual solicitations | FAR 52.225-6, Trade Agreements Certificate, where the solicitation includes it, plus the 52.225-5 clause in the award |
| SAM.gov representations | The Buy American and Trade Agreements certificates included in your annual representations |
| Resellers and primes | The same answer, flowed down. A reseller putting your product on its contract will ask for an origin statement. See federal resellers for SaaS companies |
A certification is a vendor claim
A Trade Agreements certification is self-attested. Nobody audits your commit history before award. The government accepts your answer, and a reseller adding your product to a Schedule relies on it too. That’s exactly why it matters to get right. Country-of-origin certifications that turn out to be wrong have produced False Claims Act cases, and the liability can reach the reseller as well as the software company.
Self-attested isn’t the same as verified, and federal buyers know the difference. See verified vs. self-attested: what federal buyers actually check.
A practical approach:
- Write down where the product is built: which teams design, write and compile the code, and in which countries.
- Separate products from services in your offering, and note how each is likely to be classified.
- List any hardware you sell with the software, with its manufacturer’s origin statement.
- Get advice before you certify if material development happens in a non-designated country.
- Keep the record dated and signed, and revisit it when your team’s footprint changes or you acquire a codebase.
Where it fits in your federal readiness
Country of origin is one line in a longer list of things a buyer expects to be settled before an offer arrives. It sits alongside an active SAM.gov registration, the Section 889 telecom representation, license terms an agency can sign and accessibility documentation. If you’re heading for a Schedule, it’s one of the first questions to settle. See the GSA Schedule for SaaS.
To see where your company stands across the categories federal buyers check, score your company’s federal readiness.
Related reading
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.