Nobody at your company works in exports. There is no shipping dock, no customs broker, no export department. And yet the moment a customer in another country downloads your mobile app, integrates your SDK, or gets API access to the wrong feature, your SaaS business may have just made an export under US law — with licensing, screening, and recordkeeping obligations attached. Here is how to tell when that happens and what to do about it.
The Two Regimes in 90 Seconds
US export controls run through two separate systems, administered by two different agencies. The order matters: you check the first one before the second.
ITAR — defense items. The International Traffic in Arms Regulations, administered by the State Department's Directorate of Defense Trade Controls (DDTC), control defense articles, defense services, and related technical data listed on the US Munitions List (USML). If your software was specifically designed or modified for a military application — guidance, targeting, military communications, or similar — you are in ITAR territory, where licenses are hard to get, few exceptions apply, and civil penalties run to seven figures per violation. Most commercial SaaS never lands here, but you must rule it out first, because ITAR takes jurisdiction whenever it applies.
EAR — everything else. The Export Administration Regulations, administered by the Commerce Department's Bureau of Industry and Security (BIS), cover all other US-origin items, including commercial software and technology. Controlled items appear on the Commerce Control List (CCL) under an Export Control Classification Number (ECCN); items subject to the EAR but not listed anywhere are designated EAR99. Most ordinary business software is EAR99 or a low-sensitivity ECCN, which means most destinations need no license — but "EAR99" is still a classification under the regulations, not an exemption from them. Restricted destinations, restricted parties, and prohibited end uses can still trigger a license requirement.
One uncomfortable feature spans both regimes: many administrative violations do not require criminal intent. Shipping — or transmitting, or granting access to — a controlled item to the wrong place or person can create liability even when nobody meant to break the rules. That is why the compliance habit that matters most is classifying before you transmit, not explaining after an enforcement letter arrives.
Why SaaS Founders Assume This Does Not Apply to Them
The assumption feels reasonable. Nothing leaves the country in a box; the code sits in a US data center and foreign customers merely interact with it through a browser. For years, BIS guidance supported a narrow version of that view:
- A 2009 advisory opinion established that a cloud provider is generally not the "exporter" when its customers use rented computing capacity to create or move controlled technology — the customer is.
- A 2011 opinion concluded the provider therefore does not need deemed-export licenses for its own foreign-national IT staff who may encounter customer data on the network.
- A widely relied-upon 2014 opinion held that giving users access to a "cloud-based storefront" — what we now call SaaS — is not an export of the software itself, provided users do not download it.
That 2014 opinion is a big reason the SaaS industry could scale globally without treating every login as an export event. But it is narrow: it covers use-without-download, it is fact-specific, and it says nothing about the five situations below, where SaaS companies routinely cross the line. And the ground is shifting — more on that in a moment.
Five Ways SaaS Companies Actually Become Exporters
1. Downloads, SDKs, and Mobile Apps
The 2014 opinion protects access without download. The moment a foreign person downloads your software — a mobile app, a desktop client, an SDK, an on-prem agent, even a container image — that is a textbook export of software to that person's country. Each download destination then needs the standard analysis: classification, country, end user, end use.
Practical consequence: if your product has any downloadable component, maintain a current ECCN or EAR99 determination for every downloadable artifact, and make sure your distribution and licensing terms account for sanctioned destinations rather than discovering the gap during due diligence for a funding round.
2. Sharing Source Code and Technical Data With Foreign Persons
Under the EAR, releasing controlled technology or source code to a foreign national inside the United States is a "deemed export" to that person's most recent country of citizenship or permanent residency — a license is required if exporting the same technology to that country would require one. ITAR has a parallel and stricter rule for technical data.
This is the trap most likely to catch a small team:
- A foreign-national engineer on your US payroll who can browse the whole monorepo may need a deemed-export analysis for every controlled technology area they can access.
- An offshore contractor with GitHub access to encryption source code or controlled algorithms is receiving technology in their country, not merely "helping out."
- A support screen-share that walks a foreign customer through a controlled configuration can be a release of technology.
Fixes are operational, not exotic: classify your technology, segment repository access by project, mark controlled technology, and screen the access decision the same way you would screen a shipment. Trade practitioners call the written version of this a technology control plan, and its ingredients are unglamorous — transmission security, physical security, IT access controls, marking, and disposal procedures.
3. Encryption in Your Product
Nearly every SaaS product uses encryption — TLS in transit, AES at rest, libraries like OpenSSL or platform crypto APIs. Encryption software and technology are controlled for national-security reasons, typically under ECCNs such as 5D002 (software) and 5E002 (technology).
The good news is that BIS built a broad on-ramp for ordinary commercial cryptography:
- Most mass-market encryption products qualify for relaxed treatment (the 5x992 group) rather than a license application.
- License Exception ENC (15 CFR § 740.17) authorizes export and reexport of eligible encryption items without a license, and a 2021 rule removed several legacy burdens, including most pre-notifications for publicly available encryption source code.
- No encryption registration with BIS is required anymore.
The remaining obligation that startups most often miss is paperwork, not permission: exporters who self-classify encryption products under License Exception ENC(b)(1) generally must file an annual self-classification report with BIS covering the prior calendar year, due February 1. Put it on the compliance calendar next to your tax deadlines, and keep a standing export-classification list for every product and component so the report writes itself.
4. API Access to Controlled Technology — Including AI Models
For ordinary SaaS features, browser-and-API access without download still sits under the 2014 opinion. But regulators have started carving out the highest-sensitivity technology. Commerce has moved to treat remote, API-based access to advanced AI models as a controlled "release" of the model — a sharp break from the historic position that remote interaction without a technology transfer is not an export.
And Congress may go further. In January 2026 the House passed the Remote Access Security Act (RASA), which would give BIS authority to regulate remote access by foreign persons to EAR-controlled items through internet or cloud services — closing what sponsors call the "cloud loophole." As of this writing the bill awaits Senate action. If it becomes law, the compliance burden for companies operating on the cloud expands substantially, and the 2014 use-without-download comfort zone narrows.
What to do while the law is in motion: inventory which of your APIs expose controlled technology (encryption, high-performance computing, AI/ML models, geospatial or sensor-fusion features are the usual suspects), log who accesses them from where, and structure your terms and access controls so you can restrict destinations and users if the rule changes under you.
5. Customers, Destinations, and End Uses
Even EAR99 software needs a license — or is outright prohibited — for certain destinations, parties, and purposes:
- Sanctioned destinations change with foreign policy; selling or providing access into embargoed countries without authorization is prohibited, and regional restrictions (Russia, Belarus, occupied regions of Ukraine) now reach even ordinary EAR99 business software.
- Restricted parties must be screened deal by deal. Check every customer, reseller, and integration partner against the government's consolidated restricted-party lists before provisioning access, and re-screen periodically — lists change, and so do your customers' ownership structures.
- Prohibited end uses include military, nuclear-propulsion, and certain surveillance applications. A generic project-management tool sold with knowledge it will support a military end use in a restricted destination can still violate the rules.
None of this requires an enterprise compliance department. It requires a checklist that runs before the first invoice: classify the item, screen the party, check the destination, confirm the end use, and write down the answer.
What Getting It Wrong Costs
Penalties are designed to exceed the profit on the deal by orders of magnitude:
- Under the EAR, criminal violations can bring up to $1 million per violation and up to 20 years' imprisonment for individuals; administrative penalties run to hundreds of thousands of dollars per violation and are adjusted for inflation every year.
- ITAR criminal penalties reach the same $1 million/20-year scale, with civil penalties in seven figures per violation.
- Beyond fines, BIS can deny export privileges entirely — a death sentence for a company whose product is distributed globally — and violations can surface years later during acquisition due diligence, when the buyer discounts the purchase price by the estimated exposure.
The headline example: in 2023 a hard-drive manufacturer agreed to a $300 million BIS settlement over shipments tied to a restricted Chinese telecom-equipment maker — the largest standalone administrative penalty BIS had ever imposed. Your company is smaller, but the arithmetic scales down, not away.
There is also a genuine carrot. BIS policy treats a voluntary self-disclosure (VSD) as strong mitigation earning a sharply reduced penalty — while the deliberate non-disclosure of a significant possible violation is an aggravating factor that increases it. A 2024 final rule codified that two-sided incentive. The practical message: when you find a past violation, investigate promptly with counsel, fix the process gap, and disclose. Burying it is the one response the guidelines punish on purpose.
A Small-Business Export Compliance Checklist
You do not need a trade-law department. You need these seven habits, sized for a team without one:
- Rule out ITAR first. Confirm in writing that nothing you sell, host, or share was designed for military use or appears on the USML. If the answer is unclear, get a jurisdiction determination before you ship anything.
- Classify everything under the EAR. Assign every product, downloadable component, and technology area an ECCN or an EAR99 determination, and keep the list current. When self-classification is uncertain, BIS accepts commodity-classification requests.
- Handle encryption deliberately. Determine whether each encryption item is mass-market, ENC-eligible, or license-required; file the annual self-classification report by February 1 if your items require it.
- Screen every foreign transaction. Check customers, resellers, and contractors against restricted-party lists; verify destinations against current sanctions; document prohibited-end-use review. Automate this in provisioning, not in someone's memory.
- Control technology access. Segment code repositories, mark controlled technology, and run deemed-export checks before granting foreign nationals (employees included) access to source code or technical data.
- Keep records for five years. The EAR requires export records generally be retained for five years from the transaction. Store classifications, screening results, license determinations, and shipping or access logs where an auditor — or a buyer's diligence team — can find them.
- Train the builders. Developers, DevOps, and support engineers create export events daily (granting repo access, sharing a debug build, screen-sharing a config). Annual training plus a one-page "ask before you share" guide prevents most inadvertent releases.
Keep Compliance Costs Visible in Your Books
Export compliance shows up in your finances long before it shows up in an enforcement action: outside counsel for classification reviews, restricted-party screening subscriptions, deemed-export controls in your HR onboarding, the staff hours behind your annual encryption report, and — if you ever file one — the legal cost of a voluntary self-disclosure. Track these as their own expense category rather than burying them in general legal or software spend, so you can see what each market and product line really costs to serve. Pair that with the five-year record trail above — classifications, screening logs, and license determinations filed by transaction — and both your auditors and any future acquirer's diligence team get clean answers instead of archaeology. Your docs on record retention and dashboards in /fava/ are natural homes for that paper trail.
Keep Your Financial Records Audit-Ready From Day One
As you open your SaaS to customers around the world, maintaining clear financial records — including every compliance dollar and every export determination — is essential. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data, with version-controlled records an auditor can actually follow. Get started for free and see why developers and finance professionals are switching to plain-text accounting.





