The sixth amendment to EU Directive 2011/16/EU on administrative cooperation in the field of taxation, DAC7, is a directive that standardizes reporting requirements for all digital platform operators across the EU. It is designed to both support tax transparency and prevent tax evasion and avoidance by people who sell via platforms such as Airbnb, Amazon, Booking.com, and Uber. As the Dec. 31 deadline for implementing the directive looms, digital platform operators should be in the process of putting their seller due diligence procedures and controls in place.
Many global platforms are already coming up against numerous challenges that they either had not anticipated or were not fully prepared for; DAC7 adds to this burden. With only weeks to go, there are still significant concerns from a business perspective about how to comply with the new rules.
It is helpful to focus on the logistical and practical, day-to-day implications of DAC7 as the deadline approaches. We will discuss the key areas affected by DAC7; including data collection, updating existing data, data validation, the lack of standardization, fetching sensitive data, and the types of technical challenges platform operators will face.
While there are several data points that need to be collected for DAC7, we will focus on tax numbers. In general, there are three categories of tax identification:
- An income tax number like a personal tax number for individuals (such as the US social security number or Dutch BSN) or a corporate tax number for companies;
- A business registration number (typically registered with a chamber of commerce); and
- An indirect tax number (value-added tax/goods and services tax number).
Many countries—for example the US—generally have no overlap between such tax numbers. However, there are many exceptions globally where one number may serve multiple purposes.
In order to comply with the DAC7 requirements, platform operators need to know which types of tax ID to collect. The directive does not list the exact tax ID names that are relevant for each country, so companies will have to perform independent research to identify the different tax number types necessary to collect for each jurisdiction. This issue is complicated by the fact that DAC7 is geared towards income taxes, and companies are now being tasked with collecting income tax numbers (rather than VAT/GST numbers, which they may be already collecting).
For other types of data such as address, the directive does not prescribe the format for how to record the data collected. Should the addresses be saved in a single string or in separate rows—for example, do you split the postcode from the main address? We know from existing data-sharing obligations across the world that the formats in each country are often different.
According to DAC7, platform operators have to determine whether the information collected from sellers is reliable and accurate. There are several challenges, many of which were discussed during a recent Bloomberg Tax panel. We outline three major issues below.
- A lack of reliable sources for tax number validation
Validating EU VAT numbers is relatively simple, thanks to the VIES system and access to local databases of the majority of the EU member countries. But most countries do not have a publicly available database to validate corporate or personal tax IDs. The eventual launch of a Government Verification Service (an electronic process available to platform operators for ascertaining the identity and tax residence of a seller) will simplify this process. It cannot come too soon.
- Incomplete or out-of-date information on publicly available sites
It is possible to build checkers (such as format and algorithmic checks based on Organization for Economic Co-operation and Development and European Commission information) into the customer onboarding process. But the European Commission information is naturally limited to EU member states, and the OECD sources are not fully up to date. Even those measures do not fully validate IDs. In short, while collecting tax ID data can be relatively simple, validating the data is not. Further, tax ID formats are not static. For example, Argentina changed its format in July 2022 in order to make its IDs generic and non-binary. In the Netherlands, an individual’s VAT number was previously (almost) the same as their personal tax number (BSN), but the country decoupled the two in 2020. Platforms would do well to educate themselves on each country’s specific ID quirks.
- Real-time validations are difficult to execute
For platforms that validate IDs in real-time (when customers input their tax ID on a checkout page), there are significant hurdles. Even if there is a government database with which to validate a tax ID automatically, this can sometimes cause a lengthy wait for the customer. Ideally, it will take significantly less than three seconds and certainly not more than six, as this seems to be the limit of our human patience. If a user has to wait too long, there is an increased chance of a lost sale. However, some databases can take significantly longer to return the necessary information. Two practical ways to limit losing customers in this process (“churn”) include making the request earlier in the onboarding funnel to give the tool time to validate the ID, or adopting a risk policy that temporarily accepts an ID that uses the correct format and syntax, but only fully verifies the number after onboarding is completed.
Updating Existing Data
Platforms will have to begin collecting and validating the required data not only from new sellers, but also from existing sellers that have already been onboarded. To collect the former, engineers will be tasked with building an additional field to collect tax IDs from anyone who onboards. But the latter brings a greater challenge, especially for older and more mature platforms—collecting tax ID data from the existing user base. And time is not on their side.
Why does it take a significant amount of time to collect data from existing users? Platforms are asking sellers for sensitive personal information, which many are reluctant to provide in the first place. Campaigns must be launched—over email, phone, or in-app—to collect this data, though special care should be taken to tailor the messaging to sellers in the language they prefer. From my experience working on these kinds of issues in-house, initial response rates can be as low as 15%, though they vary from country to country. Therefore, follow-up campaigns need to be pre-arranged and agreed. My estimation is that it will take a minimum of two months to see any sort of significant positive result.
Figuring out the most ideal time to update existing tax data from customers is not simple. One of the benefits of the gig economy initially was its ability to get people signed up and selling quickly. Platforms asking customers to provide this type of information up-front increases friction and may cause churn in the funnel, though statistics vary. Some businesses may insist that platform sellers provide their tax ID after onboarding but before payment is made out to them. Asking for that information at that stage most certainly increases the rate of compliance but, for some countries, it is worth speaking with the legal team before withholding a seller’s money.
Moreover, there are also platforms that may have “sight” of the transaction but are not always involved in the payment process itself.
Lack of Standardization
At the moment, it is not known how DAC7 will replace all existing data-sharing rules. The hope is that the type of data platforms need to collect will be standardized, but data-sharing rules introduced under regulatory (non-tax) or indirect tax legislation may remain even after local DAC7 rules are enacted, which will result in duplication of reporting. Platforms should prepare to be able to explain discrepancies between data sets.
Despite the goal of creating standardized reporting requirements, there will be regional differences in requirements and processes. Understanding the nuances in each country is key to compliance. At the time of writing, the format of the data that platforms are to collect is unknown. Because of this, companies must be diligent in keeping up to date with relevant global legislation, and be prepared to develop a strategy quickly and efficiently between engineering, project managers, designers, and communications teams, once official guidance is handed down.
Handling Bank Accounts and Other Sensitive Data
Financial account data such as bank accounts will need to be shared under DAC7, which brings with it privacy challenges. Any security breach that includes information such as date of birth and bank account numbers can also result in steep penalties in addition to reputational damage. Fetching such sensitive personally identifiable information data usually requires internal approval from the privacy team. As DAC7 requires sharing this data with multiple governments, such procedures must be considered when planning the next data-sharing submissions. The company’s data privacy officer must be kept up to date on all the changes brought about by DAC7.
Technical Challenges in Compiling the Data Sharing File
Aside from the obvious challenge of finding support to integrate with tax authority databases, there are other challenges. For example, compiling the data sharing file is a technical task which will likely need specialists in the field of data (such as data analysts, data scientists, or data engineers), as most tax professionals do not have the necessary knowledge. Relevant data points are typically scattered around different databases in the company, and overlapping data sources may need to be reconciled. The platform seller data will need to be pre-processed and transformed to a specified file format (i.e. XML or JSON) before it can be shared with the tax authority, as well as validated using in-house or third-party services. Whatever the exact submission requirements will be across the EU, fulfilling them may necessitate the help of those outside the tax team.
According to DAC7, data also needs to be shared with platform sellers before it is submitted to governments, bringing many challenges experienced by platforms with 1099 reporting in the US. Platform operators will need to design and localize—adapt the layout and languages of—tax summaries for platform sellers about whom they are sharing data.
Platforms located outside Europe may be operating under the assumption that DAC7 will apply only to EU businesses, but that does not appear to hold water. In fact, foreign companies with activities in Europe now likely have data subject to these requirements. Platforms now have an obligation to collect tax data and share it with the appropriate authorities.
It is abundantly clear that governments are not willing to excuse platform operators or platform sellers from tax reporting obligations.
- To comply with DAC7 requirements, platform operators need to know which types of tax ID to collect and should perform independent research to identify the different tax number types necessary to collect for each country—which may also include data from outside of the EU.
- Platforms must be prepared to quickly and efficiently develop a strategy between engineering, project managers, designers and the communications team, once official guidance is handed down with regard to data standardization.
- Communication campaigns must be launched to gather critical tax data from existing platform sellers, though care should be taken to tailor all communications, such as using their preferred language and referring to the correct tax ID name.
- Limit lost sales from new platform sellers when validating tax IDs by making the request earlier in the funnel to give the tool time to validate the ID or adopt a risk policy that temporarily accepts an ID that uses the correct format and syntax.
- Work closely with the company’s data privacy officer and make sure they are kept up to date on all the changes brought by DAC7.
- Data submitted to governments also needs to be shared with platform sellers, and operators will need to design and localize tax summaries for sellers about whom they are sharing data.
This article does not necessarily reflect the opinion of Bloomberg Industry Group, Inc., the publisher of Bloomberg Law and Bloomberg Tax, or its owners.
Alexander Kobakhidze is tax technology director at Fonoa, and is a tax technology specialist with in-depth knowledge of indirect taxes impacting the platform and online economy. He was previously the global head of tax technology at Uber, where he supported (and continues to support) the work of the OECD Working Parties on Consumption Taxes and on the Exchange of Information and Tax Compliance, the two groups which developed the data-sharing rules on which DAC7 is based.
The author may be contacted at: email@example.com