Marketplace E-Invoicing: What Changes When You Invoice for a Seller?

Marketplace e-invoicing is the case where your platform produces a seller's invoice and a national system decides whether that invoice legally exists.

Issuing invoices on a seller's behalf looks like a courtesy: they do not have to integrate, the buyer gets a full set of documents, and your data stays tidy. As long as those documents travel by email, that is exactly what it is.

Once a mandatory national system stands in the middle of the flow, the same courtesy turns into an operating obligation. You become the technical issuer, your integration decides whether the document came into existence at all, and the tax liability stays with the seller.

The work moves to you. The risk does not move off them.

This is a map of mechanisms, not a tax answer: which regime covers you, from when, and how far it reaches depends on the country and on the year, and the timetables here have moved more than once. What follows outlasts any date.

It shows what data your system has to carry so that a tax advisor has something to pick a rule from. It also shows what you cannot backfill later.

This article breaks down:

• Which 3 activities hide behind invoicing for a seller?
• What changes when a national system stands in the middle?
• Which 5 pieces of data must your system carry?
• Who handles outages, rejections, and archiving?

Key insights

• Once a national system stands in the middle, the invoice is a structured file, and your integration decides whether it exists at all. The PDF is only a picture of it.
• Three different activities hide under one name: issuing in the seller's name, self-billing, and your own commission invoice. Each runs on a different legal basis and carries different risk.
• One order produces two documents or three, and they can fail separately. Your €120 commission invoice goes through while the seller's €1,000 is rejected and formally never existed.
• Five pieces of data, and the first is the one most systems lack: legal issuer and technical issuer as separate fields on every document.
• Rejections create a job nobody has today. Somebody reads the queue every day, and the seller cannot, because the error is usually in the buyer's data.

Which 3 activities hide behind invoicing on a seller's behalf?

Three operations sit under one name, on different legal bases and with different risks. If you do not separate them, your advisor answers a different question from the one you asked.

1. Issuing in the seller's name and on their behalf

The document the buyer receives is the seller's invoice, because the seller is the taxable person, but your system technically produces it. The market calls that white-label invoicing.

The key trait: the execution moves to you, and responsibility for the document being correct stays with the seller.

2. Self-billing

You issue a document that you are the recipient of. The standard case is the seller's invoice to you in the one-creditor model ("Which marketplace platform model should you choose").

Under EU rules, this construction is allowed conditionally: it requires a prior agreement between the parties and a working procedure for the seller to accept each invoice. This is not a box to tick in your terms of service.

Acceptance can be tacit, but you have to be able to show it during an inspection.

3. Your own commission invoice

The only one of the three documents where you are the seller. It runs on its own path, from your authorizations and your data.

On top of that comes a distinction that was invisible on paper and is fundamental inside a national system: who is the legal issuer and who is the technical one.

What changes when a national system stands in the middle?

1. The invoice is a structured file, the PDF is a picture of it

Where the obligation applies, the legal document is a file in a prescribed format, and the PDF is a rendering. "We will generate a nice PDF and email it" stops being invoicing.

It gets worse. If the PDF says something different from the file, you risk it being treated as a second document with a tax liability of its own, because in many systems whoever issues a document showing tax owes that tax.

The rendering has to come from the accepted file, never alongside it.

2. The order of events stops being yours

In the family of regimes where the document passes through an administrative gateway before it reaches the buyer, the invoice legally exists only once it is accepted. A rejected invoice is an invoice that never was.

In the network family, where the document travels between certified intermediaries, you control the moment of issue, so an error does not block the transaction. It surfaces later, at an inspection.

3. The system assigns its own identifier

Later corrections attach to that identifier rather than to your invoice number. Your numbering stops being the only key.

4. Data quality becomes a block on selling

A wrong tax identifier for the buyer is not a defect to clear up next quarter. It is a rejection in real time.

One order, 2 documents or 3: the worked example

Take the canonical cart from this series: €1,000, a commission of 12%, and €880 left for the seller.

In the commission model, two documents arise: the seller's invoice to the buyer for €1,000 (legal issuer: the seller; technical issuer: you) and your commission invoice to the seller for €120 (legal and technical issuer: you).

In the one-creditor model, a third one appears: the seller's invoice to you for €880, self-billed by you and requiring their acceptance.

