(“Every in-house tax department should have their own IT/Financial systems capacity” – JHM, TP Minds London, 2015.)
The unexpected benefit from country by reporting (“CbyC”) reporting is that tax departments may learn something about their own groups’ financial systems.
What is there to learn?
If you are in-house, answer these four questions:
1. Do you know what the difference between a relational database and a spreadsheet is? If you don’t, you cannot work with your company’s data.
2. Do you know that your group accounts are one big relational database? If you don’t, you don’t know what data you can pull.
3. Have you ever considered the possibilities database holds for your department? If not, a useful instrument lying at your fingertips is going to waste.
4. Do you have a detailed understanding of how foreign subsidiaries’ local purchases and sales end up in your consolidated accounts? If not, you are at the mercy of others telling you what you can and cannot know.
If your answers to two or more of the above was yes, then you know:
1. how to regularly pull relevant financial data to actively manage your tax risk; and
2. unfortunately, you also know the quality of that data may be in need of improvement (and it is better to know this upfront, than to find it out it during a tax audit).
I have seen tax in accounts being completely out of scope, simply because they were used as waste baskets for everything local bookkeepers did not know where to file. Likewise, I saw subsidiary accounts being reconciled into consolidated accounts over interim spreadsheets hosted on employees’ laptop’s C-drives (and yes, that person left by then and their laptop was passed on internally).
Knowledge without application is useless
If you learn the bare minimum about your group’s financial systems during the CbyC reporting process and leave it at that, you would have opened the door opportunity and slammed it quite shut again. Here are some of the things a tax department could do upon exploring your group financial systems and the use of IT further:
1. Map intercompany transactions against transfer pricing (‘TP’) files and reconcile them. IFRS requires your group to account for all its intercompany transactions. Now imagine if instead of assuming you know all your intercompany transactions, you get the actual aggregate numbers for e.g. internal turn over on group level, a regional level, a company level, a business unit level and even get the budget to actual variances (in order of size).
While you are in the process of mapping intercompany transactions, it would also be good to determine what numbers in your TP files are based upon: is that the consolidated financial statements, the local statutory numbers, or the local tax return numbers. Better still, figure out and explain any differences between them upfront, as you need to report that in your country file under BEPS Action 13.
2. Understand how easy it is to pull the data required for CbyC reporting (it is just a spreadsheet template with the right combination of dimensions and Smartview formulas (if you are using HFM)). I “conveniently” leave out possible difficulties with PE data, as:
a. whether this is a problem depends on how your group books PE activities (I cannot imagine your management having no idea of how their branches are performing);
b. I refuse to be a scaremonger, treating exceptions (like PE’s) as the rule.
In short, there is no reason to let any consultant make you pay thousands of Euro’s for data which is readily available and at your fingertips.
3. Pull high level value chains. You can do this at a group level or a divisional level, but also a (sub-)sub-divisional level, a product level, or an activity level. Such value chains:
a. test your TP policy for realism. For example, is there a realistic chance for the residual profit/loss bearer in a value chain to ever make a profit of more than 5% if all low risk functions are compensated on a cost plus 5% basis.
b. Test your budget for realism. E.g. it may seem fine to put a seller on a TNMM of 4% of gross sales. But, if the seller has a large sales force (booked below the gross sales line), it may wipe out its total margin with 100% predictability.
c. Allow you to track budget numbers against actuals and act on time. Until a TP system can do this, it is just a reporting tool akin to a tax return. To manage your TP risks upfront, routinely tracking actual against budget moves is an imperative minimum, not an ultimate goal to strive for. And yes it can be done at a high level or a specific transactional level, preferably through automatic – vs manual – data extraction.
d. Can be a powerful weapon in tax disputes (when you have nothing to hide). When tax authorities’ fear of their country being “BEPSed” through TP leads them to unreasonable adjustments, showing them a relevant value chain and system profit distribution can bring you victory either with them, or in court, or in MAP.
4. Align your tax reports with management reporting and upgrade your department’s relevance.
5. Save cost and become more effective; IF you do it right. It should be clear from the above that a greater familiarity with your finance systems and automation, can give you faster and cheaper access to helpful (and potentially harmful) facts.
A few words of warning
1. A consolation: you do not have to become an IT specialist or accountant: you become a better tax specialist with broader, useful skills, operating on facts, not assumptions.
2. Still, you must invest and be prepared to learn. If you do not understand the possibilities of a bit of coding, what relational databases can do, or the data available in your ERP system, you will not know what you can ask for.
A banal example: today I can write a simple program to scan through the entire Encyclopaedia Britannica and give me the 100 most used words and how many times they occur. The question is how to turn this into a useful tax skill? Maybe I can scan large volumes of internal documents for occurrences of tax related words to avoid nasty audit surprises, or scan the financial files for every tax related account (and pull the largest numbers, or most occurrences).
Another real example is being unable to recover VAT, or quantify non-recoverable VAT, because VAT is booked all over (sometimes as cost of goods sold, sometimes as tax). I can have a program find those bookings, e.g. in the original cost of order.
I do not have to be able to code, but I should be aware of what I can ask to be coded.
3. Your initial results will not be perfect. To expect otherwise is to be disappointed. However, if you are prepared to start simple and improve through small incremental changes, you will soon have a useful, predictable tool, especially if you follow Pareto’s principle (the 20:80 rule), instead of getting incapacitated by minor exceptions. The key to progress is shipping: start small and fail small; don’t focus on perfection, prioritise delivery.
4. “There are so many exceptions”. I so often hear companies say that automation is virtually impossible, because for them, exceptions are the rule. While I do not dispute that, I believe most exceptions are pretty consistent, and therein lies the solution. Automate the consistent exceptions where it only requires a few lines of coding or ask someone to do a few simple tasks (taking less than 15 minutes). E.g. let the local accountant for sales in subsidiary X send you their largest intercompany transactions quarterly.
Another very practical example, by way of a question. When last did you speak to your group account comptroller taking care of intercompany eliminations? Can they send you an overview of all the intercompany transactions they have eliminated?
Conclusion
I think that CbyC reporting may just be credited for opening an in-house tax field of which the development is long overdue.
________________________
To make sure you do not miss out on regular updates from the Kluwer International Tax Blog, please subscribe here.
