Marketplace VAT: Are You the Agent or the Principal?

On a marketplace, VAT turns on one question: are you the agent, arranging somebody else's sale, or the principal, selling in your own name?

There is a default answer, and it follows directly from the platform model you chose in "Which marketplace platform model should you choose?". It is the only thing in the whole tax layer you can settle without an advisor. That is why it is worth knowing before anyone puts an implementation quote in front of you.

Everything past that one answer depends on the country, on the year, and on the specific flow, so read this as a map of mechanisms. The value is concrete: once you have read it, you can brief your own advisor, and you will not have closed off their path with your data model.

The most expensive mistake in this area is a system that never collected the facts any answer would have to be calculated from.

This article breaks down:

• Why does one marketplace sale produce 2 settlements?
• Who accounts for the tax in each of the 3 models?
• Which 7 facts must your data hold per order line?
• When does the default answer stop applying?

Key insights

• You are the agent in a 3P marketplace and the principal in dropship and one-creditor. The platform model settles it, and it is the only tax answer you can reach without an advisor.
• Every sale is two streams: the goods to the buyer, and your fee for the sale having happened. The model settles who the taxable person is in each of them.
• Your commission is a supply of its own with its own geography. On a service to a business abroad, the duty to account usually moves to the customer, so a seller's number and country are inputs to a calculation.
• Seven facts per order line, from the first order: who the seller is and where, their status and number, where the goods travel, who the buyer is, the classification, the amount split, and in whose name the document went out.
• The default answer stops applying on deemed supplier flows, on foreign sellers and imports, and in jurisdictions that make you withhold tax from the payout.

Why does one marketplace sale produce 2 separate settlements?

The buyer sees one payment and one document, so they assume there is one sale. In a marketplace, there almost never is.

There are always two independent streams: the sale of the goods to the buyer, and your fee for the fact that the sale happened. The platform model settles both at once: who the taxable person is in the first stream, and whether the second one exists as a separate supply at all.

• Marketplace (3P): the taxable person is the seller. You provide them an intermediary service, and that is your own separate sale.
• Your own sale, dropship included: the taxable person is you. You buy and resell, so both sides of the transaction are yours.
• One-creditor: there are two supplies of goods. The seller supplies you, and you supply the buyer, which means two settlements from one transaction.

That is all the certainty you have without an advisor. The rest of this article shows what follows for your documents and your data.

One cart, 3 models: the worked example

A cart worth €1,000, a commission of 12%, and €880 landing in the seller's account. The same transaction looks completely different across the three models.

In a marketplace, the seller sells to the buyer for €1,000, and you sell the seller a service for €120. The buyer gets one document.

The seller gets two: their own sales document and your commission invoice. The consequence that matters: the seller's taxable amount is €1,000.

The €880 is merely the only figure they ever see on a bank statement. Netting the commission off the payout is how the two of you settle up.

It is not a reduction of the price toward the buyer.

In the one-creditor model, the seller sells to you for €880, and you sell to the buyer for €1,000. The commission disappears as a separate service: in European VAT the fee of an intermediary acting in their own name is treated as the difference between two prices.

There is no commission invoice, because there is nothing to invoice.

In dropship, the supplier invoices you at their price, you invoice the buyer at yours, and the difference is your margin. There is no commission at all.

Notice what just happened to a single number. The same €120 is a service fee in one model and a price difference in another.

Economically identical, and completely different on paper and in tax: different documents have to exist, different amounts enter the records on both sides, and the correction after a refund looks different.

Why is your commission a separate sale with its own tax rules?

This is the part operators discover last: the answer "the taxable person is the seller" covers the first stream only. The second, your €120, is your own sale, and it runs on separate rules.

They depend above all on where the seller is established and whether they are a taxable person. On a service to a business in another country, the duty to account usually moves to the customer, and you issue a document with no tax on it but with that customer's identification number.

That assumes you hold the number and it is valid. The rule has conditions and exceptions no article can settle for you.

