Marketplace Invoicing: Who Issues Which Invoice, and When?

Marketplace invoicing is the question of who issues which document when one sale involves three parties: the seller, the buyer, and you. The question sounds like one question. The answer is at least three documents, issued by different parties, at different moments, out of separate numbering series.

Teams that did not pull them apart before launch find out in the first month: a business buyer asks for an invoice, and nobody knows who is supposed to issue it or where that buyer's tax number comes from, because checkout never asked for it.

This is a map of mechanisms, not tax advice. Which of them applies to you depends on your country, your model, and the year, and your advisor settles it.

The value of this text is narrower and more practical: before your advisor can answer you at all, your system has to hold specific data. If you are not collecting it, you close off the path, and even the best answer will be impossible to implement.

This article breaks down:

• How many documents does one marketplace sale produce?
• Who is the issuer, and who merely produces the document?
• How does self-billing differ from a white-label invoice?
• Which 7 things must your data hold first?

Key insights

• One sale produces at least three documents: the seller's invoice to the buyer, your commission invoice to the seller, and the payout statement, which is not a tax document at all.
• Producing a document does not make you its issuer. In someone else's name, the seller stays the issuer. In your own name, you become a party to the sale, with liability for the goods.
• Self-billing runs the other way: the customer issues for the supplier. It never arises in a pure agency marketplace, only where you actually buy.
• Seven things before any invoice: both parties as of the moment of sale, the buyer's status from checkout, a numbering series per issuer, two dates, amounts totalling per rate and per line, room for annotations, and one identifier across the set.
• Retention sits with the taxable person the document concerns, even when your system produced it. Your platform cannot be the only place the document exists.

How many documents does one marketplace sale produce?

The example that runs through this article: a cart of €1,000, a commission of 12%, the seller receives €880. It looks like one transaction.

It produces three independent documents, between three different pairs of parties.

1. The seller invoices the buyer for €1,000

This is the sales invoice for the goods. Its parties are the seller and the buyer.

You do not appear on it. In an agency model, it is the only document the buyer sees.

It is also the only one showing who really sold to them.

2. You invoice the seller for €120

This is the commission invoice for your service: the platform, the traffic, the operations. It is not a "part" of that sale.

It is a separate transaction between two companies, so it runs by its own rules: where the place of supply of the service sits, who accounts for tax on it, and in which currency.

3. The payout statement for €880

This is not a tax document. It is a settlement record: it shows how €1,000 became €880, and it has to add up to the transfer to the cent ("Marketplace Ledger: Why Balances Must Match the Transfer").

And an arithmetic trap that only becomes visible after launch. If tax is due on the commission, the commission invoice and the deduction from the payout stop being the same number.

The statement says "minus 120," the invoice is made out for a different total. Either somebody designed it for that, or both sides' accounting teams square it by hand every month.

A fourth document is sometimes invisible. Payment provider fees and advertising fees have an issuer and an addressee of their own, which need not be the parties above.

Before you promise sellers "one settlement," work out which of them reaches them directly from a third party ("How Marketplace Split Payments Work and Who Pays the Fees?").

And in some arrangements one sale turns into four documents. The law can treat the platform as the supplier for tax purposes and cut a single commercial sale in two: the seller to you, and you to the buyer.

The seller then issues a document to you, you issue one to the buyer, and the commission invoice stands regardless. Treatment of that first leg varies between jurisdictions.

The mechanism is universal; the answer is local. When that fiction switches on is explained by the chapter on the platform becoming the taxable person instead of the seller.

Who is the issuer, and who merely produces the document?

Tax systems usually allow three paths: the supplier issues the document, the supplier's customer issues it, or a third party issues it in the name and on behalf of the supplier. That third path is you, whenever your platform generates the PDF for a seller's sale.

It often gets called a white-label invoice, because the document looks like yours and formally is not.

1. In someone else's name: the seller stays the seller

You produce the document, but the issuer is still the seller: their details, their tax number, their numbering series, and their responsibility for the content. Outsourcing invoicing to an accounting firm or to a platform does not move tax responsibility onto whoever does the work.

Your risk is a different one, and it is contractual: you supply the data that somebody else's document gets built from. If your system assigns the wrong rate or drops a required annotation, the consequences land on the seller, and the seller brings them to you.

2. In your own name: you become the seller

If your company appears on the document going to the buyer, you are a party to that sale, with liability for the goods and the tax settlement. It is the cleanest known way to become a seller by accident ("Which marketplace platform model should you choose" and "What Is the Merchant of Record in a Marketplace?").

The conclusion for the buying stage: "Can the platform issue invoices?" is the wrong question. The right one is: in whose name, out of whose numbering, and who answers for the content.

How does self-billing differ from a white-label invoice?

These two get confused constantly, because in both the document is produced by somebody other than the seller. What separates them is direction.

1. White-label

You produce it; the seller issues it. You are the technical producer.

2. Self-billing

The customer issues it for the supplier. You issue the invoice that the seller should have issued to you. In a classic agency marketplace, it never arises, because you buy nothing from the seller. It shows up exactly where you do buy: in the one-creditor arrangement, in dropship, and on that first leg where the law treats you as the supplier.

The mechanism is not a European peculiarity. Other tax systems run it as a document issued by the recipient of the supply, hedged with conditions there too.

The conditions repeat often enough that they are worth knowing as a class: a prior agreement between both parties, a procedure for the supplier to accept the document, an undertaking from the supplier not to issue a second document for the same transaction, and an explicit annotation that the customer issued it.

For you, this is not legal trivia. It is a product requirement: the agreement and the acceptance have to be events in the system, with a date and a trace. An attachment in a salesperson's email is neither.

Which 7 things must your data hold before any invoice can be issued?

No article can tell you which rule your advisor will pick. This one can tell you what they cannot pick any rule without.

1. Both parties identified as of the moment of sale

A seller changes legal form or tax number. Practitioners describe what happens next: somebody opens a new account, because old documents cannot be reassigned to the new entity.

A document issued yesterday has to stay with the entity that existed then.

2. The buyer's status, captured at checkout

Whether an invoice has to be issued usually depends on whether the buyer is a business and whether the sale crosses a border. If the cart does not ask for a tax number at the moment of the order, the data ends up in the "notes" field, and no correct document comes out of it.

Practitioners describe that workaround as everyday.

3. A separate numbering series per issuer

The number has to be continuous and unique inside its series. Produce documents in the name of a hundred sellers and you need a hundred continuous series.

Otherwise, every seller has gaps in their numbering wherever somebody else made a sale.

4. Two dates: issue and delivery

The date of issue and the date of delivery or performance. They come apart more often than people expect, and it is those two that decide the period the document belongs to ("Marketplace Ledger: Why Balances Must Match the Transfer").

5. Amounts that total per rate, per currency, and per line

The exchange rate is frozen at the moment of the event. Shipping cost needs an allocation rule of its own: in the typical treatment shipping follows the goods it carries, so in a cart with two sellers you have to know which part belongs to which invoice.

6. Room for annotations

Who issued the document, who accounts for the tax, which special procedure applies. These are not ornaments.

They are phrases whose absence can undermine the document. The system has to place them conditionally, out of the data.

Fixed text in a template cannot do it.

7. One identifier tying every document from an order

Without it, nobody can reconstruct that the seller's sales invoice for €1,000, your commission invoice for €120, and the statement line for €880 all describe the same event.

The overriding rule is the same as in the ledger: the data has to let you issue the document several different ways, because your advisor picks the rule. A platform that picked on their behalf did not simplify the project.

It closed off options.

Who has to archive a marketplace invoice?

The answer surprises people most often: the duty to retain a document sits with the taxable person it concerns, and it sits there even when somebody else issued it for them. The seller has to hold copies of their own invoices, even if they never laid eyes on them, because they came into existence inside your system.

Three product consequences follow:

1. The seller needs durable access to the copies, and access has to outlive their account.
2. Your platform cannot be the only place where the document exists. Otherwise, a migration, or parting ways with a seller, becomes a legal problem.
3. The retention period and the acceptable format are set nationally, and with sellers from several countries, more than one rule applies at once. That is a question for your advisor.

How do the 5 documents compare?

What does marketplace invoicing change about your other decisions?

1. The decision to issue on behalf of sellers costs more than it looks

Producing a PDF is cheap. What is expensive is everything that sticks to it: numbering per seller, the archive, handling rejections and corrections, and the role of the technical issuer with the whole compliance burden it carries, in countries that require invoices to travel through a public system.

2. The model settles the documents

