DAC7 Reporting: What a Marketplace Must Collect About Its Sellers

DAC7 marketplace reporting is the EU regime that requires a platform to collect tax data on every seller who trades on it and report, once a year, what each of them earned.

A marketplace does not only report about itself. It reports about other people's earnings: how many sellers traded on it, who they are, and how much it paid them.

This is the kind of obligation nobody can make up for in December. The data you did not collect when the seller registered is not in your system, and you will not work it out from the transactions.

This guide is a map of mechanisms. Which regime covers you, from when, and with which exclusions is settled by your advisor, for your country and your year.

But the shape of the obligation repeats from one jurisdiction to the next, and it has one shared, uncomfortable property: this is a product requirement dressed up as an accounting duty. One missing field in a seller's profile can turn into an obligation to stop paying them.

This article breaks down:

• Which 3 capabilities hide behind one seller report?
• Which number counts as the seller's consideration?
• Why can't you collect this data after the fact?
• Why does a missing field stop a payout?

Key insights

• One obligation is three capabilities: collecting and verifying the seller's own data, computing what went out and what you withheld, and filing on time with a copy to the seller. They live in the registration form, the payout ledger, and an integration.
• One seller produces at least four figures on 100 orders of €1,000: the €100,000 of cart value, the €88,000 after commission, the €86,000 transferred, and the €14,000 of deductions. Which one the report wants is the regime's answer; producing all four per quarter is yours.
• None of the seller's own data can be derived from orders, and a field missing from the registration form is a campaign across 800 sellers, some of whom no longer sell with you and still have to be reported.
• The sanction that bites is an order to act toward the seller: restricted access, or a payout held until the data is completed. Your payout engine therefore needs a block reason that sets itself, lifts itself, and shows the seller what to do.
• A correction is a new filing that points at the original record, so the report has to be stored per seller, per period, and per version. Rebuild it as a query, and today's truth is the only truth you have.

Which 3 capabilities hide behind one seller report?

An obligation that looks like a single task ("file the document") is made of three independent capabilities. Only the third of them resembles reporting.

1. Collect and verify the seller's data. A company name or a first and last name, an address, a tax identifier together with the country that issued it, a date of birth for an individual, a registration number for a company, the country of residence. Some kinds of activity add further fields: the address of the property in a rental, for example. Separately: the identifier of the account the money goes to.
2. Work out how much flowed to that seller and how much you withheld, broken down into sub-periods of the year, usually quarters.
3. File it on time and give the seller a copy of what went out about them.

The first capability lives in the registration form, the second in the payout ledger, the third in an integration. None of the data in point one can be derived from orders.

That data describes an entity, and orders describe sales.

Two traps only show up when you look at the database schema. A tax identifier is not one field but a pair: the number and the country that issued it.

And one seller sometimes has several. The second trap: an account identifier is sometimes treated as "available to you" even when it physically sits with the payment provider you handed payouts to.

Outsourcing the payouts is not outsourcing the data.

The same seller, 3 different numbers: the worked example

A seller sold 100 orders at €1,000 each on your platform. The commission is 12%, so €12,000 stays with you and €88,000 is theirs.

On top of that, you charge €2,000 in service fees for the year, so €86,000 went out to their account.

Which of those numbers is "the seller's consideration" in the report: €100,000, €88,000, or €86,000?

That is not your decision. The definition is picked by the regime, and its interpretation by your advisor.

Your decision is a different one, and it comes earlier: the system has to be able to produce all three, plus the total of the deductions (€14,000) as a separate figure, because the report usually asks about the amount and about the deductions as two different things. If your ledger knows only the amount of the transfer, one of those answers cannot be reconstructed.

Then there is granularity. An annual report is almost never one number.

It is a sum of sub-periods. So those €86,000 have to break apart into quarters, and the order count along with them.

And then the moment where the whole thing starts to hurt: one order from the first quarter comes back in the second. The seller refunds €1,000 and recovers €120 of commission.

Which quarter changes? The one the sale was in, or the one the refund was in?

This is exactly the same two-date problem that "Marketplace Ledger: Why Balances Must Match the Transfer" describes, and exactly the same question about the period that "Marketplace Credit Notes: Which Period Does a Correction Belong To?" settles. The rule belongs to your advisor.

All that belongs to you is making sure the data can answer it both ways. If a correction does not carry the period of the original event, the second answer does not exist.

One last element. As a rule, the seller receives a copy of what went out about them.

That sheet of paper lands on their accountant's desk next to your payout statement. If the two numbers cannot be reconciled, you get a ticket.

This time about why the tax office sees something different from the panel.

Why can't you collect seller reporting data after the fact?

Imagine you have 800 active sellers and one field turns out to be missing. That is not a migration.

It is a campaign: a request, reminders, handling the questions. Some will never answer because they no longer sell with you. And you report about them too, because they traded in the period the report covers.

Hence a hard design rule: a field that is not in the registration form effectively does not exist. Added later to the profile as optional, it gets filled in by a minority, and a minority is not enough, because a report has no "most sellers" mode.

The second thing that is easy to miss: a report concerns a period. A seller changes legal form, address, or number during the year.

The question is what data they had back then. A profile that holds only the current state does not have that answer.

And a third: the documentation behind the report has to outlive the period by several years. An inspection rarely asks about the file itself.

It asks where the numbers in it came from. That runs straight into a deletion request from a seller who is leaving, and it is one of those places where the answer comes from a lawyer.

What is the sanction for missing seller data, and why does it stop payouts?

Enforcement in this class of obligation is unusual. A financial penalty for the platform obviously exists.

There can be a separate one for a late report, for incomplete data, for not handing the seller their copy, and for gaps in the archive.

But the sharpest mechanism of all is an order to act toward the seller.

You meet it in two shapes. The first is escalation: a request, reminders, and once the deadline passes without effect, restricted access to the platform, closure of the account, or a payout held until the data is completed.

The second is withholding part of every payout as long as the tax identifier is missing or incorrect. Countries differ in how sharply they put this.

Some guidance speaks of an obligation, other guidance speaks of a permitted restriction of access. The direction is shared: a missing field stops the money.

The product consequence is very concrete. The payout engine needs a block reason called "reporting gaps": set automatically, lifted the moment the data is completed, visible to the seller together with instructions on what to do.

And a block is not a write-off. The money stays owed, so it has to show up in the balance as blocked rather than simply absent ("How Marketplace Seller Payouts Work: Cycles, Holds, and Reserves" and "Marketplace Ledger: Why Balances Must Match the Transfer").

This is also a second, independent argument for the rule in "Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions": do not open a seller's selling gate before their payout gate. A seller with €88,000 owed and an incomplete profile is not an administrative backlog.

It is a relationship that begins with the sentence "you sold, but we cannot pay you."

Why is correcting a filed report a separate capability?

The report went out. Three months later, one number turns out to be wrong: a refund came in, the seller turned out to be a company rather than an individual, the identifier had a typo.

A correction is not a regeneration of the file. It is a new filing that points to the original record.

To build one, you have to know exactly what you sent: per seller, per period, in the version that actually went out.

Hence a conclusion that decides the architecture: if the report is a query against the database rather than a stored snapshot, you cannot build the correction. Today's query returns today's truth, and you need the difference against the one from six months ago.

It is the same principle as the immutability of an accounting entry in "Marketplace Ledger: Why Balances Must Match the Transfer", one floor up: you correct by appending. The seller's copy has to be fixed the same way.

From market observation: generating the file and fixing it are two different capabilities, and the second one is sometimes delivered as an instruction to "correct it by hand."

How do the 3 kinds of marketplace reporting differ?

What does DAC7 marketplace reporting decide?

1. Seller registration stops being a form owned by marketing

It becomes the place where you collect a complete set of tax data. That is a real conflict with onboarding conversion, and somebody has to settle it deliberately, instead of letting a designer settle it by shortening the form.

2. Deciding who reports inside your group

Several entities can facilitate the same sale: companies inside one group, a platform operating on somebody else's platform, a partner handling payments. The obligation is then sometimes met by one entity on behalf of the rest, but usually on condition that you can demonstrate it.

Assuming "somebody else is surely doing this" is the cheapest way to make sure nobody does.

3. An annual report needs data at a finer granularity than a year

You cannot add the sub-period breakdown after the fact if your entries do not carry an event date. That is "Marketplace Ledger: Why Balances Must Match the Transfer" again.

The same structure serves payouts, accounting, and reporting, so saving on it costs you three times over.

4. Your reporting data and your settlements have to tie out

Where the amounts come from is covered by "How Marketplace Split Payments Work and Who Pays the Fees?". Who is the taxable person on the sale itself is covered by "Marketplace VAT: Are You the Agent or the Principal?" and "Online Marketplace VAT: When Does the Platform Become the Deemed Supplier?".

