Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

DST revenue ringfencing

dst-revenue-trackingDomain: taxType: in-house

Description

DST revenue ringfencing is the finance-system discipline of tagging in-scope revenue at the moment of recognition, by jurisdiction, so that the DST liability calculates against the underlying ledger rather than against a year-end estimate. The discipline exists because digital-services taxes are a small family of jurisdiction-specific levies on revenue from online advertising, marketplace intermediation, and user-data monetization that have been enacted across the UK, France, Italy, Spain, Austria, Turkey, Canada, and India over the past several years; each was framed as a stopgap while the OECD Pillar Two negotiations played out, and each has remained in force long past the point at which the stopgap framing was credible. Pillar Two has not displaced any of them as of 2026. The shape of the problem is that each regime defines the taxable revenue base differently. The UK and Italian definitions are narrower and reach mainly advertising plus marketplace intermediation. The French definition reaches further into intermediation-adjacent revenue. The Indian equalisation levy reaches further still and treats non-resident e-commerce operators as a broad category. Austria's tax is advertising-only at 5 percent. Each rate is in the 2 to 7.5 percent band on in-scope gross revenue. Each has its own thresholds at which the obligation attaches (Italy's €5.5M national threshold puts more mid-sized firms in scope than France's €25M or Spain's €3M). The operational consequence is that revenue tagging has to happen at the transaction level rather than at year-end roll-up, because the categorization questions multiply once a tax-authority audit starts asking for source records. The tagging system decomposes into three pieces. The first is the revenue-stream classifier, which maps every revenue event (ad placement, marketplace transaction, subscription charge, user-data sale, in-app purchase) to the specific DST-scoped category in each relevant jurisdiction, and which records the classification reasoning so that the same event tags consistently across periods. The second is the user-jurisdiction determination, which is the piece operators most often under-budget: IP-based geolocation is the cheapest signal but not always the audit-defensible one (the French DGFiP and the UK HMRC have both pushed back on IP-only methods in marketplace contexts), and the audit defensibility of the chosen method matters more than the elegance of the method itself. The third is the reconciliation layer between the operational ledger and the tax-filing system, which is where most of the actual disputes get resolved. The practical guidance is to set the tagging architecture up before the operator hits any DST threshold rather than after. Retroactive tagging is materially more expensive than prospective tagging because the source records degrade in resolution over time (geolocation logs roll off, user-account metadata changes, payment-processor reports compress detail at archive), and because the audit-defensibility argument is harder when the tagging method was constructed inside the audit window itself. Canada's DST in particular reaches back to 2022 revenue under the 2024 statute, which has surfaced the retroactive-tagging cost in concrete form for operators caught by that lookback.

Required by (7 regulations)

  • UK DST

    Finance Act 2020 — UK DST per-revenue-stream tracking against the £25M annual allowance and the cross-border relief calculation under Section 53.

    Finance Act 2020

    Source →

  • France DST

    Loi n° 2019-759 — France DST per-revenue-stream tracking with quarterly advance payments + annual return reconciliation.

    Loi n° 2019-759

    Source →

  • Italy DST

    Legge 160/2019 — Italy DST per-revenue-stream tracking; €5.5M national threshold means more mid-sized firms in scope than France/Spain.

    Legge 160/2019

    Source →

  • Spain DST

    Ley 4/2020 IDSD — Spain DST per-revenue-stream tracking with quarterly return cadence.

    Ley 4/2020 IDSD

    Source →

  • Austria DST

    Digitalsteuergesetz 2020 — Austria DST per-revenue-stream tracking; advertising-only scope is narrower than EU comparators.

    Digitalsteuergesetz 2020

    Source →

  • Türkiye DST

    Türkiye DST per-revenue-stream tracking with monthly filing cadence.

    Türkiye DST per-revenue-stream tracking with monthly filing cadence.

    Source →

  • Canada DST

    Canada DST is REPEALED. Operators that previously registered should follow CRA refund guidance. No tracking obligation under Canadian DST going forward. Historical reference only.

    Canada Digital Services Tax Act (REPEALED 2025-06-29). Federal budget bill royal assent 2025-03-26 repealed the DST; collection halted; CRA refunded ~CAD $647M to taxpayers. No future Canadian DST obligations under this regime.

    Source →

Fulfilled by (1)

  • In-house build · medium effort

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • DST-tagged GL accounts
  • reconciliation reports

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn