Tax & Accounting Blog

Part 3: Additional Data Elements Now Needed to Generate CbC Reports in the OECD XML Schema

BEPS, Blog, ONESOURCE July 14, 2016

On March 22, 2016, the OECD published its standardized electronic format for the exchange of Country-by-Country (“CbC”) Reports between Competent Authorities, including the CbC extensible markup language (“XML”) schema and related User Guide. Both documents were developed to assist the speedy and consistent implementation of CbC Reporting with a view to accommodating the electronic preparation, filing and exchange of CbC Reports.

The complexities of producing CbC reports in the OECD XML schema is not one to be taken lightly. This, coupled with the other complexities of BEPS compliance, should further discourage MNEs from self-preparation of CbC reports. ONESOURCE can help.

This is Part 3 of a series on CbC Reports and what you need to know. See Part 1 and Part 2.

There now appears to be a need to capture several additional data elements to populate some mandatory and optional fields to generate the CbC reports in the OECD XML schema. These fields are in addition to the data fields that werespecified in the OECD templates (i.e. table 1, 2 and 3). These fields include entity identification numbers (TIN, EIN and others) and jurisdiction that issued the identification number, entity address (a short form and long form), and interestingly, the legal form of the entity as recognized in the domestic jurisdiction. Clearly the entity type was not a required field in any of the OECD tables 1 through 3 and disclosing this will require some additional due diligence. For example there is a requirement that when it comes to stated capital and accumulated earnings of a branch and permanent establishment (PE), the amounts should be reported in the jurisdiction of the parent and not the jurisdiction of the branch or PE (with some exceptions for stated capital of a branch or PE). The rules for partnerships and other flow through entities are more complex. The U.S. proposed rules for example require all CbC table 1 items for flow through entities to be reported in the jurisdiction of the partners, whereas other jurisdictions’ CbC requirements may include that a partnership’s CbC items be re-classed to a stateless jurisdiction. So an MNE filing directly in two jurisdictions may end up preparing CbC reports using two different calculation assumptions; one where partnership items are shown in the jurisdiction of the partners and another where partnership items are shown in a separate stateless jurisdiction. In a complex MNE organization structure with several branches, several partnerships at various tiers, and multiple partners in multiple jurisdictions, performing these calculations under alternative assumptions is no easy matter.

Tracking and Updating Schema Changes with Each Filing Year
Also worth noting is that schema is never static and there could be changes for the CbC filing from year-to-year. These changes need to be tracked to ensure that when you go to file each new year’s CbC report, you are in compliant with that years XML schema and other reporting formats. Think of how this then is compounded if you have multiple jurisdictional filings.

Summary

    • Preparing CbC Reports in the XML Schema proposed by the OECD is complex and requires a fair amount of computer programming
    • It is very likely that jurisdictions will adopt the same schema for MNEs to submit their CbC reports but there will be variations to capture country specific requirements
    • It is most likely that MNEs will end up having to file CbC reports directly to more than one jurisdiction which will also mean maintaining multiple XML reporting formats
    • It is very likely that jurisdictions will modify their CbC XML Schemas year over year
    • There is also a notification requirement and this must be satisfied by filing directly with each jurisdiction unlike the CbC report where multiple jurisdictions can receive the CbC report via automatic exchange
    • In addition both the CbC report and the notification will have to be e filed meaning some form of machine to machine communication with the filing tax jurisdictions
    • The OECD XML schema is asking for additional information compared to what is in the current OECD table 1, 2 and 3 templates including legal entity type which could be an additional data point that can be used by tax authorities to determine if roll up and reclass logic is correctly applied
    • The OECD XML schema should also be seen as an opportunity to add explanatory narratives like the use of NOLs and other incentives to explain a low taxes paid and taxes accrued as well as to notify the tax authority as to which jurisdictions should be entitled to receive the CbC report via automatic exchange and which jurisdictions should not since the rules that determine this is complex and constantly evolving as countries continuously implement CbC rules often with retroactive effective dates.