What happens with invoices and corrections is covered by "Marketplace Invoicing: Who Issues Which Invoice, and When?". This chapter sits on all of them at once.

How do you check DAC7 marketplace reporting with an advisor and a vendor?

1. Questions for your tax advisor

1. Does our platform fall into a regime that requires reporting about sellers, both in the country where we are established and in the countries where our sellers live? Which entity in our group carries the obligation?
2. Which number is the seller's consideration in the report: the value of the cart, the amount after commission, or the transfer that actually went out? And what counts as a deduction?
3. Which sub-period does a refund belong to when it concerns a sale from an earlier sub-period?
4. Which sellers are excluded from reporting? Thresholds exist, but confirm their level with your advisor. And what are we expected to document the exclusion with?

2. Questions for your platform vendor

1. "Show me the tax identifier field together with the country that issued it. Then tell me what data this seller had a year ago."
2. "Show me a payout blocked because of reporting gaps: who sets it, what the seller sees, what lifts it."
3. "Generate a per-seller statement for a year, broken into quarters, with a separate column for deductions. Then show me that it adds up to the payouts."
4. "Show me a correction to a report that has already gone out."

Which mistakes do operators make about DAC7 marketplace reporting?

1. "We will do an export at the end of the year"

The export is easy. The problem is that December is when you find out what you were not collecting in January.

2. An optional field in the profile instead of a required one at registration

Completeness of reporting data is binary, and an optional field gives you a fractional result.

3. The report as a query rather than as a snapshot

It works exactly up to the first correction, and then there is no way to show what changed.

4. A payout block with no path to fixing it

The seller finds out the money is not coming and does not know what to do. That generates escalations faster than any settlement error.

5. Assuming that because the payment provider pays out, they report

They report their own obligations. Yours toward your sellers stay yours, and the data you need sometimes sits in their system.

What do you still have to settle yourself about DAC7 marketplace reporting?

This chapter describes a class of obligation. Five things to confirm by name before you settle the data model:

1. Whether you are covered at all, and by which regime. With a tax advisor. It depends on where you are established, where your sellers are established, what exactly you facilitate, and whether you are paid for it.
2. What the definition of the amount and of the deduction is, and which sub-period a correction goes into. With a tax advisor. Our own claim is narrower and independent of their answer: the data has to let you answer each of those ways, because your advisor picks the rule.
3. Who reports inside your structure, and how to demonstrate that they do it for the other entities. A tax advisor together with a lawyer.
4. Whether and when you are allowed or required to hold a payout, how to write it into the seller agreement, and how to reconcile it with the rules on payment terms. A lawyer. This is the place where a tax obligation collides with a civil law commitment, and you do not want to settle it on your own.
5. How long to keep the data and what to do with a request to delete it from a seller who is leaving. A lawyer, together with whoever is responsible for personal data on your side.

Thresholds, deadlines, and the names of systems deliberately do not appear here. They change faster than documents like this one, and a version memorized a year ago is worse than none at all.

Summary: What has to be in the registration form before the first report?

The seller's name or company, address, country of residence, date of birth or registration number, the payout account, and the tax identifier paired with the country that issued it. Required at registration, versioned so you can say what was true last year, and stored where your own system can reach it even when a provider handles the payouts.

Ask a vendor to show a payout blocked for reporting gaps, and to say what the seller sees on the other side. Talk to a marketplace expert if you want to check what your registration form is missing.

Frequently asked questions on DAC7 marketplace reporting

What is DAC7 reporting for a marketplace?

It is an annual report a platform files about its sellers, covering who they are and how much they earned through it. The platform also has to hand each seller a copy of what went out about them.

Whether your platform is covered, from when, and with which exclusions is a question for a tax advisor, because it turns on where you and your sellers are established and on what you actually facilitate.

What data does a marketplace have to collect about its sellers?

Enough to identify the seller as an entity, which no amount of order data can supply. Name or company, address, country of residence, a date of birth for an individual or a registration number for a company, the payout account, and a tax identifier together with the country that issued it.

The identifier is a pair of fields, and one seller can hold several.

Can a marketplace hold a payout because seller data is missing?

In several jurisdictions it is expected, and in some it is required, once requests and reminders have run out. The money stays owed either way, so it belongs in the balance as blocked.

How and when you may hold a payout, and how that squares with payment-terms rules and your seller agreement, is a question for a lawyer.