A blueprint for Tax Data Sharing obligations like DAC7
Inhouse tax teams facing a growing list of data sharing obligations need an easy way to explain the key steps to stakeholders (legal, product, etc) to ensure compliance with the rules.
To do this, it helps to have a mental model that describes the process and what it actually takes to “share data.”
Below, we have shared ours, which we have been repeatedly told was “very helpful”.
Using this breakdown will allow you to better understand (and explain) your obligations. It is also helpful for identifying areas for focus and attention.
In this article, we focus on regulations based on the OECD’s Model Rules for Reporting by Digital Platform Operators (MRDP) like the EU’s DAC7, the UK’s Digital Platform Reporting Rules, Australia’s SERR and others. We call these “Data Sharing” regulations colloquially.
This article assumes you have some foundational knowledge of the subject. However, if you are new to this topic or need a reminder, we suggest starting with this DAC7 article and complementing it with this key DAC7 insights webinar (there are a couple more reading suggestions at the end of the webinar).
What is tax data sharing?
Tax Data Sharing is not simply the submission of data to the authorities. It is a series of seven steps: Scoping, Collection, Validation, Aggregation, Notification, Submission, and Inquiries.
1. Scoping
The first step is to understand whether your platform is within the scope of the Data Sharing Obligations, and in which countries. If so, which of your activities are covered?
However, at a high level, if you have sellers (or support the rental of properties) located in a country with data-sharing obligations, you are likely in the scope of that country’s rules.
Of course, the exact rules are more nuanced, and legislation and guidance are being rolled out. Many companies have decided to confirm their understanding with their trusted external advisor.
The real problem for most platforms is not deciding if they are in scope, but what to do about it.
Tax data-sharing rules are now also being rolled out in the UK, Australia, New Zealand, and Canada. Most countries are basing their rules on the OECD’s Model Rules for Reporting by Platform Operators with respect to Sellers in the Sharing and Gig Economy.
No Minimum Threshold
Data Sharing regulations, like the EU’s DAC7 or the UK’s Digital Platform Reporting Rules don’t have a minimum threshold for the size of the platform. Meaning that platforms that match criteria are in scope of the regulation from day 1 of their operations. Think future Ubers, Airbnbs, Amazons that are just starting out, all have to share their seller’s information with tax authorities, no matter how small the company’s revenue or headcount is.
2. Data Collection
Collecting the data is the next step in the process. Many platforms have updated their seller onboarding processes to account for the additional data fields (like Date of Birth for individuals in the EU). Much of this required work with product and communications (e.g. support) teams.
This cross-functional coordination was essential to:
- Ensure processes introduced into the onboarding funnel for new sellers were clean and minimise churn.
- Communications teams were able to reach out to existing sellers who had missing profile data, contacting them in the appropriate timelines and explaining what additional information they needed to provide and why.
This practically meant that teams that don’t usually work together had to sit at the same table for the first time. Tax teams had to make their case to ask for engineering resources to build the scripts necessary for generating compliant XML files.
Another common concern was related to “enforcement” - what to do if a platform seller fails (or refuses) to provide the necessary mandatory information, eg., a valid tax ID. There are several approaches on the market, but according to regulation, platforms are required to ban sellers to register and are not allowed to remit any payments.
When it comes to tax ID’s some platforms were able to use our tool, Fonoa Lookup, to find missing names, addresses business registration numbers and other information from sellers.
Legislative Motives
The purpose of these requirements was specifically to leverage the power of digital platforms, for getting their sellers appropriately registered at tax authorities so that they can declare their income earned trough these platforms.
3. Data Validation
Some of the collected data must be validated prior to sharing. An example is the taxpayer IDs (company and individual) which should be validated against available government sources.
What’s a TIN?
Data Sharing rules require platforms to collect all sorts of tax IDs (or functional equivalents) from their sellers, depending on their legal and/or tax registration status eg., VAT IDs, tax IDs of natural persons or functional equivalents like national insurance numbers, personal numbers, personal income tax IDs. These often overlap as individuals can decide to become sole traders and then register for VAT, in which case an individual’s tax ID can become a VAT ID at the same time.
In the EU, that doesn’t just mean running VAT IDs against VIES because VIES doesn’t confirm local tax numbers like Germany’s steuernummer. Moreover, many sellers might not be registered for EU trade but only for domestic transactions - this means VIES will not validate a valid VAT ID potentially 60% of the time (read and learn more about VIES's limitations and how you can overcome them).
Many countries have databases against which you can validate. And according to official guidance,a simple format check is not enough, government databases must be utilised (where available). Solutions like Fonoa Lookup enable you to check tax ID’s in over 110 countries including UK, Australia, New Zealand, Canada, and the EU.
4. Data Aggregation
Two types of data are required for submission: seller identification data (taxpayer ID, address, bank account, etc.) and summarised transaction data (revenues generated, number of transactions, etc.).
Immovable Property Data
When renting out immovable properties a few more data points are required with regard to the rental unit. Nights rented (per property), revenue generated (per property) and the address of (each) property.
You must connect the revenues to the seller who generated them. For reporting, you may also have to split the data into prescribed periods (e.g. calendar quarters for DAC7).
Companies looking for external help with data sharing obligations were concerned with the protection of this sensitive data and how it is handled by third parties.
We addressed this concern by creating an on-premises solution for our enterprise clients, who could meet tight deadlines without having any data leave their native systems.
5. Seller Notification
The most forgotten-about step in the data-sharing process is informing the sellers about the information being shared about them.
Under DAC7 obligations, prior to submission, platforms are required to notify sellers of what is being submitted. The intention was to allow sellers an opportunity to review their data and leave enough time for corrections.
However, the challenge here is that the seller notification had to be generated well before the January 31st deadline, which many companies struggled to meet. Moreover, poorly designed notifications with language translation issues can cause confusion among sellers, leading to business friction and customer support nightmares. To avoid these issues, Fonoa Data Sharing offers bi or tri-lingual summaries in English and the local language(s) making sure that all sellers can understand the information that is being shared.
What does a Seller Notification look like?
Most regulations don’t define a specific format or look. Just the content, which should match what is being reported to the tax authorities. Therefore Seller Notifications come in many shapes and sizes. The information can be showcased within the Seller’s user profile, however in that case there is no “evidence” that the obligation was fulfilled. The market’s best practice is creating an actual document that is shared with the seller (e.g, a PDF is made available for download).
Again, data privacy and security were top concerns. Emailing notifications containing dates of birth, bank accounts, revenues, tax IDs, and social security numbers was a no-go. So we automate this notification generation process via PDFs to make it easier for businesses handling large volumes of sellers.
6. Data Submission
Only after completing the prior steps are we ready for submission. Submission is sending the data to the authorities in the required format through the right channel. Often the submission is carried out either through a dedicated government portal or via an API connection.
This is the “easy part”.
However, please remember that your organization (platform) must be registered with the authorities to submit data. Registering and obtaining the necessary credentials can take time, so please do not leave that to the last moment! And don’t forget to ensure that submission size limitations are met by splitting the data into required limits, per country, and per immovable property location, also special business rules must be adhered to and in some cases certain special characters are to be removed as well (we do this for you as well).
7. Inquiries
Finally, after submission, there may be inquiries. This refers to answering questions from your sellers and the tax authorities about the data submitted.
It is key to respond to such questions promptly and accurately with the correct data at your fingertips. Several companies are going through this step regarding the data submitted under DAC7 in 2024.
Therefore, be aware of the data you submit and prepare answers to some frequently asked questions.
A common question is asking platforms that withhold commission fees to explain the difference between the “seller revenue” and “the amounts a sellers receive in their bank account”. The difference, of course, is often just the commission withheld.
A list of responses to common questions helps customer success teams close support tickets faster and maintain your platform's reputation.
How can Fonoa Help
Our specialists have worked in-house at platforms affected by data-sharing obligations in the rideshare and accommodation space since as early as 2015. Their experience, combined with the knowledge of the world's largest and best-known platforms and marketplaces, has enabled us to design and deliver a world-class submission tool trusted by industry leaders.
If you would like to know more about Fonoa’s Data Sharing tool, contact us for more information or book a demo.
