What Is DAC7? EU Platform Reporting Directive Explained

DAC7 at a glance#

DAC7 is Council Directive (EU) 2021/514, which extends EU tax cooperation to require reporting platform operators to collect, verify, and annually report information about reportable sellers and their platform earnings. The rules apply from 1 January 2023; DAC7 creates reporting obligations, not a new tax on sellers.

The European Commission’s DAC7 overview identifies four covered activity categories: rental of immovable property, personal services, sale of goods, and rental of any mode of transport. The reporting obligation covers domestic as well as cross-border activity.

For scope, test the legal operator and relevant activities, then identify reportable sellers and applicable exclusions. Keep unresolved classification questions separate from settled collection and verification requirements.

Keep a written scope log with the legal entity, activity, EU connection, exclusion basis, source, reviewer and decision date. Confirm the national filing process with the competent authority; a VAT registration or OSS decision is not a DAC7 scope determination.

Use the definition and scope tests first, then the operating controls below to build a repeatable seller-data and reporting cycle.

What DAC7 requires from platform operators#

Reporting platform operators must collect and verify reportable seller information and report annually by 31 January after the calendar year being reported. Preserve filing evidence and seller-level support for corrections or authority follow-up.

The reporting contains identification and financial information, including consideration paid or credited through the platform. The Commission overview explains the operator’s due-diligence role and the annual reporting deadline.

Use this as a practical baseline:

• assign one owner for the full reporting cycle
• map country steps and local filing channels
• keep a decision log for open interpretation issues
• retain records so you can explain what was filed if a tax authority follows up

If you want a deeper dive, read DAC7 Deep Dive: What It Means That EU Tax Authorities Will Now See Your Platform's Seller Data.

Who is likely in scope and where legal uncertainty remains#

EU operators can be covered through tax residence, incorporation, management, or a permanent establishment in a Member State. Non-EU operators can also be covered when they facilitate relevant activities for EU reportable sellers or rental of EU immovable property. Confirm the responsible operator and any qualifying equivalent-reporting arrangement; non-EU incorporation alone is not an exemption.

Separate operator scope from seller reportability. A covered operator does not automatically report every user or every transaction: identify active sellers, the relevant activity, the EU residence or property link, and applicable seller exclusions.

A practical scope matrix#

For covered non-EU operators, the Commission describes registration in a single Member State and reporting there. Assess qualified non-Union arrangements that exchange equivalent information before deciding whether duplicate registration or reporting is required.

Where uncertainty usually sits#

Most uncertainty is factual, not theoretical:

• Which legal entity is the operator for reporting purposes
• Whether the product is facilitating monetized activity or only providing supporting software
• Whether an exemption position is available and supportable in each member state involved

Use DAC7-specific law and national guidance for scope decisions. VAT Cross-border Rulings and OSS govern different obligations and should not determine whether a seller or platform is reportable.

Keep a scope log with a jurisdiction column from day one, then narrow only after source-document review.

Seller exclusions require a separate check. Irish Revenue’s excluded-seller guidance covers government entities, listed entities and their related entities, qualifying high-volume property-rental entities, and qualifying low-volume goods sellers. The goods test applies only to sale of goods: fewer than 30 activities and total consideration not exceeding €2,000 in the reportable period. Both conditions must be met; it does not apply as a general exemption for services or rentals, and it is not a tax-free threshold.

What seller data to collect and when to verify it#

If a seller group may be in scope, collect and verify core seller data during onboarding, not at filing time. DAC7 is described as requiring platform operators to collect, verify, and report seller information, so late backfill usually creates avoidable reporting risk.

The reporting requirements come from DAC7 and its national implementation; an XML schema specifies how data is represented and validated. Confirm the filing authority’s schema and additional submission rules. For individuals, Irish Revenue’s DAC7 guidance lists place of birth in the absence of a TIN. That is an individual-seller field, not a replacement identifier for entities. The DAC7 seller data checker can help identify missing fields in your export; a schema pass does not establish legal reportability.

A minimum seller record#

For individuals, collect name, primary address, all issued TINs with each issuing jurisdiction, date of birth, and VAT number where available; place of birth is relevant where no TIN is available under DAC7. For entities, collect legal name, address, all issued TINs with each issuing jurisdiction, VAT number where available, business registration number, and relevant EU permanent establishments. Apply the applicable TIN-collection exceptions. Irish Revenue distinguishes these two seller types.

Do not stop at field capture. Track whether each key field is uncollected, collected pending review, verified, or accepted under an exception, and record why anything is missing.

Verify early while the seller is still reachable#

The first reportable period was 2023. Annual reporting is due by 31 January of the following year; for calendar-year 2026, plan for 31 January 2027. Collect and verify data early enough to resolve missing or conflicting records before the annual filing gate.

For each key identifier, keep the capture timestamp, collection method, and current verification state. If seller details change, re-check the record instead of leaving an old value marked complete.

Add a pre-filing gate before anything goes out#

Before filing, run a pre-filing review across all reportable sellers. Focus on:

