But does that make XBRL useless? No. It just means you'll need to make a few adjustments to the tagging. A small extra step in the process with the right tools. If you don't, if you insert raw XBRL numbers, the ones you can get from the SEC or XBRL.US straight into your models, your analysis will be flawed. I'm not saying it might be flawed - it WILL be flawed.
I say that because I've looked at the following table. Well actually I compiled it. It shows the incidence of extensions for all 25 of the non financial companies in the Dow Jones Index (DJ30) for the latest published XBRL income and balance sheet and was compiled using our X Sheet. As long as you only want to compare Apple against Intel you should be fine or the other lone troika of companies that have no extensions on the face of the primary financial statements. Otherwise you've got a problem.
You can download the full spreadsheet here.
I chose to look at the face of the two principal financial statements for the DJ30 because I wanted to look at the best case scenario. The most comparable values tagged by theoretically the best resourced companies, supported by the top audit firms and therefore capable of delivering pinpoint tagging. The tags I looked at of course represent a fraction of the tagged elements in an annual 10-K, and being the most commonly summarised amounts, the ones in theory least prone to being extended. I excluded the financial companies as they are a bit more peculiar so maybe even more liable to be extended. Like I said I wanted the optimum target result.
Just in case you are not familiar with extensions, an extended tag is a useless tag. That's being a bit harsh but it does make comparative analysis exceedingly difficult, without intervening to pull it back into the US-GAAP taxonomy (the list of standard tags). The idea is that companies can extend this standard taxonomy by adding their own bunch of tags on top, where items don't fit into the list. This undoubtedly legitimately occurs and this is part of the beauty of XBRL, that it allows for this. It wouldn't be XBRL (eXtensible Business Reporting Language) without it. Unfortunately, in reality, it is up to the company to decide when this is so.
And so ineffectual is this type of extended tagging, that when Europe joins the XBRL party next year, ESMA has specified that this type of disconnected extension will not be allowed. Every value will have a backstop connection to a tag in the IFRS taxonomy and if that does not fully describe the item in question, an extended alias maybe used as its primary tag.
So having said all that, I'm not sure we should be seeing so many extensions on the face of the financial statements. Surely they should pretty much all look like Apple. Exceptions that prove the rule not make a mockery of it. Anyway I'm not gonna dwell on that. It is what it is. A more pertinent question then is whether these extensions really matter and if so what we can do about the data we have in front of us. This is why the table is not just a simple count of extensions but an examination, albeit cursory, of the potential impact on meaningful company analysis.
We've had a lot disconcerting reports on extensions before but I wanted to make this inquiry as real world as possible. So the top level items and my subjective assessment of the likely impact on KPI's or the ability to strip back figures for future forecasting. So some extensions I have deemed as insignificant, some likely to have a minor impact and others, which set off a big red flashing light as, major. So where a total, which can be calculated by combining its disclosed components using established taxonomy data validation rules, has been extended, this is deemed as insignificant but where restructuring charges have disappeared from the standard taxonomy by virtue of an extension, I have considered this a major problem. I have sometimes paid attention to the size of the amount but really it is not necessarily a reliable marker as for example in some years restructuring charges can be massive and others minuscule.
Anyway you can make your own judgement as I have made the spreadsheet containing the table available so you can use the X Sheet to see all the extensions for yourself by looking at the Filings tabs. Also by looking at the totaliZd tab, you can quickly see the scale of the impact on a comprehensive set of standard values designed for analysis (we call our version the X Financials). The scaling option, a feature of totaliZd, has deliberately been set to billions so you can more easily see the significance of any impact. A value of one could even be significant within or without its group at this level of magnification.
As the screen shot above shows, any amount in the square green boxes, is a problem that needs fixing. How you do this I cover in the next post.
What you see in totaliZd is as bad* as it can be. That is not a comment on the individual companies involved but the limitations of using neat XBRL. This is the point of totaliZd, to provide a starting point, from which you can quickly fix this apparent mess and leverage XBRL to perform the kind of analysis never previously possible before. I'm not dissing XBRL. I'm simply qualifying how you use it.
*Things get off to a very bad start for Exxon and Coca Cola as neither them supply a Revenues tag. This isn't even an extension problem. This is just a "not using enough us-gaap tags" problem. Problems like this automatically get fixed in the X Sheet when using our standiZd option.
This post could really be considered part of a series I started in 2017 - And so has the dream come true? to look at the state of XBRL disclosures and examine the continuing validity of the objections raised in using it.
No comments:
Post a Comment