Electronic Finance OÜ - e-Residency Advisory Hub

Electronic Finance OÜ - e-Residency Advisory Hub Your ultimate online platform for Estonian company creation with e-Residency. www.efinance.ee

𝗧𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝟲,𝟲𝟬𝟬 𝗴𝗮𝗺𝗲 𝘀𝘁𝘂𝗱𝗶𝗼𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗘𝗨, 𝘁𝗵𝗲 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝘁𝗲𝗮𝗺 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗳𝗼𝘂𝗿𝘁𝗲𝗲𝗻 𝗽𝗲𝗼𝗽𝗹𝗲, 𝗮𝗻𝗱 𝗮 𝗴𝗿𝗼𝘄𝗶𝗻𝗴 𝘀𝗵𝗮𝗿𝗲 𝘀𝗲𝗹𝗹 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲𝗶𝗿 𝗼...
04/09/2026

𝗧𝗵𝗲𝗿𝗲 𝗮𝗿𝗲 𝟲,𝟲𝟬𝟬 𝗴𝗮𝗺𝗲 𝘀𝘁𝘂𝗱𝗶𝗼𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗘𝗨, 𝘁𝗵𝗲 𝗮𝘃𝗲𝗿𝗮𝗴𝗲 𝘁𝗲𝗮𝗺 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗳𝗼𝘂𝗿𝘁𝗲𝗲𝗻 𝗽𝗲𝗼𝗽𝗹𝗲, 𝗮𝗻𝗱 𝗮 𝗴𝗿𝗼𝘄𝗶𝗻𝗴 𝘀𝗵𝗮𝗿𝗲 𝘀𝗲𝗹𝗹 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲𝗶𝗿 𝗼𝘄𝗻 𝘄𝗲𝗯 𝘀𝗵𝗼𝗽. 𝗧𝗵𝗲 𝘀𝗲𝗹𝗹𝗶𝗻𝗴 𝗲𝗻𝘁𝗶𝘁𝘆, 𝗺𝗲𝗮𝗻𝘄𝗵𝗶𝗹𝗲, 𝘂𝘀𝘂𝗮𝗹𝗹𝘆 𝗲𝗻𝗱𝘀 𝘂𝗽 𝗰𝗵𝗼𝘀𝗲𝗻 𝗯𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗮𝘁 𝗰𝗵𝗼𝗶𝗰𝗲 𝗿𝗲𝗮𝗹𝗹𝘆 𝗱𝗲𝗰𝗶𝗱𝗲𝘀 — 𝗮𝗻𝗱 𝘄𝗵𝗮𝘁 𝗶𝘁 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁, 𝗰𝗼𝗻𝘁𝗿𝗮𝗿𝘆 𝘁𝗼 𝗮 𝗰𝗼𝗺𝗺𝗼𝗻 𝗲𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻.

The EU game industry has reached 6,600 studios employing over 95,000 people, with a combined turnover of €24 billion (EGDF, 2024 data, published 21 August 2026). The average team is about fourteen people. A growing share sell directly from their own web shop rather than only through the big stores.

A web shop is a legal object. Somewhere in your setup there is one company whose name appears on the receipt the player gets, and that name is where the question starts: it is evidence of who is selling, not the whole answer. An engine is chosen deliberately; a selling entity can end up chosen by default.

What that choice actually decides: which entity’s tax residence the revenue sits in; who carries the VAT and OSS obligations and files the returns; which contract the player is entering into; and how the money moves through your accounting and payment setup.

What it does not decide: for sales of digital services to consumers, the VAT generally follows the buyer’s country, not the seller’s. There is one relief for small sellers — while your cross-border sales to consumers elsewhere in the EU stay under €10,000 a year, you may keep charging your own country’s VAT instead. Above that line, the buyer’s country decides. Incorporating in Estonia does not make a German player’s purchase Estonian.

December is the biggest month most studios have, and it is often the month in which cross-border sales pass €10,000 for the first time. From that point the question of whose name is on the receipt stops being theoretical.

Check it before the traffic arrives, not after:
efinance.ee/assessment

𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘀𝗽𝗹𝗶𝘁𝘀 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀 𝗶𝗻𝘁𝗼 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗶𝗻𝗻𝗼𝘃𝗮𝘁𝗶𝗼𝗻 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀. 𝗘𝗨 𝗹𝗮𝘄 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝘀 𝗻𝗼 𝘀𝘂𝗰𝗵 𝘀𝗽𝗹𝗶𝘁: 𝗩𝗔𝗧, 𝘁𝗵𝗲 𝗗𝗦𝗔, 𝘁𝗵𝗲 𝗣𝟮...
03/09/2026

𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘀𝗽𝗹𝗶𝘁𝘀 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀 𝗶𝗻𝘁𝗼 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗶𝗻𝗻𝗼𝘃𝗮𝘁𝗶𝗼𝗻 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺𝘀. 𝗘𝗨 𝗹𝗮𝘄 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝘀 𝗻𝗼 𝘀𝘂𝗰𝗵 𝘀𝗽𝗹𝗶𝘁: 𝗩𝗔𝗧, 𝘁𝗵𝗲 𝗗𝗦𝗔, 𝘁𝗵𝗲 𝗣𝟮𝗕 𝗥𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗗𝗔𝗖𝟳 𝗲𝗮𝗰𝗵 𝗮𝗽𝗽𝗹𝘆 𝗼𝗻 𝘁𝗵𝗲𝗶𝗿 𝗼𝘄𝗻 𝘀𝗰𝗼𝗽𝗲 𝘁𝗲𝘀𝘁. 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘁𝗼 𝘁𝗵𝗲 𝗱𝘂𝘁𝗶𝗲𝘀 𝗼𝗳 𝗮 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝘁𝗵𝗮𝘁 𝘁𝘂𝗿𝗻𝘀 𝗼𝘂𝘁 𝘁𝗼 𝗯𝗲 𝗯𝗼𝘁𝗵 𝗮𝘁 𝗼𝗻𝗰𝗲.

Platform strategy has one famous split: transaction platforms, which match two sides, and innovation platforms, which let other people build on top of you.

It is strategy vocabulary, not a legal category. No EU statute contains those words.

But the two species attract different questions. A transaction platform gets asked: are you the intermediary, or the supplier of what is sold through you? An innovation platform gets asked: what are you answerable for in other people’s code that ships through you?

Add one plugin store to a marketplace and you are answering both sets of questions at once. Nothing about your category changed. What changed is that VAT, the Digital Services Act, the platform-to-business rules and the DAC7 reporting duties each decide separately whether they apply to you — and your business now meets more than one of those tests.

The engagements that take us longest are almost never unusual businesses. They are ordinary ones that added a second surface — a store, a plugin catalogue, an affiliate programme — and went on describing themselves the way they always had.

Count the sets of rules that apply to you before you count your revenue lines: efinance.ee/assessment

𝗧𝗵𝗲 𝘀𝗮𝗺𝗲 𝗳𝗼𝘂𝗿𝘁𝗲𝗲𝗻 𝘃𝗶𝗱𝗲𝗼𝘀 𝗰𝗮𝗻 𝗯𝗲 𝗽𝗼𝘀𝘁𝗲𝗱 𝗮𝘀 𝗮 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝗼𝗿 𝘁𝗮𝘂𝗴𝗵𝘁 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝗹𝗶𝘃𝗲. 𝗖𝗼𝗺𝗺𝗲𝗿𝗰𝗶𝗮𝗹𝗹𝘆 𝘁𝗵𝗮𝘁 𝗶𝘀 𝗼𝗻𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁; 𝘁𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶...
01/09/2026

𝗧𝗵𝗲 𝘀𝗮𝗺𝗲 𝗳𝗼𝘂𝗿𝘁𝗲𝗲𝗻 𝘃𝗶𝗱𝗲𝗼𝘀 𝗰𝗮𝗻 𝗯𝗲 𝗽𝗼𝘀𝘁𝗲𝗱 𝗮𝘀 𝗮 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝗼𝗿 𝘁𝗮𝘂𝗴𝗵𝘁 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝗹𝗶𝘃𝗲. 𝗖𝗼𝗺𝗺𝗲𝗿𝗰𝗶𝗮𝗹𝗹𝘆 𝘁𝗵𝗮𝘁 𝗶𝘀 𝗼𝗻𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁; 𝘁𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗶𝘁 𝗿𝗮𝗶𝘀𝗲𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲. 𝗛𝗲𝗿𝗲 𝗶𝘀 𝗼𝘂𝗿 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗺𝗮𝗽 𝗶𝗻 𝗳𝘂𝗹𝗹 — 𝗲𝗶𝗴𝗵𝘁 𝗴𝗿𝗼𝘂𝗽𝘀, 𝘁𝗵𝗶𝗿𝘁𝘆 𝗺𝗼𝗱𝗲𝗹𝘀 — 𝗮𝗻𝗱 𝘄𝗵𝘆 𝘄𝗵𝗮𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗿𝗼𝘄 𝘆𝗼𝘂 𝗳𝗶𝗻𝗱 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳 𝗶𝗻 𝗯𝘂𝘁 𝘁𝗵𝗲 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝘁𝘄𝗼 𝗿𝗼𝘄𝘀.

Two founders sell the same fourteen videos. One posts them as a library you can open any evening. The other teaches through them live, session by session, with a real person on the other end. Commercially that is one product. In tax it is not one question.

A model is easy to inherit. It arrives with whatever the product launched on: a Stripe checkout, a community platform, a course theme bought on a Sunday.