If a buyer requires one invoice from one entity, invoicing in someone else's name does not solve it. That is a change of model ("Which marketplace platform model should you choose").

3. A correction is a separate document with a period assignment of its own

A refund from "Marketplace Refunds: Who Pays for Them and Out of What?" and "Who Keeps the Marketplace Commission on a Refunded Order?" does not change the original invoice. It adds a credit note to it, which is the subject of a separate chapter on corrections and periods.

How do you brief your advisor and check a vendor? 8 questions

1. Four questions for your advisor

Ask them with a description of your model attached, never in the abstract:

1. Who is the issuer of the document for the buyer in our setup, and are we allowed to produce it on a seller's behalf?
2. When is a document mandatory and when is it only on request, answered separately for business buyers, consumers, and sales outside the country?
3. Does self-billing occur in our setup, and if it does, what agreement and what acceptance procedure does it require?
4. How do we invoice commission to sellers based in other countries, and what data about them do we need for that?

2. Four questions for a vendor

Ask to be shown on screen:

1. "Show me a document issued in a seller's name and tell me whose series its number comes from."
2. "A seller changes legal form and tax number. What happens to the documents already issued for them?"
3. "Where do you collect a business buyer's tax details, and what happens when they supply them after the order?"
4. "A seller leaves. For how long and in what format do they keep access to their documents?"

Which mistakes do operators make about marketplace invoicing?

1. Treating the invoice as a printing feature

A document is not a PDF. It is a set of data, roles, and responsibilities.

Buy "invoice generation," and you get invoice generation. The rest you build yourself.

2. One shared numbering series for all sellers

Convenient in the database, awkward when you have to explain why one seller's consecutive documents sit several hundred numbers apart.

3. Collecting the buyer's tax details after the order

The issuer finds out who they sold to only once the sale is done. That is the one piece of information deciding the shape of the document.

4. An agency model with an invoice in your own name

The single most expensive mistake in this layer: it changes your role without any board decision.

5. Treating the payout statement as an accounting document

The statement explains the transfer. It is not the basis for a tax settlement.

It gets used as one anyway, until somebody asks.

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

It settles nothing that depends on your country, your model, and the year. In this subject, that is most of it.

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

1. Whether your arrangement lets you issue documents in a seller's name, and what consents, agreements, and powers of attorney it requires (a tax advisor and a lawyer).
2. When a document is mandatory and when another proof of sale is enough. The rule differs for business buyers, for consumers, and for cross-border sales, and for consumer sales a separate body of rules can call for a completely different document or device (a tax advisor).
3. The conditions for self-billing: the content of the agreement, the method of acceptance, the consequences of its absence (a tax advisor).
4. The retention period, the acceptable format, and where the archive may sit, separately for every country you have sellers from (a tax advisor).
5. Who is liable when a document issued by your system turns out to be defective. That is a contractual question between you and the seller. Put it to a lawyer.

This guide deliberately gives no rates, no thresholds, and no dates on which rules take effect: they change faster than the text, and a number quoted from memory is worse than no number.

Summary: What has to be true before you issue anything?

Both parties identified as of the moment of sale, the buyer's status captured at checkout, a numbering series per issuer, two dates, amounts that total per rate and per line, room for annotations, and one identifier tying the set together. Once those exist, a rule can be chosen.

Before they exist, none can.

Ask a vendor to show a document issued in a seller's name, and to say whose series the number comes from. Talk to a marketplace expert if you want to walk the three documents through your own model.

Frequently asked questions on marketplace invoicing

Who issues the invoice on a marketplace?

In an agency marketplace, the seller issues the invoice to the buyer, and the platform issues a separate commission invoice to the seller. The payout statement is a third document, and it is not a tax document at all. Whoever produces the file is a separate question from who the issuer is.

Can a marketplace issue invoices on behalf of sellers?

Usually yes, as a third party issuing in the name and on behalf of the supplier. The seller stays the issuer: their details, their tax number, their numbering series, their responsibility for the content. Your exposure is contractual, because you supply the data the document is built from.

What is self-billing on a marketplace?

Self-billing is the customer issuing the document on behalf of their supplier, so it runs the opposite way to a white-label invoice. It never comes up in a pure agency model, where you buy nothing. It appears wherever you do buy: one-creditor, dropship, and the first leg where the law treats you as the supplier.