The main failure mode is "collected but unverified." It can look complete in operations reporting but fail under scrutiny if you cannot show how data was verified. Keep an evidence trail from each reported field to capture event, verification state, and any approved exception reason. For a deeper reporting workflow, see EU DAC7 Reporting: What Every Marketplace Platform Must Do by January 31.

How reporting flows through EU exchange channels#

The operator reports to the competent national tax authority through the applicable registration and filing channel. Tax authorities then exchange information with the relevant Member States; the platform does not submit directly to every seller’s residence authority. Confirm the correct filing Member State and rules preventing duplicate reporting for your operator.

Keep registration, submission, acknowledgement, and correction responsibilities assigned to one internal owner. Confirm the authority’s file format, credentials, deadlines, and correction process before the reporting rehearsal.

Make ownership explicit at each handoff: Tax/Finance for submission and authority contact, Product/Engineering for fields and export logic, and Ops/Compliance for seller follow-up when new evidence is needed. If ownership is vague, defects stall between teams until deadline pressure returns.

Keep proof of filing, not just the file you intended to send. Retain the exact submitted version, submission timestamp, receipt or acknowledgement, and any rejection/acceptance messages from the filing authority.

Track defects by filing jurisdiction and feed repeat failures back into source-data and mapping controls before the next cycle.

Ownership and build-versus-buy decisions#

Decide ownership before technology: name one accountable owner for the filing relationship, submission calendar, and correction loop, then choose build, buy, or hybrid based on whether you can keep records complete, traceable, and easy to defend.

Start with ownership before technology#

You do not need every task in one team, but you do need one clear decision owner for DAC7 operations. Use that owner to set decision lines for incomplete records, disputed classification, and rejected submissions, while Product, Engineering, Finance/Ops, and Legal/Tax execute their parts.

Own the full DAC7 cycle: scope, seller due diligence, reporting, seller communication, corrections and record retention. Filing software can execute agreed steps, but it does not replace your operator’s classification decisions.

A practical checkpoint: the owner should be able to quickly produce the current reporting population, current scope rules, the submitted file version, and related authority acknowledgements or rejection messages.

Compare tooling on proof, not feature lists#

Use build, buy, or hybrid as operating models, not labels. The key question is where judgment and control sit, and whether your process stays reliable when submissions are questioned or corrected.

Hybrid is often the practical answer#

If capacity is limited, hybrid is often the most workable path: keep classification, reconciliations, and exception handling internally, and use an external engine for transformation or submission steps.

Confirm which national authority receives your report and which country requirements affect registration, submission or corrections. Keep approvals and the defect log accessible to your team even when a vendor handles the file.

The evidence pack that survives audits#

Your evidence pack needs to do one thing well: let an external reviewer trace any reported seller record back to its source data, checks, filed output, and later corrections. If that trail breaks, you are left defending process by narrative instead of evidence.

Retain the source and verification records supporting each filed seller row, the exact output submitted, and the authority response. Define retention against the applicable DAC7 rules and national implementation.

What the pack should contain#

Keep one evidence set per reporting cycle, organized so seller-level questions are easy to answer. At minimum, include:

The practical test is reproducibility: can you rebuild a reported row from source data using the logic version active at filing time?

Make jurisdiction differences explicit#

Keep national registration, file-format, submission and correction requirements visible in the evidence pack. Resolve local mechanics using DAC7 authority guidance rather than VAT ruling procedures.

Design for cross-border scrutiny#

If a national tax authority asks how a record was produced, answer with version history, approvals, and a reproducible extract. Avoid "fixed in the file" edits that bypass source records and approval trails; corrections should flow back to the underlying record and then into regenerated output.

A 90-day implementation sequence for first-cycle readiness#

Use this 90-day plan as an internal delivery cadence, not a legal DAC7 deadline. By day 90, the target is a defensible process, a tested seller dataset, and no unresolved issue that could change who is reportable or what is submitted.

For a step-by-step walkthrough, see EU DAC7 Directive for Freelancers Using Digital Platforms.

Conclusion#

Start from the actual DAC7 tests: covered operator, relevant activity, reportable seller and exclusions. Once the reporting population is established, assign owners to collection, verification, annual reporting and correction handling.

The right mental model is cross-functional. Even when the legal hook sits in a directive and local implementing law, the work lands across Product, Engineering, Finance or Ops, and Legal or Tax: scope decisions, data capture, verification evidence, reporting output, and correction handling. Your first checkpoint should be blunt and testable: can you reproduce one record end to end from source data to report output, and point to the identifier or address trail that supports it? If not, you are not ready, no matter how polished the policy note looks.

Keep jurisdiction-specific registration and submission requirements in the operating runbook. Use the national DAC7 authority’s guidance and preserve a dated decision record for unresolved classification questions.

A working cycle should reproduce a seller row from onboarding and payment records to filed output. Confirm seller exclusions, annual deadlines and national enforcement rules, preserve acknowledgements, and escalate unresolved classification questions before the filing decision.