Getting started with an XBRL API Data Call

(if you've stumbled across this article and want to know more, email us and I can add you to our beta programme)

We have set up an Excel sheet to make it really easy to start quickly pulling data back using Beryl, our API, or indeed, the XBRL US version.

All you have to do is fill in the coloured boxes in any of the sheets and run the query to bring back a time series for your chosen data point.

For our API you will need a token which you can get from our website by registering or signing in, which then goes in the Red Box.

To run the query, move to a cell in the grey area where the results are. Right click and choose refresh query or use the keyboard shortcut ALT F5. In Excel the API call is made using Power Query.

Green Box - Tag. Choose a data item by entering an XBRL tag. We have constructed a data set of the most commonly used tags that you are likely to need called the X Financials. These are listed on a sheet at the back of the Workbook. If you want to see all the tags you could possibly ever use! then got to an online XBRL Taxonomy (there are quite a few free ones around). I use the Workiva Wdesk Taxonomy Analyser. You can also just enter "All" in this box and it will bring back data for all the items used the companies you select.

Green Box - "All". If you don't know which tag to select or need to get familiar with the tags in use, you can put "All" in the Green Box as the Tag.. Be aware that if a value lies off the main axis (sorry getting a bit technical here), then these values will not get returned with this call. This only applies to more obscure values that might have been disclosed in a more complex table in the notes. A full explanation of axis and dimensions is explained in another article. Values on these axis will be made available in future. We want to make sure we do this in a meaningful way that doesn't bombard you with incomprehensive incomparable data

Orange Box - Date. Choose a year for the values that you want returned. It will get values from filings with a reporting period ending in that year. So specifying 20191231 will return values from a 10-K with a year end up to and including that date. If you just enter 2019, it will do the same. If you enter 20190630, it will bring back values for filing periods ending between 20190630 and 20180701.

Orange Box - Years. The other (optional) Orange Box, Years, determines how many years of values are bought back. So the Date box specifies the starting year and Years how many periods are returned in the series. If no Years are specified, it will bring back one year of values.

Blue Box - Cos. Enables you to specify which companies you want values returned for. This is where the beauty of modern Excel kicks in. Add a ticker to the bottom of the list and the Excel Table (The Blue Box) automatically expands to include it. Companies have to be specified by ticker, but don't worry if you haven't got the ticker at hand, you can quickly look them up using our API on the Beryl Cos sheet. You can always reduce the number of companies returned by pulling the Table back up to its original size using the triangular (ish) handle at the bottom right corner of the Table.

Also read - A Walk Around the Results Returned by an API Data Call (coming soon).

Will there ever be less XBRL data items?

If you read my previous post, you will know that the arrival of the SEC US-GAAP Taxonomy unleashed a veritable tsunami of data items on a concerned body of filers and a bewildered bevy of investors.

So with so many data items milling around, you would have thought that someone or something might be sent out to clean it up. Well the good news is that in late 2014, the FASB launched the Xbrl Taxonomy Simplification Initiative.

And now the not so good news...

Source: FASB - 2017 Taxonomy Release Notes

Looks good until you realise that this represents the rate of change. In other words you don't really want the blue line exceeding the red line. But you can actually see the impact of the 2014 initiative as the red line finally jumps above the blue one through 2015/2016 reaching a peak of 681 deprecated items in 2016. I have to say I still find it staggering that there are so many items to choose from given how few items companies actually disclose in their 10-K's and Q's.

So is there any way out of this forest? Well all is not entirely lost because in March 2017 the SEC finally agreed to allow foreign filers to use the IFRS taxonomomy. This is good on two counts. One it means that all foreign filers will for the first time be required to file XBRL which starts to answer the is it only for US Companies question (more on this later!) and two it establishes a precedent that a taxonomy does not have to have 16,000 data items.

The IFRS Taxonomy which is designed to satisfy the filing requirements of every country around the world, not just one large country, has only 4,610 items. It did have a lot less (47% less to be precise back in 2011 when it was originally scheduled to be mandated) but I think they were told to bulk it up a bit if they wanted to get SEC approval (sound of head banging on table). A group was tasked with adding items by custom or practice (and approx. 1,000 Common Practice items have been added since then). During this process no specific consideration is given to how useful an item's structural relationship might be - this is sadly not the philosophy behind either the IFRS or US taxonomy. Well at least 4,500 is a lot better than 16,000.

IFRS based XBRL is likely to be adopted for mandatory filing in Europe in 2020 and one would imagine the rest of the world will fall into line after that (completely answering the US Companies only question). Most of the world now uses International Financial Reporting Standards or has standards based on them.

I should point out that I am a member of the IFRS Taxonomy Consulative Group (ITCG). But this is not why I'm a relative fan of the IFRS taxonomy. It's just got less items in.

What do filers do with all the XBRL data items at their disposal?

This is the latest in a series of ponderings on whether the XBRL dream has come true?

In our XBRL to XL database, we have 20,000 data items that originate from the US-GAAP Taxonomies. That's a heck of alot of data items. Admittedly that includes alot of bumf that is just there for presentation or connecting stuff (abstract items) or axis (column headings) and items that have subsequently been deprecated. But compare that to S&P Compustat's 500 odd or the 1600 data items we use for our standardisation routines.

I guess the FASB were worried about companies using extension tags, although perhaps there are more direct routes of limiting i.e. prohibiting extensions.

Of course the more there are, the greater the risk of mistakes. Choosing the wrong item over another in the same section is not easy to detect. Usual validation routines won't pick it up. And none of this stuff is audited. Ultimately it is up to the company, or whoever they've outsourced their XBRL tagging to, to pick it up.

The kinda advice stressed by Ernst & Young on the release of new taxonomies is typical and not surprising.

"As they move to a new taxonomy, companies should review their practices for selecting XBRL tags and thoroughly search the tags in the new taxonomy".

So what value do we as users get out of all this wonderful detail?

Well lets have a look at disclosure levels for our probably over the top standard data set of 1632 items (lets refer to this set as the standidZd 1600. So a couple of weeks ago I did a chop of our SEC XBRL to XL database (powers XBRL sheet) to check on item usage. I thought it would be interesting to look at usage for our reference set of industrial companies we established when looking at filing histories (seeing our standiZd 1600 was designed explicitly for non financial companies). Keeping everything consistent with all our other data sampling in this series, I only included 10-K's but all the 10-K's they've ever filed in XBRL. I should stress that this is before we've applied our standardisation routines.

So what is this table telling us? That 263 of our standiZd 1600 have NEVER been used by any of the top US industrial companies. And a whopping 65% of what we regard as the most comparable individual data items have been used by 5% or less. So if we were trying to compare any one of these 1000 odd items, we would have at best only 11 other companies (and roughly on average probably only six) to compare them with. Lets hope a couple of them happen to be in the same sector! And we can probably forget about creating any meaningful aggregates for these items.

What happens if we widen it right out to the total population of US-GAAP tags and the total population of companies. Not surprisingly it gets uglier. 10,000 of US-GAAP tags appear in 5% or less of the total number of 10-K filings made to date (approx. 50,000). And roughly only 1,000 items appear in more than 5% of these filings.

This isn't a perfect piece of analysis as some items have come and some items have gone (but that has been happening by and large around the margins of the taxonomy)

So it's probably not too unreasonable to conclude 20,000 data items is drastic overkill for comparative analysis and that our 1600 standiZd data items IS over the top! We will certainly take a close look at those 263 items to see if we need to rename! this set downwards.

So what use does this disparate tagging have? Well it does allow us to easily find the rare occasions where particular tags have been used but because use is so rare, it probably has no real advantage over them just being tagged using extensions. A simple text search, although not as neat would be just as effective, if not more so as it would pick up all (the right or wrong) occasions when an extension has been used instead.

All this prompts the question - will there ever be less data items?

Firefox XBRL Add-on

Continuing my trawl through the free viewers.....

As I mentioned in my previous post, the Firefox XBRL Add-on, although apparently not supported, has a couple of tricks up it's sleeve.

With the Firefox XBRL Add-on you can view any of the taxonomies used in the creation of the XBRL and you can drill down into the notes for a financial statement item by clicking on it to reveal a pop up box that will show any links, providing these have been enforced in the original document. Charles Hoffman calls this "metadata leveraging".

He also discovered that you can do some crazy stuff by dragging & dropping the headings around like you can in an Excel pivot table to totally customise the view. You can do this with any heading with a triangle in the top left hand corner. You can swap them round or drop them onto "[DRAG PAGING COLUMNS HERE]". Not sure how useful it is at this level but it's mildly entertaining. Perhaps more usefully, you can choose to view only specific data items or periods by clicking on the "Item" and "Date" headings (with the triangles in the corner) to reveal lists with check boxes. You can't however save these settings to use with other documents.

And It will turn XBRL into iXBRL and vice versa, although the iXBRL doesn’t always render perfectly but if you wanna turn XBRL into a single document to read offline, it’s fairly adequate.

The Add-on is not based on the Rivet open source code. Don't be put off by the fact that Firefox says it's not compatible with version 5. It will install and work once you relax Mozilla's strict compatibility enforcement in the options. Click on a copy of the instance document on an Edgar filing page and (after a short interlude) the add on will kick in to enable you to see the document. You can also view documents on your hard drive, although it will need a connection to download the taxonomies before it will load.

Of course the fact it is in Firefox maybe a problem. I moved over from Firefox to Chrome last year so it's not where I'd ideally like it.