Now a failure that is not a technical failure. The €1,000 invoice is rejected because the buyer gave a tax identifier that does not pass validation.

Your €120 invoice goes through because it runs on your own authorizations and your own data. The result: the money is split, the commission is invoiced, and the document for the buyer formally does not exist.

This is an axis that "Marketplace Ledger: Why Balances Must Match the Transfer" does not have. There, we made sure the number in the panel equals the transfer.

Here a second state appears, independent of the first: whether the document was accepted by the system.

The customer returns the purchase in the following month. Two corrections arise, with different owners: the credit note against the €1,000 invoice, which you issue in the seller's name and which has to point to the identifier the system gave the original, and the credit note for your own €120 of commission.

That second one is your document, on your path. One economic event, two documents, two regimes of authorization.

Which 5 pieces of data must your system carry?

This is the core of the whole article. The point is not for you to know how to invoice.

The point is for your system not to close off your advisor's options.

1. Legal issuer and technical issuer: separate fields on every document. This document is seller X's invoice, technically issued by you, and that one is your own.
2. The identifier and the status from the system, sitting on the order. Accepted, rejected, pending; the rejection code; the history of attempts. If the document status lives in an integration log instead of on the order, customer service cannot answer "where is my invoice."
3. A separate, unbroken numbering series for every seller you issue for. A hundred sellers means a hundred series. Settle up front what happens to a series when a seller leaves or changes legal form.
4. The scope and the term of the authorization. From when to when the seller authorized you to issue, for which document types, and what happens to the queue when the authorization is withdrawn in the middle of the day.
5. The seller's status and the buyer's type, measured against the regime. You need the seller's country of establishment and their registration. Entities without an establishment in a given country are sometimes outside the obligation, sometimes covered by a narrower reporting duty. You also need the buyer's type: in most regimes we know of, the obligation aims at sales between businesses, though there are exceptions that reach consumers. A marketplace has both sitting in one cart.

None of these five tells you how to invoice. Your advisor picks the rule. They settle something else: whether there will be anything for them to pick from.

What do you do about outages, rejections, and archiving?

1. An outage on their side is your operational problem

Regimes usually provide a fallback mode: you issue outside the system and file it later, within a set deadline. Confirm that deadline for your own country.

The product question is independent of those details: can your system queue documents, flag them, and file them later, or does it stop the flow until the gateway returns?

2. Rejections create a role you do not have today

Somebody has to look at the rejection queue every day, understand the codes, and fix the data. The seller will not do it.

They have no access to your integration, and the error is often in the buyer's data. At a thousand documents a day, even a fraction of a percent is a permanent job.

3. Archiving is a separate obligation

Under EU rules, for the whole retention period you have to guarantee authenticity of origin, integrity of content, and legibility of the document, available on demand for inspection. Retention is counted in years and differs between countries, as do the rules on where they may be kept.

Put the question early: who archives a document issued in someone else's name (you, the seller, or both of you). Then settle what happens to the archive after you part ways.

4. Multiple countries multiply all of it

There is no single format and no single gateway: every market is a separate integration, separate authorizations, and a separate fallback procedure.

How do the 2 families of e-invoicing regimes compare?

You do not choose between them. The country you sell in chooses for you. You only choose whether your architecture can carry both, because on expansion it will have to.

What does marketplace e-invoicing change about your other decisions?

1. Seller onboarding gains a step that cannot be done self-service

Granting an authorization to issue in someone else's name is a formal act on the seller's side, often inside a government system your platform has no access to. For a foreign seller, it is sometimes a barrier they cannot get past, and at that point it is no longer a tax problem but a limit on your growth.

2. Invoicing stops being a feature and becomes a process with a duty roster

A queue, rejections, a fallback mode, late filings. That is a line in your operating costs the business case usually does not contain.

3. From now on, an order has two states: the money state and the document state

"Marketplace Ledger: Why Balances Must Match the Transfer" described the first one, and "Who Keeps the Marketplace Commission on a Refunded Order?" covers what happens to the commission on a refund. The document side of corrections, and how they are assigned to periods, is the next article.

4. This gets settled together with the model

Who sells and who is the taxable person ("Marketplace VAT: Are You the Agent or the Principal?", "Online Marketplace VAT: When Does the Platform Become the Deemed Supplier?" and "Marketplace Invoicing: Who Issues Which Invoice, and When?") determines how many documents arise on a single order, and therefore how many paths you have to maintain.

