It is 30 December and 2 MNEs contact me about my YouTube videos on uploading Country by Country Reports (CbCRs); they need help. In the week of New Year, I helped taxpayers in Bermuda, Belgium, Britain (for B’s), Cyprus, China, Colombia (for C’s) and then some more down the alphabet (not Zimbabwe).
I remembered how taxpayers fought CbCR during the BEPS process at the OECD (I was a delegate for the Danish competent authority) and about how they used confidentiality and security as excuses. Then I looked countries extravagant confidentiality procedures today, from electronic handshakes to SOAP responses and I thought, “Boy, this is payback time”.
A few anecdotes, a few good news examples and then some suggested best practices going forward.
The anecdotes
The Brits: page 20 of the “HMRC Country-by-Country XML User Guide”, V1.0.1.02, Updated, gives the following examples of what a unique Message reference (an ID for the whole CbCR filing), and unique Document references (IDs for sub-parts of the CbCR filing) should look like.
- The message reference consists of the reporting entity country abbreviation (twice), the reported year, the taxpayer TIN, an OECD message type indicator, the OECD required timestamp (from the year, down to the second), and a unique, incrementing element with maximum 56 characters (for perspective: the diameter of the universe, measured in millimetres, is 8.8 with 29 zero’s, or 30 characters). Their example: “GB2016GBXACBC0000999999CBC40120170523T140000123456 789”.
- The document reference then consists of the message reference, a whole lot of other information which is already in the CbCR and unique, incrementing elements with maximum 41 characters. The total characters per reference may not exceed 250 (the first paragraph of this blog is less than that).
The HMRC DocRefID requirement is without a doubt the most useless summary of CbCR file imaginable. Suffices to say that some taxpayers took days to get their OECD validated CbCR files successfully uploaded to HMRC. And for what?
- The simple combination of the taxpayer TIN and the timestamp to the second makes every taxpayer filing unique already. Add to that a 4 digit document reference number e.g. an “R” for Reporting entity, “C” for CbCR numbers or “A” for additional information, followed by 3 incremental numbers starting at 001 and you would have enough unique variables to cover 999 countries and 999 additional comments.
- All the additional information asked for in the references are in the documents already.
- Very few, if any, countries will follow the UK reference format, so the extravagance becomes useless in country to country exchanges of the CbCR. Global simplicity would, and uniformity might, have been so much better.
In a previous blog I have already vented about the difficulties with the CbCR xml namespace and the lack of practical examples by governments. It turns out that the OECD does, but HMRC does not, accept xml files which do not include “version=”1.0.1″” in the CbCR xml top. However, this requirement is nowhere to be found in the 36-page HMRC guide referred to hereabove.
To their credit, the HMRC website at least tells filers why their documents are rejected. I know of at least two jurisdictions where the rejections come with no, or very generic, rejection reasons.
Then off course there is France, where I have been told the CbCR’s are not accepted in XML format at all, but in EDI format. EDI is an older, far simpler, but unreadable format for the human eye (making visual verification of the file before filing difficult). So while the rest of the world is working on XML solutions, French filing companies have to figure out an EDI solution by themselves, which the French government will then convert into xml files to share with the rest of the world’s tax authorities based on the OECD’s manual.
A last curveball came from an Excel macro quirk, and additional, unpublished, validation requirements. When Excel converts numbers into text (ie an xml file), it adds a space before and after those numbers. The file still validates under the OECD xml schema and is – to the best of my knowledge –accepted by all countries, except one. A sunny taxpayer friendly island, is to have none of these loose spaces and rejects uploaded files with a mere “we see no numbers” message. Again, is this country going to reject the other countries’ xml files (e.g the UK’s or the US’s) if they have spaces before the numbers?
Good news examples
Off course my view is limited to that of one person and I may miss many other good examples, but here are some worthy mentions I saw. I start with the taxpayer friendly jurisdictions, as it seems they are also friendly in assisting their taxpayers in their compliance.
- The Dutch has to be commended for starting filing process early, having an open dialogue with IT solution providers, for extensive published guidance and for allowing test portals to help taxpayers test their filings before uploading their final version. It would have been even better if their uploading process was less complicated.
- Singapore deserves a best in class award for being the only country to my knowledge that actually produced extensive guidance in the form of a spreadsheet, giving actual examples of namespaces, DocRefs and MessageRefs.
- Bermuda should be recommended for manning a helpdesk to help taxpayers with their filings on Saturday 30 December.
Finally, as far as CbCR notifications are concerned, Denmark is to be commended for developing a simple bilingual pdf file with a “Send” button converting your notification for you into an email with an xml attachment. Fantastic. I do hope they share their solution with as many countries as possible.
Suggested best practices going forward
I have said it before, “compliance should never be this difficult”. Here are a few suggestions on how the OECD and countries can make the CbCR filings easier (and if taxpayers think the filing of the reports were difficult; wait until you try to file xml file corrections. That is the hitherto unread second half of most CbCR filing guidelines).
- OECD, please develop Excel templates for taxpayers to use for their future CbCR filings and CbCR corrections. If you can write a 50 page XML Schema guidance for taxpayers to use (yes, it covers taxpayer filings too), then you have permission to make Excel templates as well.
- OECD, please make the Danish notification solution available for other countries to use.
- Countries, please do not implement validation rules beyond the OECD XML schema rules. If you want specific DocRefs formats, please try to standardize across nations and try to do outdo each other in simplicity and robustness, not in useless complexity.
- Countries, please follow Singapore’s lead and make example files for CbCR filings and CbCR corrections IN EXCEL. We are living in a spreadsheet world, our financial systems spit out our data as spreadsheets, not as Pdf prose. Also, have your guidance read and understood by your tax auditors, not your IT people. Very few tax professionals speak IT.
- Countries, please set up responsive help desks (24 hours on weekdays should be a maximum response time for questions) and incorporate their assistance into FAQ (Frequently Asked Questions) pages on your websites. FAQ pages will greatly help your taxpayers with getting validated uploads and quickly reduce the number of people needed to man your help desks. It would also highlight the filing problem areas to more people than just your helpdesk department.
I wish everyone a great 2018.
________________________
To make sure you do not miss out on regular updates from the Kluwer International Tax Blog, please subscribe here.
