DAC7 makes platform operators responsible for reporting seller data when the platform facilitates rental of immovable property, personal services, sale of goods, or rental of transport for consideration. In practice, platforms need defensible scope decisions, complete seller identity and quarterly consideration data, clear exception handling, and country-by-country confirmation of local filing mechanics for both EU and potentially in-scope non-EU operators.
Treat DAC7 as an operating model problem, not a definitions exercise. If your platform handles income from reportable activities, you need to make defensible scope decisions, collect the right data, and keep evidence that can stand up to questions from national tax authorities.
| Milestone | Date | Article detail |
|---|---|---|
| Member State implementing laws | 31 December 2022 | Member States were required to adopt and publish implementing laws |
| Directive entered into force | 1 January 2023 | Council Directive (EU) 2021/514 entered into force under the Directive on Administrative Cooperation framework |
| First exchange for calendar year 2023 | end of February 2024 | The first exchange of information for calendar year 2023 took place |
At EU level, the legal base is settled. DAC7 is Council Directive (EU) 2021/514 under the Directive on Administrative Cooperation framework, and it entered into force on 1 January 2023. The first exchange of information for calendar year 2023 took place at the end of February 2024, so this is already a live reporting obligation.
For platform teams, the risk is cross-functional. Compliance needs defensible interpretations. Legal needs to separate EU-level requirements from local procedure. Finance needs payout and reconciliation data tied to reportable activity. Risk needs controls for missing records, weak classification, and potential breaches under Member State sanction regimes. One point is explicit in DAC7: the reporting obligation sits with platform operators.
That distinction, what is settled at EU level and what still needs local confirmation, should shape your controls.
This is where execution usually breaks down. Member States were required to adopt and publish implementing laws by 31 December 2022, but domestic application still needs country-by-country validation. EUR-Lex tracks national transposition measures and makes clear that Commission verification of completeness and correctness still matters.
In practice, validate each reporting position against both Council Directive (EU) 2021/514 and the relevant local transposition or tax authority guidance. If a national authority gives a date or procedure, treat it as local execution detail, not an EU-wide rule.
This article focuses on the operational side of that reality: scope decisions, control ownership, exception handling, and an evidence checklist you can use as an audit file. The goal is not just to understand DAC7. It is to run a process you can defend.
Under DAC7, seller tax reporting sits with the platform operator. Council Directive (EU) 2021/514, within the Directive on Administrative Cooperation framework, places the reporting obligation on platform operators and frames them as better placed to collect and verify seller information.
That legal ownership has operational consequences. If your platform can identify the seller, see the activity, and reconcile related revenue, those are the records DAC7 reporting relies on. The same logic also reaches certain non-Union Platform Operators, which may still need to register and report in one EU country.
In practice, interpretation and execution can split apart. A scope memo does not help much if seller data capture is incomplete or if revenue and payout records cannot be tied back to the seller account that generated them. The obligation starts in law, but readiness depends on complete seller, activity, and transaction data.
Use one practical checkpoint for each in-scope seller journey. Confirm a traceable chain from source records to reportable output:
If you cannot show that chain, your reporting position may be hard to defend.
You might also find this useful: Creator Platform Tax Reporting for 1099 and W-8 Expansion Decisions.
Decide scope with two separate tests: entity nexus and activity type. If a non-EU entity facilitates in-scope activity in the Union, treat it as potentially reportable until local counsel confirms otherwise.
Legal domicile alone is not enough. Under Council Directive (EU) 2021/514, first classify the operator's nexus, then test whether the platform facilitates a relevant activity.
| Scope case | Establishment or nexus test | Activity test | What to do |
|---|---|---|---|
| Union platform operator | Resident for tax purposes in an EU country, or incorporated, managed, or having a permanent establishment in an EU country | Check whether the platform facilitates relevant activities | Treat as potentially reportable unless you can support an exclusion position |
| Non-Union platform operator | Outside those EU nexus tests, but performing commercial activity in the Union | Check whether it facilitates a relevant activity by reportable sellers | Treat as potentially reportable, and confirm registration and reporting position in one EU country |
| Any operator with no relevant activity | EU or non-EU status does not by itself create reportable activity | No facilitation of rental of immovable property, personal services, sale of goods, or rental of any mode of transport | Do not assume reporting applies; document why activity is outside the four DAC7 categories |
Union platform operators include entities resident for tax purposes in an EU country, and entities incorporated, managed, or having a permanent establishment in an EU country. Non-Union platform operators sit outside that nexus, but can still be in scope when they perform commercial activity in the Union.
Once you place the operator in an entity bucket, run the activity test on its own facts. The four relevant activities are rental of immovable property, personal services, sale of goods, and rental of any mode of transport. The reporting obligation covers both cross-border and non-cross-border activity, so domestic-only flows are not automatically out of scope.
A common failure is marking an entity "non-EU, therefore out," while the platform is facilitating in-scope seller activity in the Union. Keep entity scope and activity scope in separate fields in your decision log: one field for nexus, one for relevant activity.
For foreign operators, treat the Italian tax authority guidance as a warning sign, not a universal shortcut. It states that a non-Union reporting operator without nexus to a Qualified Non-Union jurisdiction may need to register in a Member State to obtain an individual identification number. It also states that non-Union operators are in scope when they facilitate relevant activity by reportable sellers. Use that to trigger early escalation, not as a blanket conclusion for every model.
Every scope decision needs evidence, not just an outcome. Record at least:
32021L0514, ELI dir/2021/514/ojTreat scope as a living classification. Re-check it annually and whenever markets, products, or seller models change.
If you want a deeper dive, read Digital Platform Reporting: What Every Online Marketplace Must Report to Tax Authorities Worldwide.
Classify scope at the product flow level, not the company label. For DAC7, the practical question is whether the platform facilitates one of four reportable activities, and whether any claimed exclusion applies.
Start with one simple test: does the platform connect sellers with customers for a relevant activity for consideration? If yes, map the flow to one of the four DAC7 activity families below. Do this for domestic and cross-border flows alike.
| Activity family | What you are classifying | Exclusion pattern, requires legal sign-off | What to verify before coding |
|---|---|---|---|
| Rental of immovable property | Platform-facilitated paid rental of immovable property | Listing or advertising only software | Whether the product only displays listings, or also supports the seller-customer transaction flow |
| Provision of personal services | Platform-facilitated paid services performed by a person | Redirect or transfer only software | Whether the product enables the service transaction, not just traffic routing |
| Sale of goods | Platform-facilitated paid sale of goods | Payment-processing only software | Whether the product only processes payment, or also facilitates the underlying sale |
| Rental of any mode of transport | Platform-facilitated paid transport rental | Solely listing-only, redirect-only, or payment-only layers | Whether the rental is facilitated on-platform rather than only advertised or paid through a narrow utility layer |
Treat exclusions narrowly. "Solely" payment processing, "solely" listing or advertising, and "solely" redirect or transfer can be excluded from the platform concept in DAC7-related guidance. That is not a product call you should make on your own. Require legal sign-off and store the reasoning.
One red flag is worth making hard in your process. If a launch blends marketplace and payment functions, force reclassification before go-live. That blend does not, by itself, decide scope, but a historic "out of scope" label should not survive feature changes without a fresh review.
For each product or seller flow, keep the checkpoint hard to skip: chosen activity family, confirmation that activity is for consideration, any exclusion position, and the legal or compliance approver. That matters downstream because reporting platform operators submit seller information to their Member State tax authority and are expected to run due-diligence checks on data accuracy.
A failure mode can start at onboarding. If you miscoded the activity type, for example goods versus personal services, or a facilitated flow versus payments only, that error can flow into due diligence, data mapping, and reporting files sent to national tax authorities. Late fixes can be costly because you may need to unwind classification logic, seller populations, and supporting evidence.
Once scope is settled, the next question is the data model. Under DAC7, in-scope platform flows require reporting seller identity data and consideration-related activity data, not just proof that an account exists. The report is filed with the tax authority in the Member State of single registration, and that information is then shared with relevant EU Member State authorities.
Use a simple split in your data model: identity fields and income or activity fields. The current materials support a clear minimum, but they do not provide one exhaustive pan-EU field dictionary in a single excerpt. Keep the schema configurable rather than hard-coded.
| Data area | Examples supported in current guidance | Why it matters operationally |
|---|---|---|
| Individual seller identity | First and last name, primary address, all TINs, each Member State of issuance | Needed to identify the seller correctly across jurisdictions |
| Entity seller identity | Legal name, primary address, TINs, VAT ID where available, business registration number | Prevents entity records from being reduced to contact-level data only |
| Income and activity data | Total consideration paid or credited during each quarter, plus fees, commissions, or taxes withheld or charged | Gives tax authorities an economic reporting picture, not just seller enrollment |
Before each reporting run, apply a quality gate in your own control framework. If a record is missing identity data or quarter-level consideration data needed for reporting, route it to exception handling with an owner, reason, and remediation date instead of letting it pass silently. Silent omission can create gaps in the reported seller population that are difficult to reconcile later.
Because the full field-level picture is not visible in these excerpts, keep evidence tied to the data model. Where your compliance process needs provenance, retain versioned mapping notes, correction logs, and the source references used in your interpretation.
Need the full breakdown? Read How to Issue Compliant Tax Invoices in 50+ Countries as a Global Platform.
Before you wire up API filing, assign owners and prove your controls on a small, reviewable population. DAC7 puts the reporting obligation on platform operators and expects due diligence on collection and accuracy, so automation should come after scope, completeness, and correction handling are working.
DAC7 does not prescribe your org chart, but it does make the operator accountable. A workable minimum split is below.
| Control area | Suggested owner | What that owner must decide or check | Evidence to retain |
|---|---|---|---|
| Legal interpretation | Legal or tax counsel | Whether the entity is a Reporting Platform Operator or, for a non-EU group entity, a Non-Union Platform Operator that may need to register in one single EU country | Written scope memo citing Council Directive (EU) 2021/514 and any country implementation notes |
| Product and data mapping | Product, data, or engineering with compliance input | Which product flows map to relevant activity categories and which fields are captured at onboarding, payout, and correction stages | Versioned field mapping, activity classification notes, change log |
| Reporting operations | Finance or tax operations | Whether reported totals reconcile, whether required records are complete, and whether the filing pack is ready by the local deadline | Reconciliation file, exception list, filing approval record |
| Oversight and challenge | Risk, compliance, or internal control | Whether exceptions are aging, whether control checks found repeat failures, and whether periodic revalidation happened | Control test results, issue register, remediation tracker |
If your structure is small, one person can hold more than one role. What matters is clear accountability and retained records for each decision.
Use this sequence to avoid unnecessary rework:
| Step | Action | Key detail |
|---|---|---|
| 1 | Classify entity scope | Identify which group entity operates the platform and whether it is in the reporting population; for non-EU operators, confirm whether single-country EU registration is required |
| 2 | Classify activity scope | Map product flows to rental of immovable property, personal services, sale of goods, or rental of any mode of transport |
| 3 | Map required fields | Bind seller identity and other reportable data to the reporting model only after scope is clear |
| 4 | Validate record completeness | Route missing seller or reportable records into tracked exceptions with an owner and remediation date |
| 5 | Run pre-submission checks | Reconcile totals, review outliers, and confirm the report population matches the in-scope population |
| 6 | File and retain evidence | Keep submission records, correction logs, and supporting documentation for the required retention window |
For many teams, especially non-EU platform operators, a manual phase can be a safer starting point: legal scope attestation, operations sign-off on the reporting population, and targeted QA before automated submission. This is a control choice, not a DAC7 legal requirement.
Keep jurisdiction differences explicit while you do this. The Commission states DAC7 entered into force on 1 January 2023. Dutch guidance states collect, verify, and report obligations as of 1 January 2024. If your group includes a non-EU operator, this is where human review stops wrong assumptions from being hard-coded. If that is your situation, this related guide may help: DAC7 for Non-EU Platforms: Does Your Marketplace Owe Tax Data to European Authorities?
Use filing cadence as an operational checkpoint. Ireland states returns are due by 31 January for the prior calendar year, with exchange by 28 February 2025 for the 2024 period. If exceptions are still unresolved in January, API speed will not fix data quality.
When you evaluate tooling, compare it on defendability:
These are not statutory architecture requirements, but they line up with authority expectations on collection, verification, accuracy, corrections, and retained evidence. Design for retention from day one. Finnish guidance states records must be stored for at least six years after the end of the reportable period.
Related: GDPR for Marketplace Platforms: How to Handle Contractor and Seller Personal Data Compliantly.
Before you automate filings, map your control owners to concrete system behaviors (policy gates, status handling, and audit trails) in one implementation checklist: Review the docs.
Once owners are in place, make onboarding decisions based on relevant activity carried out for consideration and profile completeness, not account creation alone. Classify a seller for reporting when they start, or are enabled to start, in-scope activity and you have the data needed to support that decision.
Your onboarding gate should stop in-scope status from going live without both a mapped activity type and the required identity and tax fields. Under DAC7 implementation, Reporting Platform Operators are expected to run due diligence and report accurately, and national guidance makes clear that required data can include fields like address and tax identification number.
| Seller state | Action | Rule |
|---|---|---|
| Only creating an account | Do not set a final DAC7 classification | Unless intended activity is already known |
| Enabled for reportable activity | Require completion of the identity and tax profile before full activation or payout | Your onboarding gate should stop in-scope status from going live without both a mapped activity type and the required identity and tax fields |
| Required data is missing or the seller does not cooperate | Route the case to exception handling | Published guidance states this can lead to removal or withholding of outstanding consideration |
Use a simple rule set:
This avoids the common failure mode where transactions and payouts start before classification data is complete.
Classification should change when seller behavior changes. If a seller moves from excluded or non-reportable behavior into an in-scope activity category, trigger reclassification and record the effective date.
Keep that review concrete: check the activity code used and the seller terms in force at that time. For edge cases, route decisions through a defined internal approval path before changing production labels, and retain the approval record, supporting facts, and effective date.
Monitoring should track where exposure actually shifts: seller residence, activity mix, and unresolved classification exceptions. At minimum, run an annual checkpoint in January, when prior-year data summaries surface errors. If your platform changes quickly, run more frequent internal checks.
Prioritize three questions:
Keep the evidence tight: submitted seller profile, classification rationale, reclassification date, and an exception log showing owner, status, and aging.
Do not respond to missing seller data by collecting everything. Use a narrower rule: collect only the fields you can map to a documented DAC7 reporting purpose under Council Directive (EU) 2021/514 and the relevant Member State implementation layer.
That boundary matters because both obligations apply at once. DAC7 is part of EU tax-authority information exchange and expects platform operators to collect and verify seller information. GDPR requires data to be collected for specific purposes and limited to what is necessary. A collect-now, justify-later approach can become a control failure, not a safe fallback.
A field register is the practical control here. Require one before schema or workflow changes. For each seller-data element in reporting, record:
Apply GDPR by-default controls to amount, processing extent, storage period, and accessibility. In practice, that supports restricting default access to seller tax data and using a bounded retention schedule instead of open-ended storage.
Because Member State transposition is a distinct implementation layer, treat schema updates as a joint privacy and tax decision. Have privacy counsel test purpose limitation and minimisation. Have tax compliance confirm reporting need by jurisdiction. Keep that approval record with the field register.
For a step-by-step walkthrough, see What Is DAC7? EU Platform Reporting Directive Explained.
Use a formal exception queue for items that are still unresolved at reporting time. That keeps decisions explicit and auditable instead of letting them disappear into silence.
Keep categories practical and distinct. A workable internal set, based on the controls evidenced here, is:
Treat these as internal control categories, not legal labels. If you need DAC7-specific categories, define and validate them separately, because this evidence set does not establish a DAC7 exception taxonomy.
| Trigger | Primary owner | Decision output |
|---|---|---|
| Unclear scheme scope or return inclusion | Named compliance owner | Documented inclusion or exclusion decision, or further fact-finding |
| Missing records or invoice evidence for in-scope items | Named operations owner | Evidence remediation plan and reporting treatment |
| Repeated control failures against scheme obligations | Named escalation owner | Control-failure decision, remediation plan, and escalation path |
This keeps interpretation, reporting operations, and control-risk issues from being mixed into one workflow.
If deadlines are close and data quality is still unresolved, escalate to a named approver for a documented decision instead of quietly excluding the record. Record whether the issue affects the OSS return, other VAT reporting, or internal reconciliation only.
At minimum, record:
If you already run OSS processes, reuse the discipline around record-keeping and audit readiness, but keep this decision log separate so obligations do not blur together.
Related reading: Real-Time Reporting Metrics Platform Finance Teams Can Actually Control.
A workable DAC7 process can use one annual calendar with one accountable owner. That helps keep timing, versions, and correction handling auditable across legal, compliance, and finance.
Keep one line per in-scope jurisdiction, or reporting channel, and track the same stages: period close, pre-submission review, submission, correction handling, and post-filing review. Do not import VAT One Stop Shop dates into this DAC7 calendar. The European Commission material in this pack is explicit on OSS mechanics and cadence, but it does not establish DAC7 deadlines.
| Calendar stage | Anchor | Gate before moving | Evidence to retain |
|---|---|---|---|
| Period close | Internal year-end reporting cut-off by jurisdiction | Seller activity extract complete, exceptions tagged, scope decisions locked | Locked extract reference, exception register snapshot, scope approval log |
| Pre-submission review | Jurisdiction filing date confirmed for that jurisdiction | Completeness review passed, unresolved items have documented approver decisions, draft output reconciles to source totals | Review checklist, reconciliation file, approver sign-off |
| Submission | Actual filing event by jurisdiction | Final file version approved, submission channel details recorded | Final version ID or hash, submission receipt, confirmation record |
| Correction handling | Late seller updates, reconciliation findings, or authority feedback | Change, rationale, approver, and resubmission decision documented | Correction memo, before and after comparison, decision log, resubmission evidence |
| Post-filing review | Annual retrospective window after submission | Submitted totals reconcile to retained records, open issues assigned | Post-filing reconciliation, control-failure log, remediation tracker |
For each in-scope jurisdiction, record the local confirmation source, named internal owner, submission route, and correction path, not just a due date.
Treat the evidence pack as the file you would use to explain how reporting decisions were made. At minimum, include:
Keep version history explicit. A dated trail of what changed, who approved it, and which seller population was affected is stronger than a generic reference to the latest file.
Run three checks every year:
Known from European Commission materials in this pack
- The cited Commission material is about VAT One Stop Shop, not DAC7 reporting mechanics.
- OSS material explicitly covers registration, declaration and payment, record keeping and audits, and scheme exit or exclusion.
- OSS return cadence is quarterly for Union and non-Union schemes and monthly for the import scheme.
Unknown without jurisdiction-specific confirmation
- DAC7 filing deadlines and submission windows
- DAC7 correction deadlines or correction channels
- Field-level seller data requirements
- Country-by-country differences across EU Member States
- Whether any OSS-style routing or evidence expectations apply by analogy
Assign one accountable owner for calendar integrity. Legal, compliance, and finance can each contribute, but one owner should maintain the master calendar, ensure local date confirmations are attached per jurisdiction, and confirm the evidence pack is complete before submission.
This pairs well with our guide on How to Handle Currency Gain and Loss Reporting for a Multi-Currency Platform.
Focus this month on four controls: scope, evidence, data readiness, and country confirmation. The goal is to defend your DAC7 decisions before the next filing cycle, not to automate uncertain logic.
Run one workshop across legal, compliance, product, and finance, and force a yes or no answer per entity on two questions: are you a platform operator, and do you facilitate a relevant activity? At EU level, relevant activities are rental of immovable property, personal services, sale of goods, and rental of any mode of transport.
Do not treat geography as the only scope test. Non-Union platform operators can still be in scope and may need to register and report in one EU country if they perform commercial activity in the Union. For each conclusion, record the entity, activity, decision owner, and source. If local interpretation is still open, mark it provisional and assign a recheck date.
Create one lean internal evidence pack now so decisions survive regulator or audit review. Keep it consistent:
This matters because DAC7 places reporting obligations on platform operators, and due-diligence procedures are expected to confirm information accuracy.
Validate whether your current data can produce the annual return required in your reporting jurisdiction before you add automation. Test real seller records, including messy cases, and confirm you can identify reportable sellers, map activity type correctly, and explain inclusions, exclusions, and reclassifications.
If your team cannot explain difficult records manually, automation will only scale errors. Fix onboarding and monitoring gaps first, especially where classifications may need to be revisited.
Treat implementation as country-specific. Ireland states filing by 31 January for the previous calendar year and notes exchange by end of February. Italy cites national implementing acts including a Revenue Agency provision dated 20 November 2023. A Dutch seller-facing page states reporting applies from 1 January 2024.
Build a country list for each country where you have sellers or reportable activity, record the local authority page or adviser used, and note where specialist advice changed your interpretation. Do not copy one country's exclusions, dates, or process into another without documenting why.
If your team needs a jurisdiction-by-jurisdiction readiness check before the next reporting window, talk to Gruv to validate rollout assumptions and operating controls.
DAC7 requires Reporting Platform Operators to file an annual return on reportable sellers that carried out relevant activities on the platform in the previous year. In the guidance cited here, that includes seller identity data plus quarterly totals for consideration paid or credited and quarterly fees, commissions, or taxes withheld or charged. The same guidance says the reported information should also be provided to the seller by 31 January of the filing year.
Yes, they can. Non-Union Platform Operators can be required to register and report in one EU country, and cited Member State guidance says a non-EU operator may choose a Member State to register and file for DAC7. If the platform facilitates a relevant activity by a reportable seller in a Member State, treat the operator as potentially in scope until local advice confirms the position.
Current guidance groups reportable activities into four categories: rental of immovable property, personal services, sale of goods, and rental of any mode of transport. Platforms should map onboarding and transaction logic to those categories before finalizing reporting. If a launch blends models, run a classification review before go-live.
Exclusions need local verification rather than a one-size-fits-all EU rule. The material here notes local guidance that can exclude an operator with no reportable sellers and can exclude certain sellers, such as goods sellers with less than 30 transactions and €2,000 total or sellers that rent the same immovable property listing more than 2,000 times during the reportable period. A common misclassification is applying one country's exclusions across all Member States without checking local implementation.
Use a both-and approach: collect what DAC7 reporting requires and keep the processing GDPR-compliant. Document the reporting purpose for each field, restrict access, and apply bounded retention. The article also recommends a field register and joint privacy and tax review for schema changes.
Use the full timeline. The directive is dated 22 March 2021, Member States had to adopt and publish implementing laws by 31 December 2022, the Commission describes it as entering into force on 1 January 2023, and the first exchange for 2023 information took place at the end of February 2024. For operations, build controls around the current filing year and each Member State's implementation instead of relying on one copied date.
Asha writes about tax residency, double-taxation basics, and compliance checklists for globally mobile freelancers, with a focus on decision trees and risk mitigation.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Educational content only. Not legal, tax, or financial advice.
The hard part is not calculating a commission. It is proving you can pay the right person, in the right state, over the right rail, and explain every exception at month-end. If you cannot do that cleanly, your launch is not ready, even if the demo makes it look simple.
Step 1: **Treat cross-border e-invoicing as a data operations problem, not a PDF problem.**
Cross-border platform payments still need control-focused training because the operating environment is messy. The Financial Stability Board continues to point to the same core cross-border problems: cost, speed, access, and transparency. Enhancing cross-border payments became a G20 priority in 2020. G20 leaders endorsed targets in 2021 across wholesale, retail, and remittances, but BIS has said the end-2027 timeline is unlikely to be met. Build your team's training for that reality, not for a near-term steady state.