Digital Services Tax (DST) for SaaS Companies: Why Incorporation in Wyoming, Hong Kong, Singapore or Any Other Jurisdiction Does Not Eliminate DST

Executive Summary

Digital Services Tax (DST) has emerged as one of the most misunderstood global tax topics for SaaS founders. A common misconception is that incorporating a company in a specific jurisdiction — such as Wyoming (US), Estonia, Ireland, or Hong Kong — can eliminate Digital Services Tax exposure in France, Italy, Spain, India, Turkey, and other DST-applying countries.

This is incorrect.

DST liability is determined exclusively by the location of your users/customers, not by the country where your company is incorporated.

This report explains:

• Why incorporation jurisdiction does not matter

• How France, Italy, Spain, India, and others actually enforce DST

• Revenue thresholds and risk levels

• Real-world SaaS examples

• What does reduce DST exposure (and what doesn’t)

• Structuring strategies used by global SaaS companies

• Decision frameworks and diagrams for founders

What is DST and How Does It Affect SaaS?

DST is a turnover-based tax imposed on digital businesses that earn revenue from users located in a specific country.

Key Characteristics of DST

Feature	Explanation
Tax base	Gross revenue (turnover), not profit
Trigger	Users located in the taxing country
Entity location	Irrelevant for DST
Tax treaties	DST ignores double-tax treaties
Digital PE	Not required for DST
Target	SaaS, platforms, data-driven digital services

DST emerged because governments concluded that traditional corporate tax rules (CIT, PE, withholding tax) were inadequate for highly mobile, borderless digital services.

For SaaS companies, this creates a unique exposure: You can owe DST in a country where you have zero physical presence.

The Core Misconception: “If I Incorporate in Wyoming or Serbia, I Avoid DST.”

This is false.

DST applies based on: ➡ The user’s location

NOT the company’s:

• domicile

• incorporation country

• tax residency

• servers

• employees

• management

If a French user subscribes to your SaaS product, France analyzes DST exposure regardless of whether your company is located in:

• Wyoming

• Delaware

• Serbia

• Estonia

• Hong Kong

• Singapore

• Nevis

• UAE

Jurisdiction of incorporation simply does not affect DST.

DST Thresholds: Why Most Smaller SaaS Companies Are Not Affected

DST applies only when specific revenue thresholds are met.

DST Thresholds in Key Countries (2025)

Country	DST Rate	Global Revenue Threshold	Local Revenue Threshold	SaaS Applicability
France	3%	€750M	€25M	Yes
Italy	3%	€750M	€5.5M	Yes
Spain	3%	€750M	€3M	Yes
UK	2%	£500M	£25M	Yes (user-data driven SaaS)
Austria	5%	N/A	N/A	Mostly ads (low SaaS impact)
Turkey	7.5%	None	None	High
India (Equalization Levy)	2–6%	None	None	Very high (no thresholds)
Kenya	1.5%	None	None	Yes
Nigeria	6%	None	None	Yes
Tanzania	2%	None	None	Yes

Critical insight:

A SaaS company with €1–20M global revenue has zero DST liability in France, Spain, Italy, and the UK — regardless of corporate location.

DST strikes mostly at scale.

Visual Diagram: When Does DST Apply?

Why Incorporation Doesn’t Matter: The Legal Basis

DST rules explicitly tax:

• Revenue derived from users located in the taxing country,regardless of:

• permanent establishment

• tax residency

• legal seat

• incorporation jurisdiction

• ownership structure

DST is extraterritorial by design.

This is why a SaaS company from Wyoming or Serbia can still be asked to pay DST in France if it exceeds the French user revenue threshold (€25M).

Real Exposure Comes From These Markets (Not Europe)

High-Risk DST Countries (No Thresholds)

Country	Risk Level	Reason
India	🔥 Very High	No thresholds; applies to any SaaS revenue
Turkey	🔥 Very High	7.5% DST; aggressive enforcement
Nigeria	High	6% digital tax
Kenya	Medium	1.5% DST
Tanzania	Medium	2% DST

These are the countries SaaS founders should truly worry about.

In contrast:

• France → Safe until €25M in French revenue

• Italy → Safe until €5.5M

• Spain → Safe until €3M

• UK → Safe until £25M

What Does Help Reduce DST Exposure (Legally)?

Since incorporation does nothing, SaaS companies rely on other methods:

1) Merchant of Record (MoR)

Using providers like:

• Paddle

• Stripe MoR

• Shopify App Store

• Apple App Store

• Google Play

shifts DST responsibility away from your company.

2) Geo-restriction of high-risk countries

Blocking or restricting:

• India

• Turkey

• Nigeria

• Kenya

• Tanzania

is a common and legal practice for SaaS companies below enterprise scale.

3) EU reseller model

A European reseller becomes the “seller of record” to EU users.

Your main company sells only to the reseller → no DST exposure.

4) Product segmentation

Offering:

• EU-friendly versions

• Non-EU versions

• Data-minimal versions

can reduce DST triggers related to user-data monetization.

5) Revenue monitoring

Setting alerts for revenue approaching DST thresholds by country.

Table: What Impacts DST Exposure (and What Doesn’t)

Factor	Impacts DST?	Explanation
User location	✅ Yes	Primary basis for DST
Revenue thresholds	✅ Yes	Must exceed them for DST to apply in some countries
User-data monetization	⚠️ Yes	Triggers DST in UK and EU
Incorporation country (WY, DE, RS, HK, EE)	❌ No	Has zero effect
Server location	❌ No	Ignored
Company tax residency	❌ No	Ignored
PE (permanent establishment)	❌ No	Not required for DST
MoR provider	✅ Yes	Can eliminate DST exposure
Reseller model	✅ Yes	Transfers DST liability
Geo-restrictions	✅ Yes	Avoids DST-triggering markets

Conclusion: The Only Thing That Determines DST Is the User’s Location

DST is one of the few tax regimes that:

• ignores tax treaties

• ignores company jurisdiction

• ignores PE

• ignores tax residency

• ignores incorporation strategy

Because DST is a destination-based tax, not a corporate tax.

Therefore:

Incorporating in Wyoming, Delaware, Serbia, Estonia, or Hong Kong does not eliminate DST exposure.

The correct approach is not “Where should I incorporate?”but rather:“Do I exceed DST thresholds in user-location countries, and how should I structure billing?”