The product consequence, though, is unambiguous: a seller's identification number and country of establishment are not fields in a profile. They are inputs to a calculation.

If onboarding leaves them optional, then the first seller from abroad arrives, and you cannot issue a correct commission invoice; by then their offers are live, and their orders are in the system.

Which 7 facts must your system record on every order line?

This is where the practical value of the article sits. An advisor will calculate nothing for you if the data does not hold the facts the answer is calculated from.

And the facts have to be collected from the first order, because a history you never recorded cannot be reconstructed.

Your system should know at least this much, separately for every order line:

1. Who the seller on that line is and where they are established. Not the "store" but the legal entity: the country of registration decides whose turnover this is and whether the exception described in the next article applies.
2. Whether that seller is a taxable person, and under what number. Two offers of the same product at the same price can carry different tax for the buyer, because the sellers hold different status. The price on the page does not show it. The document does.
3. Where the goods physically travel from and to. A shipping address on every line, because a store's registered office says nothing about where the goods travel. That is what decides whose rules you apply.
4. Who the buyer is. A consumer or a business, and if a business, whether they gave an identification number. On a cross-border transaction between businesses, the duty to account can move to the buyer.
5. The tax classification of the goods. A code that lets the treatment be established. A rate typed into the offer by hand is somebody's answer from one particular day.
6. The amount broken out into goods, shipping, and discount. Shipping cost usually follows the fate of the goods, so it cannot be one figure on an order with several sellers behind it. On a discount, the system has to say who funded it, because that is where the question of whose turnover falls begins.
7. In whose name the document was issued. Self-billing moves nothing in tax terms: you issue the document as a technical matter, and the seller is still the taxable person. It does require a prior agreement and an acceptance procedure on the seller's side. That is a function in the system.
8. The overriding rule reads like this: do not store answers in your data schema; store the facts the answer is calculated from. A rate as a field on an offer is a stored answer: one given by the seller on the day the offer went up.

A classification code, the countries of both parties, and their status are facts. The data has to let you calculate the settlement both ways, because your advisor picks the rule. And they pick it again at every change in the law and on every new market.

How do the 3 models compare on who accounts for the tax?

When does the default answer stop applying?

Each of these can void the table above for part of your orders.

1. The rules can treat the platform as the taxable person

That is the subject of the next article and the most common surprise in this layer: you can be an intermediary in civil and commercial terms and the taxable person on part of your flows at the same time.

2. Sellers based abroad and imported goods

Separate enough to have a chapter of their own. If you plan for them from the start, that conversation belongs to the data design.

3. A third answer: withholding at the payout

In some jurisdictions outside Europe, the law requires the platform to withhold tax from the seller's payout and remit it to the authority. You are not the taxable person then, but the collector.

The payout stops being a simple difference between the sale and the commission.

4. Your role is classified by what you actually do

In practice, platform contracts are often drafted with no thought for tax, while the assessment looks at who sets the conditions of sale, who authorizes the charge to the buyer, and whose name the buyer sees. If your checkout does all three, the wording in your terms may not be enough on its own.

What does marketplace VAT change about your other decisions?

1. You order the data schema together with the model

It is the only decision in this article that you take before launch, and that cannot be topped up retroactively. An advisor can change the rest later.

2. Your revenue line comes out of the same structure

In a marketplace, the revenue is the commission. In dropship and in one-creditor, it is the whole GMV, so the same sale gets reported an order of magnitude apart.

Agree on this with your finance team early. A separate chapter on revenue in the books develops the thread.

3. Seller onboarding stops being a form

Country, tax status, and identification number become data that blocks selling, the same way payout details do in "Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions". A seller with published offers and incomplete tax data is a liability.

4. Refunds and corrections inherit this structure

If there are two streams, then there are two corrections: one to the sale and one to the commission. "Marketplace Ledger: Why Balances Must Match the Transfer" describes the balance side.

The document side gets a separate chapter on corrections.

How do you settle VAT with your advisor and your vendor? 6 questions

