Would ESEF mean easier financial analysis and better comparability?
Following on from our previous blog on ESEF’s comparability issues with the anchoring and extension...
Learn morePlease use Chrome for a better browsing experience as Internet Explorer is not supported
Download ChromeWe’ve written in the past how ESEF is a good step towards a digital future, but it’s by no means the “silver bullet” to improving the way listed businesses report their figures and, equally importantly, their story to the market.
One of the key challenges in ESEF’s practical implementation is undoubtedly the application of “extending and anchoring”. In the case where there’s no appropriate corresponding element in the base ESMA taxonomy (itself, based from the IFRS taxonomy), issuers can “extend” the taxonomy and create a new entity-specific tag or “extension”.
To avoid any reporting manipulation, ESMA requires each “extension” to be further anchored to the closest wider base element that’s already existing in the taxonomy.
Based on our research, 18% of ESEF data will generally need to be “extended and anchored”, which is around 40 figures per ESEF filing, on average. So, even though “extending and anchoring” have been introduced to prevent any reporting incomparability and data distortion in ESEF, there’s still room for discrepancies that might require some extra manual intervention by users.
Much work has been done by groups such as BP plc and Royal Dutch Shell plc to suggest how to compare data in extensions, when every extension is different. Let’s highlight the crux of the issue that they’re trying to resolve.
Company A – A large Oil & Gas listed business:
Company B – Another large Oil & Gas business:
By looking at their Consolidated Income statement, we can see that both of them have lines or elements that very likely relate to the same kind of thing. However, because an equivalent tag doesn’t exist within the ESEF taxonomy, both firms will be required to extend and anchor that element.
What’s more annoying is that the extension tags will very likely be called “Exploration” in one instance and “Exploration expense” in another. The default will be to simply use the line item description as the name of the extension tag, which will automatically create data incomparability (unless somebody does some work somewhere to “tie” them together). A simple search for the word “Exploration” might reveal both items, but further would be needed to associate them with each other; hardly an automated way of comparing data.
To solve that problem, our team have come up with quite a neat solution.
Because we tag everything from our Belfast office, we have a wealth of knowledge of how to tag accounts. We also have shared technology and shared expertise and experience. And what we’ll also have is a shared library of extensions.
In other words, as we begin to tag ESEF accounts “for real”, we’ll be creating a library of all extension tags that we apply. This will also help us understand what’s been seen before and collectively learn about what’s in accounts that isn’t in the ESMA taxonomy.
What this also means is that when we’re “extending and anchoring” for our clients, we’ll re-use tags from our library as far as possible. To the example above, if we’ve tagged “Client A” and added “Exploration Expense” to our library, then when we come to tag “Client B” we’d use that same extension. So, should the two datasets be analysed against each other, those two extensions would be identical, giving a little more comparability to the data.
If you’d like to find out more about our ESEF solutions, please get in touch.
Following on from our previous blog on ESEF’s comparability issues with the anchoring and extension...
Learn moreIn recent months there’s been a little uncertainty around ESMA’s latest mandate ESEF, which has...
Learn moreHosted with our ESEF partners Black Sun, this webinar provided the latest news on the requirements...
Learn moreOur for:sight platform offers a robust solution for tax teams, and its machine learning capability Fix & Verify takes its functionality to the next level.
Fix & Verify can not only save your tax teams time but also help to avoid errors by scanning 100% of your transactional data for anomalies such as incorrect VAT codes and manual keying errors.
This is crucially important in an era where tax administrations are pushing towards insight, accuracy and transparency.
We believe your tax department could benefit from Fix & Verify within for:sight. Want us to look at your data and prove it? Request a demo today and our team will be in touch.