The ESEF audit process would be the last stop in your journey to file your iXBRL annual reports with the local regulator.
This is a journey you would have started in early 2020 by first narrowing down on the software with which to prepare your iXBRL report. You might even have chosen to outsource the XBRL tagging part.
Now in the last leg of your journey, it is time for you to make sure your report conforms to ESEF audit requirements.
We have identified three key areas where you mustn’t go wrong for your report to fit the bill perfectly for an iXBRL audit — ensuring that you submit your reports with a file and folder structure as defined by the ESMA reporting guidelines; avoiding calculation inconsistencies, and making sure the numbers in your XHTML (human-readable) document tie-up with those in the underlying tagging (machine-readable) layer.
Ensure files & folders conform to ESMA guidelines before your ESEF audit
ESMA reporting guidelines recommend a particular file and folder structure for the iXBRL documents you submit to your country’s regulator. And in some cases, the country regulator recommends its own structure.
In case your filing does not conform to the recommended structure, your filing might be rejected. And, so, it is vital that you stick to the recommended structure before you go in for your ESEF audit.
In case you or your auditor happens to use IRIS audit — our iXBRL audit solution — you would notice that our solution does not let a filing go through if it does not follow the recommended file and folder structure.
Remove calculation inconsistencies before your ESEF audit
Calculation inconsistencies occur when either the numbers in your iXBRL report are rounded off incorrectly, or they run into a ‘reversing signages’ issue.
Some amount of rounding off is expected in financial statements. For example, 1+1 = 2.5 might be an acceptable level of rounding off. What might not be acceptable is if the result of 1+1 is shown as 3.5.
The issue of reversing signages occurs when one ignores one key attribute of an XBRL tag representing a monetary item. This key attribute is the ‘balance type’.
We will explain this further with an example.
Take for instance three simple monetary concepts — revenue, cost of goods sold, and gross profit — that can be expressed in a formula: Revenue – Cost of Goods Sold = Profit. The balance type of the XBRL tag for revenues and profit is ‘credit’, while that of cost of goods sold is ‘debit’.
When a calculation relationship is established between revenues, cost of goods sold, and profit, the value for the cost of goods sold is automatically reduced from revenues to calculate the value of gross profit (see the screenshot below). To understand what a calculation relationship is in more detail, read our blog post about the company taxonomy.
If a company tags the cost of goods sold as a negative number in XBRL (since it may have shown its value as negative in the human-readable layer of its document), the negative value that the calculation relationship already places on the element combines with the negative value tagged to render it positive in any calculation relationship. Cost of goods sold ends up becoming a positive fact and getting added to revenues, rather than getting deducted from revenues.
Therefore, in XBRL, it is important to tag the cost of goods sold as a positive value, even if it is shown as a negative value on the human-readable face of the annual report. Its balance type and placement in calculations will take care to let viewers know it is a debit item that will be reduced from revenues.
While this is a simple example, many people fall into the trap of tagging an item as negative simply because the face of the annual report shows it in brackets, or as negative, for ease of representation to users.
In XBRL, it would help you to watch for the balance type of the item and decide whether you need to reverse the sign in your XBRL tagging or not. Not only will this help you steer clear of one of the most common mistakes that can occur while creating the XBRL layer of your report, but your ESEF audit process will be smoother.
Make sure the numbers in your report’s human-readable and machine-readable layers tie up before your ESEF audit
The third thing you must bear in mind before submitting your iXBRL report for the ESEF audit process is that the numbers in your XHTML (human-readable) and underlying (machine-readable) layers are the same.
In the following screenshot, the number that is displayed in the human-readable layer of the iXBRL document is 20,000, while the number to which the XBRL tag was applied is 11,576.
The numbers are different because the software using which the XBRL layer of the document was prepared did not link up the numbers in the XBRL layer and the human-readable layer of the document. To avoid such an error, you must ensure that the number appearing on the face of your document and the number being tagged is the same.
We hope this blog post helps you avoid these pitfalls and breeze past the ESEF audit process.