1. Three questions for your tax advisor

Bring the model description and a concrete example with amounts:

1. On a €1,000 cart at a 12% commission, who accounts for the tax, and on what amount? Answer separately for the sale to the buyer and for our commission.
2. Which of the flows we are planning fall outside that answer, and what piece of data do you need on every order to recognize them?
3. Should we be issuing documents on behalf of sellers, and if so, what consent and what acceptance procedure does that require?

2. Three questions for the platform vendor

Ask them at the demo, and ask to be shown rather than told:

1. Show me an order with two sellers from different countries and point to where the data holds each seller's country and the shipping address of each line.
2. Is the rate a field on the offer, or the result of a calculation from the classification and the countries? If it is a field, who fills it in, and what happens when the law changes?
3. Can a document be issued in the seller's name, with a path for the seller to accept it, or is this just PDF generation?

Which mistakes do operators make about marketplace VAT?

1. The rate as a field the seller types in

Convenient at the start, unfixable for a thousand sellers, and the first change in the law. It is a stored answer instead of facts.

2. Confusing the transfer with the taxable amount

The seller sees €880 and treats that as the sale. Their mistake, your cost.

It comes back as a settlement dispute and a phone call from their accountant.

3. "We are only an intermediary" written in the terms and contradicted by the checkout

The role follows from how the transaction works.

4. A single country baked into the data model

A seller with one address and one rate is enough until the day you enter a second market or take on your first seller from abroad. Then it is a migration.

5. Putting the subject off until after launch

"We will polish it after the pilot" fails here for a technical reason: missing historical data cannot be added retroactively.

What do you still have to settle yourself about marketplace VAT?

This is a map of mechanisms, not a tax opinion, and it deliberately carries no rates, no thresholds, and no dates. Those change faster than any document can.

Confirm five things by name before you fix your data model.

1. How your role is classified in your country and for your flows. Whether you act in the seller's name or in your own. Ask a tax advisor and a lawyer together, because the question is at once a tax question and a civil law one.
2. How your commission is accounted for toward sellers based abroad. Who accounts for it, on what conditions, and what evidence you have to keep. Ask a tax advisor.
3. Whether you may issue documents in a seller's name, and in what form consent and acceptance have to be given. Ask a lawyer, and expect consequences for what the system has to do.
4. Which flows fall outside the default rule. Sellers based abroad, imported goods, digital goods, services. Ask a tax advisor before launch.
5. The treatment of shipping costs and of discounts you fund yourself. Whose taxable amount they reduce, and how they have to be broken out in the data. Ask a tax advisor and your own accounting team.

Our claim is narrower than any of those answers and independent of them: the data has to let you answer every one of those ways. A platform that settles the answer inside its schema takes away your right to change your mind. And the legislator will change it for you.

Summary: What can you settle without an advisor?

Exactly one thing: which model you are in, and therefore who the taxable person is on each of the two streams. Everything past that needs your country, your year, and your flows.

What you owe your future advisor is a data model that can still answer either way.

Ask a vendor to show you an order with two sellers from different countries, on screen. Talk to a marketplace expert if you want those seven facts checked against your own order line.

Frequently asked questions on marketplace VAT

Who accounts for VAT on a marketplace?

In an agency marketplace, the seller does, on the full price the buyer paid. You account separately for your own commission, which is a distinct supply with its own rules.

In a one-creditor or dropship model, there are two supplies of goods, and you are the taxable person on the second one.

Is a marketplace an agent or a principal for VAT?

It follows from how the transaction actually works, whatever the label in your terms says. The assessment looks at who sets the conditions of sale, who authorises the charge to the buyer, and whose name the buyer sees.

A checkout that does all three is hard to describe as pure intermediation.

What data does a marketplace need for VAT?

Seven facts on every order line, from the first order onward. Who the seller is and where they are established, their tax status and number, where the goods travel from and to, who the buyer is, the classification of the goods, the amount split into goods, shipping and discount, and in whose name the document was issued.