Read technical background on iXBRL and what it means for Irish companies submitting their accounts.
iXBRL (which stands for “eXtensible Business Reporting Language) is a freely available, open, and global standard for exchanging business information. A primary use of XBRL is to define and exchange financial information, such as financial statements, in a computer readable format.
iXBRL (Inline XBRL) is a development of XBRL in which the XBRL data is embedded in an XML document, e.g. a published report and accounts. Typically, iXBRL is implemented within HTML documents, which are displayed or printed by web browsers without revealing the XBRL data inside the document.
Why are tax authorities like the Revenue insisting upon iXBRL filing?
A combination of improved reporting and analysis capability for tax authorities as well as reduced related costs is probably the main reason. Revenue has seen the capability to perform instant analysis of high value data using their gateway computers.
A Revenue computer can immediately scan and record your debtor and corporate tax values and then this data can be compiled with thousands of other taxpayers’ data. This provides tax authorities with the capability to compare and contrast other similar sized and structured entities relatively easily. This is done whilst effectively transferring the reporting and data preparation work to taxpayers at the same time, which is quite a neat trick.
How have your clients responded to the iXBRL filing requirement in the UK to date and how do you expect your ROI based clients to fare?
There was some initial concern expressed by a number of our clients at what was perceived as pure compliance work. The consensus view was that iXBRL provided little in the way of immediate tangible benefit as they saw it – especially at a time when there was so much global economic upheaval and strife affecting companies already.
The perception was at first that this was perhaps not the best time to be implementing this extra layer of compliance work with all the additional costs and effort required for it consequently. This perception was not helped by a number of advisors advocating the early view that iXBRL would never come to pass and that HMRC would rescind this reporting requirement – which as we all know now – they never had any intention of doing.
Having said all this, all the clients we have dealt with approached iXBRL filing very proactively and positively. We tried to help augment this by reminding them that HMRC had added in a caveat of a “Soft Landing” approach in the first year of iXBRL. What this meant was that if taxpayers attempted a “Best Effort Tagging” approach to their tagging, during the embryonic iXBRL reporting period, no financial penalties would be forthcoming.
This sensible approach by HMRC was appreciated by vendors and taxpayers alike, and meant there was a bedding-in period in which to develop the new necessary tagging skill sets.
To date we at KPMG have not had a single client who has failed to submit their final accounts to HMRC and that is a testament not just to our software but to the diligence of our clients when tagging and reviewing their accounts. We absolutely expect our ROI based clients to fare similarly well.
Explain the typical process of transferring Statutory Accounts data into an iXBRL Format and filing your accounts?
There are a number of iXBRL tools available on the market right now, but what they all fundamentally do is the same things. They import a Word or Excel document (whichever format the Statutory accounts are in) and then allow a user to attach “tags” from a taxonomy (an electronic chart of accounts) to matching items on the accounts.
So by way of example, there is a section in the taxonomy called “Balance Sheet” included in which are tags for all the items located in a Balance Sheet such as debtors, fixed assets and share capital. The user then transfers the appropriate tag to the appropriate item on the face of the accounts through a process known as “tagging”. The tag will attach to the text and usually become highlighted so as to indicate that text is tagged.
What this means is that when the Word or Excel statutory accounts are then converted into a HTML document suitable for submission to a tax authority website – on the top level the accounts are still readable and in the same format as the original Word or Excel stat accounts, and beneath this and hidden in the code, is information telling Revenue Online Service (“ROS”) that a debtors value is, for example, €1 million.
Following its successful introduction in the UK by HMRC, online Corporate tax returns and statutory accounts filing is due to become mandatory for Irish Large Cases Division (“LCD”) businesses as of October 2013 with an expected mandatory rollout for all other companies from October 2014.
What one piece of advice would you provide to clients looking to undertake iXBRL reporting?
Plan in advance and do not leave implementing an iXBRL production process to the last minute. Our clients in the UK who reacted quickly and set up processes and filed early found the overall process far less onerous than the clients who tried to ignore the problem till the last minute. iXBRL filing requires a joined up approach from both the Tax and Accounts departments and getting a process in place to ensure the smooth delivery of your tagged accounts.
Regardless of whether you are tagging your own accounts in house using a solution or outsourcing the work to an iXBRL vendor to tag for you, you need to give whoever tags the accounts sufficient time to do so. Additionally, it is strongly recommended that someone different to the tagger reviews the tag choices made prior to final submission. As we have mentioned previously, iXBRL can be a technically challenging discipline. Reviewing tagged accounts will help ensure consistency in your tag choices and eradicate the opportunity for unnecessary errors.
Secondly whichever solution or iXBRL vendor you opt for - make sure that their tool and processes includes internal-tag-validation-functionality as standard. Having a tool that performs all the same tests internally that ROS will perform at the final submission stage, means you can rest assured that there will be no mishaps which could cause you to incur penalties.
What difficult practicalities are there in tagging a set of accounts?
Typically we have found that a lot of clients have initially underestimated the difficulties associated with iXBRL. This is primarily because it seems at first inspection to be a simple, rudimentary process with no technical skills required to perform. In fact, whilst the physical process of tagging is a process that anyone can master very quickly, there is also a real skill in being able to select the correct tags for the correct items on the face of your accounts. Furthermore, what we refer to as “tag etiquette” (tagging a certain type of tag in a certain way) often plays a critical role in the overall process.
The potential error points that we normally see occur fall into one of four key headings:
Getting the Basics Right or Wrong
It may seem a banal and obvious thing to say, but making sure that the simple bits of tagging are done correctly is the first key step to a successful submission. We have lost count of the number of times we have been asked to review a set of tagged accounts where all the complex tag choices have been made correctly and reflect a lot of hard work by a client, only to see this hard work and effort let down by a silly and unnecessary error elsewhere in the tagging.
There are a number of these that do crop up and most of these will either result in an immediate failure when you go to submit your accounts to the Government Gateway or ROS, or even if they pass this technical test, will be picked up as an error by a tax official when they review your accounts.
Some of the most obvious ones to look out for are:
As such we recommend that if clients are tagging their own accounts with KPMG’s XME or an alternate vendor solution, that a qualified accountant be the person who performs the tagging. The reason for this is that anyone else will invariably struggle to select the correct tag for the correct item on the face of their accounts.
Choosing the wrong tag
All of the taxonomies are made up of the combinations of items one would expect to see in a typical statutory accounts document. This will include relatively simple items such as debtors or administrative expenses. These items are self explanatory as to what they are and relate to, and are matched by obvious tags in the taxonomy. There is no confusion here and any layman could use a search tool to use the nomenclature to select the correct tags for the correct items on the accounts.
However if accounts and accountancy was as simple as this, we would not need to study to become qualified. This complexity is reflected in iXBRL as well and more so than in pure XBRL.
iXBRL- as has been mentioned previously - is a combination of pure XBRL (technical code data) with an “inline” readable document sat on top. It might help to think about this as two documents submitted “inline” with each other simultaneously (the “Text and the Tags” as they are sometimes referred to).
HMRC and the Revenue opted for iXBRL over pure XBRL because it provides more flexibility for usage. In XBRL (which is used in the US primarily) every taxpayer is required to extend their taxonomy so that each and every item on the face of their accounts can be tagged. In iXBRL by contrast, the expectation is that a maximum of 70 – 80% of items on your accounts can and should be tagged.
The 30% of items left untagged are still readable by a Government tax official upon submission, so no information is lost in the process. iXBRL tagging is a lot quicker and less technically difficult than pure XBRL, meaning it can be used wider and more proficiently by taxpayers too.
However, the downside to this approach is that whilst certain tags are obvious as to how they should be tagged, others are less so. This is where having the technical knowledge and understanding of iXBRL is so crucial. To be “Best Effort Compliant” a tagger needs to know when to tag an item, what tag is most appropriate and when to have confidence that there is no appropriate tag available at all.
For example, no non accountant would probably have the slightest idea how to define the following tag from the GAAP taxonomy, let alone how and where to tag it on the face of the accounts:
”Transfer to (from) financial liabilities from (to) equity caused by a change in redemption prohibition”.
Tagging items like this right will differentiate good taggers from bad and will give an overall indication to the Revenue tax official reviewing your accounts, as to the quality of the tagging they can expect to see throughout the document.
The third most common cause of errors and confusion is related to Negations – which is otherwise known as “Inversion of a tag’s Balance Type”. This issue still causes confusion for clients years after the introduction of iXBRL in the UK.
As we all know, accountancy and Double Entry is based upon the Debit and Credits principle. Certain items are Debits (Assets and Expenses) whilst others are Credit (Liabilities and Income). These balance types need to be reflected in iXBRL as well. Each tag will have its default Balance type included in its tag characteristics. So Profit for the period will be Credit as standard.
However, if a company has unfortunately made a loss in a financial period – then tagging that item without making the necessary alteration (negation) to reflect it being a loss rather than a profit will result in an incorrect submission. Negation effectively inverts a balance type and has to be applied correctly to reflect the true nature of a monetary tag.
One of the main points of confusion that we see occurring in relation to this issue is why if an item has brackets after it, does it not automatically indicate to the Revenue what the balance type should be, i.e. if I have a loss of $10,000 expressed as (10,000)? The reason for this is because accounts are not universally represented by companies in this respect. Some companies will put Administrative expensive in brackets and some will not for example. In both examples it is still a Debit and an expense – but this different format style can cause inconsistency and confusion when it is rendered in iXBRL format.
So using negation to invert a balance type, although cumbersome, is the only way to really resolve this issue.
We would warn anyone to be aware of this potentially confusing area of iXBRL accordingly.
Inconsistent duplication and casting in iXBRL
One of the main annoyances that our clients voice about iXBRL is that it is compliance work which really does not benefit them at all and add value to their overall process and help reduce risk. A case in point where this certainly holds true is iXBRL’s very limited casting and reconciliation requirements.
To ensure a successful submission a tagger must ensure that any item tagged in two places on the face of your accounts (e.g. Debtors which can be located in your Balance Sheet and in your notes) must be the same value. However, the individual constituent items that make up the total Debtors value e.g. “Debtors within One Year”, “Debtors After More Than One Year” and “Trade Debtors”, do not need to add up to the total “Debtors” amount to ensure a successful submission.
The reason for this is that there is no casting performed in iXBRL because there is no guarantee that you will be able to locate every tag required for your set of accounts. For example if you have a specific Debtors class that is not included in the taxonomy then your total debtors values will never reconcile to the combination of other specific debtors values.
So the issue we warn clients about is not to get hung up on the fact that tagged items do not cast. There is a good chance that they never will.
This article was written in March 2013.
KPMG has developed a cost- effective and efficient solution to help your business manage the potentially significant implications of the introduction of iXBRL.
To find out more about how we can help, contact us:
+44 28 9089 3786