(POLAND) — Poland has advanced a Digital Services Tax (DST) aimed at revenues from digital services in Poland, with public consultations starting February 2, 2026, and the draft bill entering the Polish government’s legislative work program on January 27, 2026.
Globally mobile founders often sell into Poland without a Polish office. A DST can still matter. It is designed to follow users and revenue, not where your company is registered.
What you’ll need before you assess exposure
- A current map of how you earn digital revenue connected to Poland (ads, platform fees, data).
- Basic evidence you already collect on user location (billing country, IP signals, device signals).
- Group revenue numbers for the prior accounting period, including subsidiaries where relevant.
- Internal owners for billing, tax, and data pipelines.
1) Overview of the proposed Digital Services Tax (DST)
Poland’s proposal is a revenue-based tax on certain digital services “provided in Poland” or aimed at users in Poland. Think of it as a country charging a fee on specific digital revenue streams linked to its user base.
A digital services tax is not the same as corporate income tax (CIT). CIT is typically profit-based. It looks at income minus costs, then taxes the net profit. DST instead applies to qualifying revenues, even when margins are low or you are reinvesting heavily.
“Provided in Poland/targeting users in Poland” generally points to where the user is located or where the ad is targeted. For remote-first teams, that can mean:
- Your ad inventory is sold for impressions aimed at Polish users.
- Your marketplace or social platform connects Polish users to other users.
- Your business monetizes data generated by user activity in Poland.
Policy stage matters. Early drafts often change during consultation. Poland began public consultations on February 2, 2026, after the Polish Ministry of Digital Affairs submitted the draft bill for the Polish government’s legislative work program on January 27, 2026.
2) Key features of the proposed DST
Revenue taxes feel different in day-to-day operations. A profit tax can be softened by costs. A revenue tax can bite even if you are close to break-even in a market. That is why ad-funded products and thin-margin marketplaces tend to watch DST proposals closely.
Revenue streams likely in scope
Poland’s draft frames the DST (also described as a compensatory tax) around three core buckets that many cross-border digital businesses recognize:
- Targeted digital advertising Revenue from placing ads directed at Polish users. If your adtech stack sells campaigns by geography, “Poland-targeted” is the basic risk flag.
- Multilateral digital interfaces Running a platform that lets users find and interact with other users. Marketplaces and social platforms are the common examples. Fees, commissions, and similar platform charges can fall into this category.
- User data monetization Sale, licensing, or other monetization of data tied to user activity on a digital interface. That includes aggregated datasets, in many DST-style designs.
Carve-outs you should not ignore
Exclusions shape product design and contract drafting. Poland’s draft carves out several activities, including:
- Own-site content delivery on your own interface (as opposed to running a marketplace-style interface for others).
- Online sales of goods or services through a supplier’s own website when the supplier is not acting as an intermediary.
- Regulated financial services and trading systems under EU Directive 2014/65/EU.
- Crowdfunding and editorial publishing.
Those exclusions often exist to avoid taxing “ordinary” online sales and regulated sectors, and to keep the DST aimed at large platform and advertising models.
Rate and double-tax relief concept
The proposal contemplates a DST rate of up to 3% on qualifying Polish revenue. Poland’s design also attempts to limit double taxation by reducing the DST by the amount of CIT attributable to the same income. The mechanics will matter in practice, so watch how the final text defines the matching of DST revenue to CIT base.
3) Taxpayer thresholds and applicability
Threshold tests are the gatekeeper. Poland’s DST is aimed at large digital providers, but the scope can still catch international groups with one high-scale product line.
How the thresholds typically work
Poland’s draft uses a prior accounting period test. That timing can surprise fast-growing platforms. You might cross thresholds based on last year’s scale, even if your current-year Poland strategy has changed.
Group concepts also matter. The proposal applies to entities or consolidated groups. In many DST systems, group revenue can include subsidiaries and related entities that are consolidated for reporting. Corporate structure, not just a single legal entity, may drive eligibility.
“Regardless of tax residence” You do not need to be headquartered in Poland. A foreign company can be in scope if it earns in-scope revenue tied to Poland and meets the thresholds. That raises a practical question: can you identify which revenue is “Polish revenue” under the sourcing rules? For many models, user location evidence becomes the compliance hinge.
Examples of structures that could be exposed (illustrative only)
- A marketplace operator earning commissions from transactions initiated by users in Poland.
- An ad network selling targeted digital advertising aimed at Polish users across apps and sites.
- A SaaS platform that separately monetizes user activity data, beyond subscription fees.
Threshold requirements for DST eligibility (Table 1)
| Threshold | Amount | Notes |
|---|---|---|
| Global revenue | €1 billion | Measured in the prior accounting period; some reporting has mentioned €750 million as an alternative figure. |
| Polish revenue threshold | PLN 25 million | Polish taxable revenue in the prior accounting period. |
| Who is tested | Entities or consolidated groups | Applies regardless of tax residence or headquarters location. |
4) Timeline and current status
Public consultation is where definitions often shift. Stakeholders usually focus feedback on what counts as targeted ads, what qualifies as a multilateral interface, and how to source revenue to Poland.
Key items to watch as the draft moves through the legislative process:
- Effective date and any transitional rules.
- Registration and filing cadence, including payment timing.
- Definitions for in-scope services and excluded activities.
- Sourcing rules for “provided in Poland,” including accepted user-location indicators.
- Enforcement approach, including documentation expectations.
Preparation can start before enactment. Data and billing systems take time to change. Many businesses begin by tagging revenue lines that might be in-scope and aligning them to user location evidence.
✅ What affected digital businesses should do now: assess if Poland-based user exposure exists, map revenue streams that could fall under DST, and prepare data tagging for potential sourcing rules
5) Context, potential impacts, and related developments
France and the UK have used DST-style models aimed at large digital businesses, especially advertising and platform intermediation. Poland’s proposal follows that pattern. High revenue thresholds are meant to keep smaller firms out, but they can still pull in globally distributed groups with one scaled product.
Operational impacts often show up first in contracting and billing:
- Pricing clauses: Some firms add tax gross-up language or DST pass-through provisions for B2B customers.
- Marketplace fees: Platform operators may revisit fee schedules if DST applies to commission revenue.
- Ad billing: Campaign invoicing may need clear country targeting fields and audit trails.
- Data monetization reporting: If data licensing is a line item, finance teams may need a Poland sourcing view.
Policy friction is another planning variable. Prior commentary has included warnings about possible retaliation by the Trump administration if a DST is enacted. Treat that as uncertainty, not a forecast. Your practical response is scenario planning in contracts and cash-flow timing.
Crypto policy is separate unless Poland explicitly links it later. Poland’s February 12, 2026, presidential veto of MiCA-aligned crypto legislation sits on a different track. Treat it as a parallel regulatory topic, not a DST driver.
6) Related 2026 tax changes in Poland
DST is not the only moving piece for finance teams. Two other items can affect how digital businesses run billing and compliance work in Poland.
Mandatory e-invoicing (KSeF)
KSeF is Poland’s e-invoicing framework. Mandatory e-invoicing typically means invoices must be issued and transmitted in a structured format through a required system, rather than emailed PDFs. That can force changes in:
- Billing workflows and invoice numbering logic.
- Vendor and contractor onboarding, especially where Polish customers require compliant invoices.
- Integration work between ERP, invoicing tools, and local compliance steps.
Cross-border teams often feel this through operations. Finance, product billing, and vendor management usually need a shared plan.
Bank-sector CIT measure
A separate policy item is a temporary 30% CIT hike for banks. Most digital founders will not be directly affected unless they operate in the banking sector, yet it signals a broader willingness to use sector-specific tax measures in 2026.
⚠️ Be aware of possible changes during the consultation and legislative process; no implementation date is set yet
If you might be near the thresholds, start by tagging Poland-linked revenue and confirming how your products identify Polish users. That work reduces scramble later, even if the final DST text changes.
This article discusses proposed tax rules and should not be taken as legal or tax advice. Consult a qualified advisor for guidance tailored to your business.
Regulatory language is subject to change during the legislative process; confirm final text before planning or reporting.