So here is the whole map, not a teaser. Eight groups, thirty models: one-time digital products, subscription media, SaaS, mobile apps, education, memberships, service marketplaces, and software-plus-service hybrids. Digital supplies only — no physical goods anywhere on it. It is our working sheet; we open it in the first ten minutes of every intake.

Two things to do with it. Find your row. Then find the second row that also describes you. Most platforms sit on the boundary of two or three models, and the boundary is where the questions live: how much of the delivery is done by a person, and whether the customer is buying content or someone’s time.

Save the sheet. If two rows fit you, that is the conversation: efinance.ee/assessment

The grey market in RuneScape gold went to the Court of Justice. Your in-app purchases lost.Inside large online games the...
18/08/2026

The grey market in RuneScape gold went to the Court of Justice. Your in-app purchases lost.

Inside large online games there are real economies trading entirely unreal things. RuneScape has run one since 2001 — an in-game exchange with order books, price charts and spreads, where players trade virtual gold and virtual artefacts. None of it exists outside the game. The gold is a number in a database.

It still takes hours to accumulate, and some people would rather pay than spend the hours. So a grey market grew around it: real money for virtual gold, against the game’s own rules, for twenty years.

A Lithuanian company, Žaidimų valiuta, worked the middle of that chain. Bought virtual gold from players, sold it to other players. The tax authority looked at 2020–2023 and said: that’s VAT.

The company argued the gold was a gift card.

Less absurd than it sounds. In EU law a gift card is a multi-purpose voucher, and it carries a rule studios have leaned on for years — no VAT when the card is sold, only when it is redeemed. Player pays €10 for gems: nothing. Player buys a sword: now. Player never comes back: never.

On 5 March the Court said no. A voucher is an instrument someone is obliged to accept as payment for a separate supply. Virtual gold entitles you to nothing separate. It is the thing being consumed, not a ticket to it.

So — a digital service, taxed at the top-up, on the full amount.

Twenty years of trading, and nobody had established what the virtual gold actually was. It took the highest court in Europe to answer, and the answer moved the tax.

Every digital business has a smaller version of that question. A bundled subscription. A seller payout. A course library.

Most people answer it by intuition.

Intuition is what lost this case.

A marketplace listing with paid promotion. A course with live sessions. A subscription with downloadable assets. A game ...
14/07/2026

A marketplace listing with paid promotion. A course with live sessions. A subscription with downloadable assets. A game with an in-game currency.

Commercially, each is one product; for VAT purposes, each is usually several distinct supplies — each with its own treatment, its own place of taxation, and its own collection point.

The decomposition matters early because it propagates. Product & VAT Mapping determines how individual components are priced at checkout, what the Terms of Service and the Seller Agreement must say about each of them, how the accounting model recognises each supply, and how they are reported through OSS.

Mapped at the design stage, this is a table: component, VAT treatment, place of supply, who collects. Reconstructed after launch, it becomes a correction exercise that runs through contracts, checkout logic and past OSS filings simultaneously.

Product & VAT Mapping is the fourth step of our methodology: every component of the catalogue receives a defined treatment, aligned with the platform’s classification and the payment flow — the two decisions made before it.

The map is inherited, in turn, by the contracts, the accounting and every OSS return that follows.

From the implementation methodology behind Platform Legal & Tax Architecture.

A structured starting point for a specific setup: https://efinance.ee/assessment (Link in bio)

The payment flow of a platform — who collects from customers, how sellers are paid out, where the commission settles — i...
13/07/2026

The payment flow of a platform — who collects from customers, how sellers are paid out, where the commission settles — is often left to be configured after launch, as a technical integration.

It is among the earliest architectural decisions of the project. The payment flow determines far more than the movement of customer money: whether the platform may hold third-party funds at all; which provider structures are available; how commission settlement works; at which point platform VAT is collected and reported through OSS; and how platform accounting recognises revenue — the platform’s fee, as distinct from the amounts passing through.

The payout records created by the flow are also the raw material for DAC7 seller reporting — data that is far easier to collect from the first transaction than to reconstruct in January.

Reversing the order is expensive. A payment flow that contradicts the platform’s classification weakens every contract built on top of it, and a banking relationship opened without a documented flow rarely survives its first compliance review.

In our methodology, Payment Flow Design is the third step of seven — after Platform Classification, before a single agreement is drafted or a company registered. Its output is a provider-ready payment flow model.

Every contractual and accounting decision that follows inherits the documented flow.

From the implementation methodology behind Platform Legal & Tax Architecture.

A structured starting point for a specific setup: https://efinance.ee/assessment (link in bio)

In practice, platform classification follows conduct in a single transaction: whether the platform authorises the charge...
09/07/2026

