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

𝗧𝗵𝗲 𝘀𝗮𝗺𝗲 𝗳𝗼𝘂𝗿𝘁𝗲𝗲𝗻 𝘃𝗶𝗱𝗲𝗼𝘀 𝗰𝗮𝗻 𝗯𝗲 𝗽𝗼𝘀𝘁𝗲𝗱 𝗮𝘀 𝗮 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝗼𝗿 𝘁𝗮𝘂𝗴𝗵𝘁 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝗹𝗶𝘃𝗲. 𝗖𝗼𝗺𝗺𝗲𝗿𝗰𝗶𝗮𝗹𝗹𝘆 𝘁𝗵𝗮𝘁 𝗶𝘀 𝗼𝗻𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁; 𝘁𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶...
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

Registering an Estonian OÜ takes an afternoon. Deciding whether it is the right structure — and how it has to be built —...
31/05/2026

Registering an Estonian OÜ takes an afternoon. Deciding whether it is the right structure — and how it has to be built — is the part that has to happen first.

If you manage the company day-to-day from another country, then place-of-effective-management rules in that country are relevant before you register, not after.

If you sell to EU consumers, then where your OSS VAT registration sits is a structural decision, not an administrative one — and it depends on which entity is the supplier of record.

If you already hold a US or other entity, then the Estonian OÜ is one entity inside a structure, and the split of revenue, contracts and cap table between them is the actual design work.

If none of these are true for you — a single founder, EU-based, selling EU-to-EU — the setup is genuinely simple.

The registration form is the same either way. What differs is everything decided before it is opened.

A founder ends the year with retained profit in the company and no plan to take it out yet.In a Delaware C-corp, that pr...
29/05/2026

A founder ends the year with retained profit in the company and no plan to take it out yet.

In a Delaware C-corp, that profit is taxed when the year closes — whether it is distributed, reinvested, or simply left in the account.

In an Estonian OÜ, the same profit is taxed at 0% for as long as it stays in the company. Corporate income tax — 22% — applies only when profit is distributed as a dividend. Retain it, put it back into hiring or product, and the tax event has not happened.

This is not a loophole. It is the design of the Estonian system: tax follows the decision to distribute, not the calendar.

For a founder reinvesting to grow, the difference is not a percentage on a return. It is whether the company keeps its own capital working — or hands a slice of it to a tax authority before any decision has been made about what that money is for.

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

Website

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

Category