Yes. A non-EU marketplace can owe DAC7 reporting when it facilitates in-scope activity with an EU connection, even without an EU legal entity. The practical path is to confirm scope, determine the single Member State registration and filing route for a Non-Union Platform Operator, classify reportable sellers, and verify required fields before reporting. Keep dated evidence for each decision and escalate unclear country-level interpretation early so filings remain defensible.
Treat DAC7 first as a reporting and data-control problem, not a tax-rate problem. Council Directive (EU) 2021/514 was adopted on 22 March 2021 and entered into force on 1 January 2023. It amended the Directive on Administrative Cooperation so tax authorities can receive and exchange platform seller data across the EU. We recommend starting there so your team does not treat DAC7 like a tax-calculation project and miss the reporting controls that actually fail first.
That framing matters for non-EU operators. DAC7 does not create a new tax. It creates an obligation to provide information. EU Member State tax authorities automatically exchange data from platform reports, and the first exchange for calendar year 2023 took place at the end of February 2024. In practice, for non-Union operators that report in one Member State, that data is then exchanged across Member State authorities. We see teams get into trouble when they under-resource the reporting owner because they assume the obligation stops at the filing state.
A decision-list format fits here because the execution risk is mostly about sequence. You need to confirm whether your activity is in scope, where you may need to register, which sellers are reportable, what data you must collect and verify, and when to escalate unclear points for legal advice.
DAC7 is the 2021 amendment to the Directive on Administrative Cooperation, the EU framework for secure administrative cooperation between national tax authorities. In operational terms, the regime expects platform operators to collect, verify, and report seller information, so ownership cannot sit in one silo.
The reporting obligation can extend to platform operators that may not meet core EU nexus criteria but perform commercial activity in the Union. Non-Union Platform Operators are required to register and report in one single EU country. If you facilitate rental of immovable property, personal services, sale of goods, or rental of any mode of transport, treat scope as a live question until you can rule it out.
The policy logic is that platform operators are best placed to collect and verify seller information. Build minimum controls for data collection, verification, exception handling, and filing ownership before you choose automation. As one concrete timing anchor, Ireland's DAC7 guidance requires filing by 31 January for the previous calendar year, so late classification or verification creates predictable year-end remediation pressure.
Use the sections that follow in order. Each decision narrows the next. Where Member State interpretation is unclear, document the open point, retain evidence for your decision path, and escalate early. Related reading: GST Digital Marketplace Platform Comparison for Australia, Canada, and India.
Use this list to sequence decisions, not to replace legal advice. The goal is to choose the lightest control set that still meets DAC7 reporting obligations, produces evidence you can defend, and avoids rework later. We recommend keeping that sequence visible in your project plan so legal interpretation does not drift away from system design.
This section is for compliance, legal, finance, and marketplace ops owners at non-EU platform operators. DAC7 puts reporting responsibility on the platform operator, so your team needs to connect legal interpretation, seller data, and filing output. We would rather see one named owner coordinate that chain than let each function assume another team is carrying the reporting risk.
Start with scope, including both cross-border and domestic activity, then registration and reporting jurisdiction, then reportable sellers, then Annex V due diligence and reporting controls. Early scope mistakes can cascade into bad data collection and late-stage remediation.
Lean does not mean informal. For each reported seller field, you should be able to show the source, verification step, exception handling, and accountable owner.
This list does not replace specialist advice on Member State registration tests, exemptions, equivalence relief, or penalties. If your footprint changes, seller geography expands, or authority interpretations conflict, pause design decisions and escalate before locking your AEOI reporting model.
Related: DAC7 Deep Dive: What It Means That EU Tax Authorities Will Now See Your Platform's Seller Data.
Start with a fast triage: yes, no, or escalate. If even one material flow matches a listed DAC7 activity and has an EU connection, treat your platform as likely in scope until legal review narrows it. That is the practical default because DAC7 is a tax-transparency reporting regime, not a new standalone EU tax.
A bad scope call early creates rework later in seller classification, onboarding fields, verification, and reporting ownership. The rules apply from 1 January 2023, so delay can increase cleanup risk for active platforms, including non-EU operators that may still be in scope.
Screen for all four listed activities: sale of goods, personal services, rental of immovable property, and rental of any mode of transport. Do not rely on internal labels alone. Reconcile product or listing types, onboarding categories, and payout or booking data so the same flow is classified consistently.
DAC7 reporting covers cross-border and non-cross-border activity. A fully domestic EU segment can still matter. If you facilitate EU-linked seller activity or EU-linked immovable-property rental, move into likely-scope handling. Non-EU operators can still be in scope when they perform commercial activity in the Union.
Capture a dated scope note, the activity-mapping logic, and supporting artifacts such as listing types, terms, and seller-geo outputs. Mark the result clearly: likely in scope, likely out of scope, or legal review required. This record supports later registration and reporting design, including one-country EU registration and reporting paths for Non-Union Platform Operators where applicable.
A common failure mode is treating the whole platform as one homogeneous model. Mixed marketplaces can combine goods, services, property, or transport flows, and some are easy to miss. If one material flow is in scope with EU nexus, proceed as likely in scope and design data controls while counsel resolves edge cases.
You might also find this useful: A Guide to the EU's DAC7 Directive for Digital Platforms.
Resolve registration logic before you build systems. For a non-EU platform facilitating reportable EU-linked activity, DAC7 generally means one EU registration and filing country. Your reported data can still be shared with multiple Member States through Automatic Exchange of Information, or AEOI.
| Touchpoint | What the article says | Practical note |
|---|---|---|
| Single EU filing country | Non-Union Platform Operators are required to register and report in one single EU country when they perform commercial activity in the Union | Treat registration as one filing point, not one-country exposure |
| Seller residence Member State | Under AEOI, tax authorities automatically exchange reported data with the Member State where the reportable seller is resident | Separate the filing country from recipient countries |
| Property-location Member State | For immovable-property rentals, the property-location Member State is also relevant | Include property location in the country matrix |
| Irish public guidance example | States a 30 November 2023 registration deadline, gives a 5 May 2024 to 30 June 2024 timing example, and says an operator that elects another Member State must inform Revenue in writing | Keep a dated matrix of trigger facts, notifications, owner, and unresolved counsel questions |
| Conflicting public timing example | Dutch public pages describe obligations as of 1 January 2023 on one page and as of 1 January 2024 on another | Do not hard-code dates when official public pages conflict |
| Enforcement risk note | Continued non-compliance after two reminders from the Member State of registration can lead to permanent registration revocation | Route unclear country or timing issues to counsel before buildout |
Non-Union Platform Operators are required to register and report in one single EU country when they perform commercial activity in the Union. Public authority guidance also says a non-EU platform operator may choose a Member State to register and file in, but if it meets conditions in more than one Member State, it must elect one. Treat this as one filing point, not one-country exposure. If your footprint spans many Member States, do legal triage before you customize onboarding, filing workflows, or internal approvals.
Filing in one Member State does not keep the data there. Under AEOI, tax authorities automatically exchange reported data with the Member State where the reportable seller is resident. For immovable-property rentals, the property-location Member State is also relevant. Build a country matrix with seller residence, activity type, filing authority, expected recipient authority, and legal-status notes. This prevents late rework when one filing election still creates multi-country visibility.
Public guidance is useful, but it is not a complete answer for every fact pattern. Irish guidance, for example, states a 30 November 2023 registration deadline for operators meeting Irish conditions, gives a 5 May 2024 to 30 June 2024 timing example, and says an operator that elects another Member State must inform Revenue in writing. Keep a dated matrix that records trigger facts, chosen or candidate registration state, required notifications, internal owner, and unresolved counsel questions.
Do not hard-code dates when official public pages conflict. The Commission states DAC7 entered into force on 1 January 2023. Dutch public pages describe obligations as of 1 January 2023 on one page and as of 1 January 2024 on another. Enforcement risk also needs early handling. The Commission summary says continued non-compliance after two reminders from the Member State of registration can lead to permanent registration revocation. If facts are unclear, hold country-specific automation and route edge cases to counsel first.
The practical move is simple: settle registration logic before automation, keep a defensible country matrix, maintain a named counsel queue, and separate the filing country from the countries that will receive the data.
Need the full breakdown? Read Canada Non-Resident Tax for Freelancers Working With Canadian Clients.
Define your seller-classification policy before you collect more data. For non-EU platforms in scope, the job is to classify each seller as reportable, excluded, or legal-review, then apply that logic consistently across goods and personal services.
| Seller pattern | Article treatment | Control note |
|---|---|---|
| EU-resident seller on a non-EU platform | A practical warning that non-EU operators with EU-resident sellers may face EU reporting exposure | Use activity type plus EU link, not internal labels |
| Entity listed on a stock exchange | Public guidance lists it as an excluded seller | Require evidence for each excluded record |
| Goods seller with less than 30 transactions and a total amount of €2,000 in the reportable period | Public guidance lists it as an excluded seller | Apply both threshold conditions together and keep a seller-level record of transaction count, total amount, activity type, and rule version |
| Seller that rents the same immovable property listing through the platform more than 2,000 times during the reportable period | Public guidance lists it as an excluded seller | Require evidence for each excluded record |
| Seller changes from sole trader to company | Trigger reclassification review instead of editing the old profile in place | Make seller type a controlled field, not free text |
DAC7 puts the reporting obligation on platform operators, and public guidance says it does not create a new tax for sellers. Your policy should determine reporting status, not broader taxability.
Classify the seller first by DAC7-relevant activity: sale of goods, personal services, rental of immovable property, or rental of any mode of transport, then test the EU connection. A UK government manual notes that some UK platform operators with EU-resident sellers have been obliged to report to an EU Member State, which is a practical warning that non-EU operators with EU-resident sellers may face EU reporting exposure. Do not let internal labels like "creator," "merchant," or "contractor" decide the outcome. Use activity type plus EU link.
Build exclusion rules directly into the policy and require evidence for each excluded record. Public guidance lists excluded sellers including entities listed on a stock exchange, goods sellers with less than 30 transactions and a total amount of €2,000 in the reportable period, and sellers that rent the same immovable property listing through the platform more than 2,000 times during the reportable period. Treat thresholds as rule tests, not judgment calls. For goods sellers, apply both threshold conditions together and keep a seller-level record of transaction count, total amount, activity type, and rule version.
DAC7 reporting fields differ for individual and entity sellers. The Directive distinguishes first and last name for an individual seller and legal name for an entity seller, so one combined path will either miss required fields or collect the wrong data. Make seller type a controlled field, not free text. If a seller changes from sole trader to company, trigger a reclassification review instead of editing the old profile in place.
Cross-border patterns can create inconsistency, so route unclear cases through a defined legal-review path. A non-EU seller selling into the EU and an EU-resident seller on a non-EU platform are different fact patterns and should not be resolved ad hoc by operations. Maintain a mandatory escalation bucket for mixed accounts, seller-type changes, and sellers active across both goods and services, and require legal approval for policy v1 and material updates.
This pairs well with our guide on HMRC Reporting Rules for Platforms for UK Marketplace Operators.
Keep the data standard narrow and documented, then verify early. That is the most practical way to meet DAC7 due diligence expectations without turning intake into over-collection.
DAC7 requires Reporting Platform Operators to run due diligence procedures to identify reportable sellers and collect their data. Public guidance is clear that this is an information-reporting regime, not a new tax. Your intake design should produce records that are complete enough to report and still remediable before 31 December of each reporting period.
| Seller/activity type | Minimum data to collect | Verification checkpoint that matters |
|---|---|---|
| Individual seller | First and last name, primary address, all TINs issued to the seller; if no TIN, place of birth | Confirm core identity and tax fields are complete; if no TIN, require place of birth instead of leaving the record incomplete |
| Entity seller | Core entity identity and tax identifiers, plus VAT identification number where available and business registration number | Confirm entity versus individual classification before finalizing the record |
| Property rental seller | Seller data above, plus for each property: type, address, identification of the property, number of days rented | Confirm each property record is complete and tied to the correct listing |
Use the fields DAC7 guidance points to for report content. For individuals: name, primary address, TINs, and place of birth if no TIN is available. For entities: include VAT identification number where available and business registration number. For property rentals: include property type, address, identification details, and number of days rented. Tie mandatory fields to reporting content and documented control needs, not to nice-to-have data.
Verification order is what prevents year-end cleanup. If a seller is likely reportable, verify required fields before payout eligibility or equivalent operational progression instead of relying on remediation later.
This is an internal control choice, not a uniform EU-wide payout-hold rule stated in the cited sources. But it fits the requirement to obtain and verify seller information and to complete due diligence by 31 December of each reporting period.
Some records will fail verification on the first pass. Route those cases into a controlled exception queue with reason code, owner, timestamp, and supporting evidence for each decision. Every exception should resolve to verified, blocked pending remediation, or legal review.
Member States must maintain procedures that ensure compliance with DAC7 due diligence, so your process should preserve what was requested, what was provided, what was missing, and who approved the outcome.
DAC7 sources support due diligence, annual reporting, and seller notification obligations. They do not by themselves mandate a specific storage design such as masked fields or role-based access architecture. Implement those controls as internal design choices, and label them that way.
One required step is seller disclosure: platform operators must inform sellers what data was transmitted to tax authorities. Keep records complete enough to support that communication, especially because EU tax authorities automatically exchange reported information with the seller's Member State of residence.
If you need one operating rule, use this: collect the minimum DAC7 fields at onboarding, verify before the account becomes hard to pause, and route unresolved cases through tracked exceptions before 31 December.
If no one owns DAC7 end to end, do not start with software. Start with accountability, because the legal reporting duty sits with the platform operator under Council Directive (EU) 2021/514.
| Ownership lane | Focus | Checkpoint or evidence |
|---|---|---|
| Interpretation and registration | Scope, reportable-seller interpretation, and registration path | Signed country position memo or decision log |
| Data controls and due diligence | Seller-information controls that feed reporting | Pre-filing completeness check against the reporting schema, plus retained evidence for overrides or remediation |
| Report assembly, reconciliation, and sign-off | Turn verified records into a filing-ready package | Final extract, reconciliation to seller and payments data, approval record, and submission acknowledgement |
| Seller notice and post-filing correction | Seller communications and corrections after filing | Correction log with the original record, corrected record, reason, approval, and seller notice copy |
This follows directly from Decision 4. Once you know what seller data must be collected and verified, the next risk is handoff failure. You need clear ownership for scope, data quality, report assembly, sign-off, and corrections.
Assign one accountable owner for scope, reportable-seller interpretation, and registration path. For a Non-Union Platform Operator, that owner must determine which single EU country is used for registration and reporting. This lane absorbs Member State differences, since national transposition and penalties are set locally, not in one uniform EU template. Set a concrete checkpoint before tooling: a signed country position memo or decision log.
Assign one owner for the seller-information controls that feed reporting. DAC7 expects platform operators to collect and verify seller data, and national guidance describes due diligence plus declaration to tax authorities. That owner should define completeness, blocking rules, and exception handling, not just data stewardship. If your process includes review of tax-relevant fields, define reviewer and evidence standards now. A practical control is a pre-filing completeness check against the reporting schema, plus retained evidence for overrides or remediation.
Assign one accountable owner for turning verified records into a filing-ready package, with finance and compliance consulted. This step must be defensible before exchange, since EU tax authorities automatically exchange reported information. The Directive ties that exchange to a window within two months after the Reportable Period. For calendar year 2023 data, the first exchange occurred at the end of February 2024. The standard here is defensible reporting, not just a technically valid export. Keep an evidence pack with the final extract, reconciliation to seller and payments data, approval record, and submission acknowledgement.
Name one owner for seller communications and corrections after filing. Platform operators must inform sellers which data was passed to tax authorities. This lane continues after submission, including disputes, amendments, and resubmissions. Maintain a correction log with the original record, corrected record, reason, approval, and seller notice copy.
You do not need a complex RACI to begin. You do need one named owner for each lane, one backup, and one documented handoff point. Without that, tooling just helps you produce ambiguity faster.
If you want a deeper dive, read Digital Platform Reporting: What Every Online Marketplace Must Report to Tax Authorities Worldwide.
Build the evidence pack now, not after your first challenged filing. If you cannot trace a seller from intake to classification to verification to the submitted file, your process may run, but it will be hard to defend.
DAC7 puts the reporting obligation on platform operators, and the reported data is exchanged through AEOI across EU tax authorities. Weak records can therefore become a multi-jurisdiction issue, not just a local documentation gap.
Start by preserving decision records and every approved policy version that affected filing. For a non-Union platform operator, that includes scope decisions, chosen registration country, reportable-seller policy, and seller-data or verification standards tied to your process.
Keep more than the current policy. Keep the version in force at decision time, approver identity, and what changed. Because Member State implementation differences can exist, log country-specific interpretations that changed seller treatment or filing position.
Use a simple test: for any material policy, your team should be able to show which version applied, who approved it, and which filing population it affected.
Your strongest evidence is the record of how each seller decision was made, not just the final filing export. Reporting Platform Operator guidance emphasizes keeping records of due diligence procedures and the evidence relied on.
Retain both the outcome and the basis for it. A status flag without evidence is weak, and documents without a decision log are weak.
At minimum, keep these linked at seller level, and make sure they can be traced into the filing population:
| Evidence item | What it proves | What to retain |
|---|---|---|
| Seller classification log | Why a seller was treated as reportable, non-reportable, or pending review | Seller ID, decision date, rule applied, reviewer, approval reference |
| Verification outcome | That required checks were completed or failed | Check performed, result, date, evidence relied upon, remediation note |
| Exception and override history | Why normal rules were bypassed | Original status, override reason, approver, supporting document, expiry or follow-up date |
| Change history | Why a seller moved between statuses | Prior value, new value, trigger, date, owner |
| Filing inclusion flag | Traceability into the submitted report | Filing period, included yes/no, submission batch reference |
Tie policy records and seller-level decisions to the exact DAC7 submission. Under AEOI, you should be able to show the submitted file was complete, reviewed, and consistent with underlying records.
Treat reconciliation as core evidence, not as a separate finance task. Keep the filing extract, reconciliation records, approval record, and submission acknowledgement together, with one retention owner.
Timing supports this discipline. DAC7 entered into force on 1 January 2023. The first exchange for calendar year 2023 took place at the end of February 2024. The Directive also references communication within two months after the reportable period. Adviser material also noted a first EU deadline of 31 January 2024, with extensions in some Member States. The practical point is the same: do not leave evidence assembly to post-deadline cleanup.
Keep the pack lean enough to maintain and strong enough to defend. Overbuilt evidence requirements get bypassed under deadline pressure, but narrative-only files can fail due-diligence scrutiny.
Assign recurring ownership and version control, not just year-end assembly. Strong packs are built throughout the year through records, policy updates, and periodic review.
Use one operating rule: every material DAC7 decision should leave a dated record, a named owner, and a document trail another reviewer can follow without oral context.
If your evidence pack is still fragmented, map your control points to concrete workflow states and exports first, then use Gruv docs to align implementation details.
Set written escalation triggers before operations change. Your team can handle routine, documented decisions, but changes in scope, registration posture, filing setup, or record-keeping should move to legal and tax counsel early.
This only works if you escalate with evidence. Use the policy history, seller logs, and submission records from your evidence pack so counsel reviews facts, not assumptions.
If you add a new activity line, enter additional EU markets, or change how transactions are facilitated, escalate before launch. The key question is whether the new fact pattern changes classification, filing population, or VAT reporting treatment.
If you use OSS, treat registration and scheme design as legal and tax decisions, not ops preferences. OSS participation is optional, but if you opt in, registration is in one single Member State, the Member State of identification, and all supplies under that scheme must be declared via the OSS return. Also confirm how OSS returns, which are additional and do not replace the regular VAT return, fit your existing filing model.
As seller activity spreads across Member States, interpretation risk can rise. Use a hard trigger for geography drift or country-specific caveats in internal memos, and send a country matrix plus representative edge cases for review.
Escalate on events that affect defensibility: record, invoice, or bad-debt documentation gaps; deregistration planning; exclusion notices; or cadence changes tied to scheme type, quarterly for non-Union or Union, monthly for import. Late escalation here can turn into recovery work. Keep the trigger list short, named, and owned so the line between internal decisions and specialist interpretation stays clear.
For a step-by-step walkthrough, see Creator Platform Tax Reporting for 1099 and W-8 Expansion Decisions.
Once your escalation triggers are in place, choose the smallest architecture that still produces a defensible record. For most teams, that means avoiding a full build on day one and focusing on traceable decisions for reportable sellers, controlled exports, and clear evidence.
Start manual when scope is still moving, seller volume is manageable, or counsel is still testing edge cases. Keep it controlled: one owned seller-classification register, one verification log, and one approval step before any export is created.
Before approval, reconcile the export population to the seller register, exception log, and current policy version. If a seller was added or excluded outside that chain, stop and resolve it before submission.
The main failure mode is version drift: the policy changes, the filters do not, and the file no longer matches the approved population. If you cannot show policy version, approver, and source records, the process is already too light.
Use a hybrid design when you need stronger control without overbuilding. Keep interpretation, approvals, and exceptions under human review, then automate only the parts your stack already supports well, such as data capture, status tracking, and controlled exports.
If you already run EU VAT operations through OSS, reuse the operating pattern, not the legal logic. OSS is structured around registration, declaration and payment, record keeping and audits, and leaving the scheme. That lifecycle is a useful template for status-driven operations.
"Member State of identification" is a practical modeling example: in OSS, it is the single Member State where an OSS user registers for a chosen scheme. Do not assume DAC7 uses the same registration logic, but do use the design lesson that one authoritative registration-status object is safer than scattered country flags.
Also keep calendars separate unless counsel confirms overlap. OSS VAT return cadence differs by scheme: quarterly for non-Union and Union, monthly for import. OSS VAT returns are additional and do not replace regular VAT returns. Do not infer DAC7 filing cadence from OSS alone.
Build in-house when legal interpretation is stable and exception handling volume is the main cost. At that point, you need more than forms and exports: store field provenance, decision history, approval timestamps, and post-filing correction states.
Do not use VAT status as a proxy for DAC7 reporting status. EU VAT e-commerce rules can treat some platforms as deemed suppliers and impose record-keeping requirements, but those concepts do not determine DAC7 reportability on their own.
For many teams, the lightest viable end state is structured data, manual approvals, and targeted automation. If you can show who changed seller status, when it was verified, and which export version was approved, the architecture is probably at the right weight.
Choose the lightest path that still gives you a defensible DAC7 record for your current perimeter. DAC7 places reporting responsibility on the platform operator and expects seller information to be collected and verified. Judge each path on whether it can support annual filing, seller-copy delivery where required by your registration jurisdiction, for example by 31 January in Ireland, and later review by your Member State of registration.
This is a current-state control decision, not a future-state one. DAC7 has applied since 1 January 2023, and the first exchange for 2023 data took place at the end of February 2024. Non-Union Platform Operators register and report in one single EU country. Reporting can still cover both cross-border and non-cross-border activity, so change tolerance matters as much as filing speed.
| Scenario | Usually viable starting path | Owner count | Exception volume | Audit-trail strength | Reporting repeatability | Dependency on external counsel |
|---|---|---|---|---|---|---|
| Marketplaces for goods | No DAC7-mandated path; use the option that keeps collection, verification, and reporting controls reliable | No DAC7 owner-count cutoff stated in the cited sources | No DAC7 exception-volume cutoff stated in the cited sources | Strong register-to-export reconciliation and approval evidence | Repeatable annual filing and seller-copy process where required | Member State interpretation can affect implementation details |
| Platforms for personal services | No DAC7-mandated path; select based on control reliability and change handling | No DAC7 owner-count cutoff stated in the cited sources | No DAC7 exception-volume cutoff stated in the cited sources | Strong decision history and exception handling | Repeatable annual filing and seller-copy process where required | Member State interpretation can affect implementation details |
| Rental of immovable property | No DAC7-mandated path; select based on control reliability and change handling | No DAC7 owner-count cutoff stated in the cited sources | No DAC7 exception-volume cutoff stated in the cited sources | Strong property- and seller-level evidence with approval controls | Repeatable annual filing and seller-copy process where required | Member State interpretation can affect implementation details |
Manual-first can be practical when your controls are still evolving. It gives you flexibility to change classification and jurisdiction handling without rebuilding logic.
Run it with hard gates: one owned seller-classification register, one verification log, and one approval step before export or online submission. Also verify that the seller population used for filing matches the population used to produce each seller copy by the applicable deadline, for example 31 January in Ireland. If they diverge, stop and resolve before filing.
Hybrid can help when manual handling starts creating control strain. Keep interpretation and approvals under human ownership, and automate repeatable operations such as status tracking, data capture, exception queues, and controlled exports.
A hybrid approach can align with filing channels in some jurisdictions. For example, Ireland Revenue supports online form, XML, and API submission, which creates a practical ladder from manual submission to controlled exports and then API-based flows.
Use automation-first only when legal interpretation is stable, your policy is settled, and your registration-state filing channel is clear. Its advantage is repeatability at scale, not better legal judgment.
Be cautious if your activity mix spans sale of goods, personal services, and rental of immovable property, and if you operate across domestic and cross-border cases. If legal assumptions are still changing, hard-coded logic can fail broadly.
Automation does not reduce regulatory exposure by itself. Member States can apply administrative and penal sanctions for breaches, and continued non-compliance after two reminders from the Member State of registration can lead to permanent revocation of registration. If you cannot evidence field provenance, approvals, and post-filing corrections, use a phased control approach before a full automation build.
Because the cited sources do not set owner-count or exception-volume cutoffs, decide path changes based on whether your controls can still collect and verify seller data, support filing, and meet seller-copy obligations in your registration jurisdiction.
We covered this in detail in When Marketplace Platforms Still Face Sales Tax Nexus Obligations.
The practical win is not collecting every possible seller field. It is making DAC7 decisions in the right order and documenting what is settled versus what still needs Member State legal confirmation. We recommend keeping your unresolved points explicit so your filing team is not left guessing at deadline time.
Start with scope, then reporting perimeter, then seller rules, then controls, then ownership, then escalation. DAC7 places the reporting obligation on platform operators, covers both cross-border and non-cross-border activity, and applies to defined activities: rental of immovable property, personal services, sale of goods, and rental of any mode of transport. If scope and activity classification are not written and approved, do not lock tooling yet.
At EU level, reporting is annual, the filing deadline is stated as 31 January of the following year, and Non-Union Platform Operators can be required to register and report in one single EU country. DAC7 entered into force on 1 January 2023, and Member States had to adopt and publish implementing measures by 31 December 2022. Use these as baseline build-now requirements, and keep a country-by-country legal question log for issues public summaries do not resolve.
Before deadline pressure builds, name owners for legal interpretation, seller-data collection and verification, report assembly, approval, and post-filing corrections. Keep an evidence pack you can produce on demand: current policy, classification logs, verification outcomes, open legal questions by Member State, approvals, and change history. Reconcile those records to the population you expect to file by the stated 31 January deadline.
Run this decision list against your current model now, document unresolved questions by Member State, and assign an owner and due date for each item before the next reporting cycle. We would rather see your team escalate one unresolved DAC7 point early than discover at filing time that a registration or seller-classification decision was never owned. Once legal interpretation is settled, run a practical architecture check for your reporting flow and escalation model with Gruv.
No. DAC7 is a reporting and tax-transparency regime under Council Directive (EU) 2021/514, not a new tax. The core risk is compliance with reporting and data obligations, not a separate DAC7 tax charge.
The reporting obligation sits with the platform operator. Public guidance states platforms are expected to collect, verify, and report seller information because they are better placed to do so. Sellers still matter operationally, but the legal reporting duty is framed at operator level.
Potentially, yes. A platform may still be in scope even if it is not tax resident, incorporated, managed, or permanently established in a Member State, if it facilitates relevant activity tied to Member States. In that scenario, Non-Union Platform Operator registration in one Member State may be required to obtain an identification number.
The core activity categories are rental of immovable property, personal services, sale of goods, and rental of any mode of transport. Scope is not limited to cross-border cases. DAC7 reporting can also apply to non-cross-border activity. If your platform facilitates one of these categories, domestic-only activity does not automatically place you out of scope.
At minimum, operators must collect, verify, and report data on reportable sellers. Public guidance describes this as an annual reporting cycle for certain platform operators from 1 January 2023. Keep your reporting population and records consistent, since Member State tax authorities automatically exchange reported information.
Member State application details can still require legal confirmation. Official guidance notes it is not complete and may not provide a definitive answer in every case. Escalate questions on registration tests, exemptions, local filing mechanics, and edge-case classifications to counsel.
Based in Berlin, Maria helps non-EU freelancers navigate the complexities of the European market. She's an expert on VAT, EU-specific invoicing requirements, and business registration across different EU countries.
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.
Digital platform reporting is an operating control, not a year-end cleanup task. For online marketplaces, seller and income data should be collected and verified as part of normal operations, not reconstructed later. If you run a marketplace, you need this data model working before filing season, not after it.
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.
Spend 10 focused minutes with this guide and you should leave with three concrete things: a quick triage of where DAC7 questions may sit, a record routine you can actually maintain, and a clear point where advisor input is worth the time and cost. The goal is execution, not legal theory.