In practice, platform classification follows conduct in a single transaction: whether the platform authorises the charge, whether it controls the price presented to the customer, and on whose terms the sale is concluded. Where these point at the platform, EU VAT law treats it as the supplier of everything sold through it — regardless of what the contracts say.

For this reason, classification is the second step of our methodology — before any document is drafted, any payment provider selected, or any company registered. The decision defines the payment flow, the VAT position, the contractual framework and the accounting logic. Taken deliberately, either role can be made to work well. Taken by default, it tends to be established retrospectively, during an audit.

The working test we apply: if the Terms of Service, the checkout page and the invoice were read side by side, would they name the same seller?

The classification is also not permanent. Introducing third-party sellers, an in-platform balance or a new revenue line reopens it — and usually brings DAC7 seller reporting with it. This is why structure reviews sit inside ongoing governance in our methodology, rather than being an emergency measure.

This is why Platform Classification precedes Payment Flow Design in our sequence — every later layer is built on this decision.

From the implementation methodology behind Platform Legal & Tax Architecture.

A structured starting point for a specific setup: https://efinance.ee/assessment (link in bio)

In EU VAT law, a deemed supplier is a platform treated as buying and reselling everything sold through it — even where, ...
08/07/2026

In EU VAT law, a deemed supplier is a platform treated as buying and reselling everything sold through it — even where, commercially, it only intermediates between sellers and customers.

The term usually arrives as a compliance question. In platform architecture it is an operating model, and choosing it — or deliberately staying an intermediary — is a design decision with consequences in every later layer:

→ Payment flow: a deemed supplier collects the full price and accounts for VAT on it; an intermediary settles a commission. Two different provider structures.
→ Contracts: the Terms of Service and the Seller Agreement must place the sale with the right party — documents drafted for one model do not survive under the other.
→ OSS reporting: the deemed supplier reports the full transaction value through OSS; the intermediary reports its fee.
→ Platform accounting: gross versus net revenue recognition — a difference visible in every management report and every investor conversation.

Neither model is inherently preferable — the right one depends on the operating design. Chosen deliberately, both work well; adopted by accident, either becomes expensive to unwind.

Every later implementation decision inherits this choice.

From the implementation methodology behind Platform Legal & Tax Architecture.

A structured starting point for a specific setup: https://efinance.ee/assessment

Two EU VAT rules can make your platform the supplier — and they work differently.Article 9a applies to e-services. Defau...
10/06/2026

Two EU VAT rules can make your platform the supplier — and they work differently.

Article 9a applies to e-services. Default position: your platform is the supplier. To rebut it, the underlying provider must be named in the contract and on the invoice, AND your platform must not authorise the payment, authorise the delivery, or set the terms. Any one of those three triggers — you are the supplier, on the full transaction value, not your commission.

Article 28 is broader — any service supplied in your own name on behalf of another. No presumption. The question is whether you act as principal in name while the substance belongs to someone else. Reseller, white-label, commissionaire — these are Article 28 patterns.

The error: treating them as interchangeable. 9a is narrower but presumes against you. 28 is broader but starts neutral.

More on platform VAT structure on our blog → https://efinance.ee/article?slug=supplier-intermediary-platform-eu-vat

In an EU VAT audit of a marketplace, what decides whether the platform owes VAT on the full transaction or only its marg...
01/06/2026

In an EU VAT audit of a marketplace, what decides whether the platform owes VAT on the full transaction or only its margin is rarely the vendor agreement. It is the Stripe setup.

Article 9a tests two functions in how a sale actually runs: who authorises the charge to the customer, and who sets the price. If the marketplace’s account receives the customer’s payment before splitting it to vendors, the marketplace authorises the charge. If the platform’s pricing engine produced the number the customer saw, the platform sets the price. Either function in the platform’s hands makes the platform the supplier under EU VAT — regardless of what the vendor agreement says.

The implication does not stop at the current quarter. Prior OSS filings get reassessed on the full transaction value, not on the retained commission. The pass-through with underlying vendors creates a mismatch a standard accountant has no reason to look for.

The diagnostic is mechanical: walk through one real sale on your platform. Whose merchant account first receives the customer’s payment? Whose pricing logic produced the price they saw? Either answer pointing to the platform is the gap.

The question worth answering is which of those answers is actually true for your platform — before an audit answers it.

Full breakdown → https://efinance.ee/article?slug=supplier-intermediary-platform-eu-vat

Address

Tornimäe Tn 5
Tallinn
10145

Opening Hours

Monday 10:00 - 17:00
Tuesday 10:00 - 17:00
Wednesday 10:00 - 17:00
Thursday 10:00 - 17:00
Friday 10:00 - 17:00

Telephone

+3726640022

Alerts

Be the first to know and let us send you an email when Electronic Finance OÜ - e-Residency Advisory Hub posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Electronic Finance OÜ - e-Residency Advisory Hub:

Shortcuts

Share