If you are responsible for performing the Country-by-Country Reporting for your group or as a tax advisor for your clients, you probably know that compiling your CbCR documentation can be quite a challenge. What many people don’t know is that the technical part of creating a CbCR XML file is very hard too. Just to understand what steps are necessary to create a CbCR filing we describe the process to have an insight into the burden of manual steps to create a CbCR filing.
The manual steps to create a CbCR filing
- Gather the data for the group.
- Structure the data in Excel by splitting it into the famous CbCR Table one and Table two.
- Performing risk analysis on the data and providing Table three comments.
- Creating the XML.
- Creating different versions of the XML for different countries.
- Sending the XML to the tax authorities.
Below is a more in-depth description of the steps described above.
1. Gather the data for the group
In an ideal world, the data required to comply with CbCR would reside in a tax-sensitized, group-wide ERP or consolidation system. In reality, such a system is still likely to be an aspiration for most Multinational Enterprises (MNE). The process and struggles of collecting the required data is another topic for a much broader article. Let’s assume a MNE completed the first step and collected all necessary data for each company within the group.
2. Structure the data in Excel by splitting it into the famous CbCR Table one and Table two
The process of gathering group-wide information for financial reporting purposes has generally resided in the finance function; that data has been collected for a different purpose with different requirements as to the materiality, definitions, and granularity. For CbCR, it is necessary to go beyond locally consolidated data to entity-level information, as OECD guidance indicates that the data should be reported on an aggregated (rather than consolidated) country basis. Therefore it creates an additional challenge. Assuming we managed to allocate the data needed for Table 1 and Table 2 correctly and we move on to the next step.
3. Performing risk analysis on the data and providing Table three comments
On top of the challenges discussed in the first 2 steps comes the challenge which can be summarized as “how do I analyze it?”. This analysis has to be performed on groups level, country level and entity level. Then a decision has to be made on what to do with the results of this analysis, and how these risk factors have to be mitigated by communicating and commenting in Table 3. We have completed this task as well. Here we are at the point that all data seems to be collected and have to be submitted to Tax authorities in the relevant country or most probably several countries. What is next?
4. Creating the XML
Creating XML is a task only reserved for tech-savvy people. Look at the CbCR XML snippet below and be honest: you do not want to spend your days writing code like this!
CbCR XML snippet
Luckily there are tools to create XML files such as Altova XML spy or alternative XML editors. However, those tools need explicit instructions on how to convert data. They cannot simply convert an Excel to the appropriate XML format.
5. Creating different versions of the XML for different countries
The OECD has released guidance. What many people don’t know is that all OECD member countries have interpreted these guidelines their own way with slight deviations from the OECD guidelines. For example, when filing in Italy you will need to add all Table 3 comments in both Italian and English. In the United Kingdom, it is mandatory to add a CbCID in your message to the HMRC. And in Taiwan, an additional 12 fields need to be filled in containing BAN information.
The documentation of different countries provided on their own CbCR implementation varies in quality as well. For example, documentation can be only in the local language (such as Taiwan or Austria). Or the documentation is of such poor quality it is very difficult to understand. Reverse engineering CbCR XML examples are often necessary to understand the documentation.
Many different countries have many different exceptions on the standardised guidelines, which makes it very difficult to comply.
6. Sending the XML to the tax authorities
Another burden is that each country has its own way of sending the CbCR file to the tax authorities. They made it very easy in some countries such as in Sweden and the United Kingdom, with easy-to-use CbCR portals and very good quality checking of the data.
But for example in Malaysia, the file needs to be manually encrypted with a tool and different encryption keys using OpenSSL. In Hong Kong first, a test filing must be provided to the IRD.
Many tax authorities have a validation service in place. This is very good. For example Sweden and the UK have a great test service. When testing the file in the Netherlands the input for the validation service can only be uploaded in ISO 8859-1. Whereas files can be uploaded in a more extensive character set in the production environment. You are never able to know if your file is valid with test services deviating from a production service!
Conclusion
Luckily there are tools available to take the burden off your shoulders creating CbCR XML. We can see the manual steps to create a CbCR above. TPGenie automates most of the above tasks. For example, we have integrated a workflow engine which allows you to gather all CbCR data from your local entities.
Additionally, we processed all documentation and implemented the countries’ exceptions into the tool, so you don’t have to bother with generating the complex XML structure.
And we have done this successfully! In the last three years, hundreds of successful CbCR filings in dozens of countries have been done using TPGenie. Do you want to see it in action?
Recent Comments