How do you check e-invoicing with a vendor? 6 questions

Six questions for the vendor. Ask to be shown this on a working system.

1. "Show me an invoice issued on a seller's behalf and tell me who its legal issuer is in your data model." If the system has a single "issuer" field, the distinction does not exist.
2. "Where do I see the document status on the order, and what does customer service see when a document has been rejected?"
3. "What does the numbering look like when you issue for a hundred sellers?" You want a hundred separate, unbroken series.
4. "What does the system do when the national gateway is down for half a day?" The right answer describes a queue and a later filing.
5. "How do you issue a credit note, and what ties it to the original?" The system's identifier has to come up alongside your invoice number.
6. "What happens to the documents of a seller who withdraws the authorization or leaves the platform?"

One control question for you: is anyone in your organization accountable today for a seller's document being accepted by the system? If the answer is "the platform," the answer is nobody.

Which mistakes do operators make about marketplace e-invoicing?

1. Treating invoicing on a seller's behalf as a convenience

It is an operating obligation with a duty roster and a queue.

2. Assuming that issuing the document means taking on the liability

It usually works the other way round, and that is worse: you do the work, and the seller answers to the tax authority for a faulty document. They then come to you with it, because it was your system that got it wrong.

Put the split of liability in the contract before you issue the first document.

3. The PDF is treated as the document

A rendering that has drifted from the file is not an aesthetic problem. It is the risk of a second tax liability.

4. Collecting the authorization after launch

A seller live in the catalog without an authorization sells and generates documents that cannot be issued. This is a condition of admission to selling.

5. Invoicing hard-wired into the core of the platform

Regimes and formats change, and new countries get added. Rewriting the core for a new format is a cost nobody planned for.

What do you still have to settle yourself about marketplace e-invoicing?

There is deliberately not one date, rate, or name of a national system here. A document with a date in it ages faster than it gets read.

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

1. Whether, in your country and in your model, you are allowed to issue in a seller's name at all. If you are, what form the authorization takes and whether it can be withdrawn retroactively. Tax advisor and lawyer.
2. What conditions self-billing has to meet if you use it: what the prior agreement looks like, and how you demonstrate the seller's acceptance procedure. Tax advisor.
3. Who bears the consequences when a document is rejected or is not issued on time? Then how to divide that between you in the contract with the seller, given that the rules divide it differently. Lawyer.
4. What retention period and what method of archiving apply to documents issued in someone else's name, who holds them, and what happens to them after you part ways with the seller? Tax advisor and lawyer.
5. Which flows in your cart fall under the obligation and which do not. The split runs by buyer type, by the seller's country of establishment, and by where the goods came from. That is the same data that settles whether the platform is treated as the deemed supplier for VAT ("Online Marketplace VAT: When Does the Platform Become the Deemed Supplier?"). Tax advisor.

Our claim is narrower than any of those answers and independent of them: the data model has to let you answer all five ways, because your advisor picks the rule. A system that knows one answer cannot be reconfigured when the rule changes.

It has to be rewritten.

Summary: What does a national system take away from you?

Control of the moment of issue, and the assumption that a document exists because you sent it. What you keep is the data model: legal and technical issuer held apart, the system's identifier and status on the order, an unbroken series per seller, the scope of each authorization, and the seller and the buyer measured against the regime.

Ask a vendor what the system does when the national gateway is down for half a day. Talk to a marketplace expert if you want to see legal and technical issuer held apart in a working schema.

Frequently asked questions on marketplace e-invoicing

What is e-invoicing on a marketplace?

E-invoicing makes the invoice a structured file that travels through a national system, so on a marketplace your platform becomes the technical issuer of somebody else's document. The seller stays the legal issuer and the taxable person.

The work moves to you, and the liability does not move off them.

Who is liable when an invoice issued by the platform is rejected?

The seller answers to the tax authority, and then comes to you, because it was your system that produced the document. That asymmetry is the reason to divide the consequences in the seller contract before the first document goes out, rather than after the first rejection.

Can a marketplace issue e-invoices on behalf of sellers?

Usually yes, with formal authorization from the seller, which is often granted inside a government system your platform cannot reach. That makes it a step in onboarding that cannot be self-service, and for a foreign seller, it is sometimes a barrier they never get past.