Digital Financial Reporting

I wanted to make my loyal blog readers aware of something before I passed this information on to others.  On this blog site there is a web page for the XBRL for Dummies book which is set to be in stores very soon (like next month).

The page is for the XBRL for Dummies book. The page has two things which may be of interest.  First, the organizes the links in the book into book chapters.  Therefore, you can get a better feel for the book using that table of contents information.  Second, lots and lots of links.  The links are good for two reasons:  (a) because they point to other useful information, (b) because it helps you realize the amount of information which is presented in the book.  The book condenses and organizes all that information into a useful and useable form, so you don't actually have to wade through all those links (there are about 350 links!).  But, if you want more detail, use the links to dig in deeper into specific areas.

Happy reading!  Thanks for your support of XBRL.

I have put together a prototype application for accessing SEC EDGAR information. I created this application for a number of reasons which will become apparent later, but the application is also quite helpful in seeing what is necessary to make such an application work and it demonstrates the potential of XBRL.

I cannot take full credit for this prototype. A number of years ago, the University of Kansas created a demonstration repository of XBRL based information.  For that project we created a little "analysis" tool which extracted and used that XBRL based information. I modified that tool, making it work with the current SEC EDGAR XBRL data.

Remember that I am not a programmer and the prototype is more of a proof of concept than an application which would be useful for analysis. It does work though. But keep in mind the following limitations of this application:

• It only works with a list of 408 XBRL submissions to the SEC and is not updated for new submission.
• The application does not make use of an XBRL processor.  An XBRL processor was used to pre-process a few things such as the XBRL taxonomies for each filer and the queries used to extract data.
• The application is not intended for analysis, it is intended to show what is needed in order to make an analysis application workable.
• The application is not a demo of the nifty features of Excel, it is a demo of extracting and using information on the Internet.

How to use the prototype

To use the prototype:

1. Download the ZIP file.
2. Open the ZIP file and then open the Excel spreadsheet.
3. On the "Analysis" spreadsheet, click on the button in the upper left hand corner.
4. Work through the form which comes up left-to-right.  It is pretty easy and it is hard to do things out of order.
5. Watch the Excel spreadsheet, that is where the information extracted is put.
6. Think about what is making this application work and what you might need within your systems to make then work as you need them to work (meta data, taxonomies, etc).

If you know now to write Excel VBA (macros), you can go even further...modify the application.  The application has a lot of good code examples which help you understand how to get at the information within an XML file or within an XBRL file without an XBRL processor.  Reverse engineering is a great way to learn!

I would challenge you to make the appliation work better.

How the prototype works

The application uses a number of XML files to pull information together which is then viewed within the application.  Here is a summary of these files:

• List of entities: First, you need some list of entities.  The list of entities in this application comes from the XBRL Cloud feed of SEC filings.  I read that list, grabbed the filings that I wanted to use, and publish my list of entities and related SEC filings here, which is the entity information used by this application.  This is the XML file.
• List of industries: Because the number of entities is so large, it helps to categories the entities into smaller more manageable groups.  This is done using SIC codes. Rather than having a human have to read the list like many publish this information; I republished the list of SIC codes in an XML file which I can read.
• List of queries: You want to be able to query the data in XBRL filings.  I am using a standard form for providing the list of fact values to grab: XBRL. I simply create an XBRL presentation linkbase which contains the concepts I want to analyze and then read that taxonomy to get the information I want to analyze.  Here is an XML file which contains the list of queries I created for the prototype. Here is one of the XML representations of the network relations. (Note that the XBRL taxonomy is pre-processed into an easier to query resolved set of relations.)
• XBRL instances: Of course, you want the filed information, that comes from the XBRL instances filed with the SEC.  Here is one of those.  The entity list above points to the filings of each SEC filer, that is how they are found within the SEC EDGAR system.
• Filer XBRL taxonomies: The filer XBRL taxonomies which you can see in the prototype are the filed taxonomies, pre-processed so they can be easily read by the Excel application without the use of an XBRL processor.  You can see one of those here.

The Excel interface simply pulls all this information together.  What the application can do is limited because it does not use an XBRL processor. Or rather, better said...an XBRL processor would make it far easier to make the Excel application do useful functions.  But as you can imagine, none of this happens by magic.  The application is driven by data provided to it. If the application has the data, such as the SIC codes to categorize entities into groups, the application can make use of that data to help the user.

Video of application

Here is a short video which shows the basics of using this Excel based application.

The XBRL filings of SEC companies provides insight into why an information model is important. Consider this one presentation linkbase from the US GAAP Taxonomy: Statement of Income. If you click on that link and look at the page, you will notice that the presentation network of the income statement starts off something like this:

Income Statement [Abstract]             {ID1}

Statement [Table]                       {ID2}

Statement, Scenario [Axis]  {ID3}

Statement [Line Items]       {ID5}

You can click on the page and get to that presentation arrangement by collapsing or expanding the line items of that network. The IDs on the right just help you see which nodes I want you to focus on.

Why is the income statement organized in this manner, as a [Table]?  Well, there are two primary reasons reasons.  The first reason is that an income statement have a number of dimensions, for example it could be actual or budgeted, it could be for a consolidated group or for a subsidiary, or there are other breakdowns or "dimensions" which could be provided.  Those dimensions can be expressed using the "Statement, Scenario [Axis]" and the facts for which values are expressed are provided within the "Statement [Line Items]".  The second reason this [Table] is organized in this manner is because the US GAAP Taxonomy Architecture says that all [Table]s are to be organized in this manner (see the US GAAP Taxonomy Architecture, section 4.5 Implementation of Tables, page 34).

In fact, it is not that just this one [Table] is organized in this manner, ALL [Table]s in the US GAAP Taxonomy are organized in this manner.

However, look at the following sample of XBRL filings to the SEC:

http://www.xbrlsite.com/demos/console/TreeView-0001047469-09-007400.html#ID1([Table], [Axis], and [Line Items] used just like US GAAP Taxonomy)

http://www.xbrlsite.com/demos/console/TreeView-0000950123-09-030335.html#ID505 ([Table], [Axis], and [Line Items] used just like US GAAP Taxonomy)

http://www.xbrlsite.com/demos/console/TreeView-0000950123-09-029921.html(Table on balance sheet just like US GAAP Taxonomy, but no Axis on the income statement)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-046329.html#ID1 (No table, no axis, no line items)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-048234.html#ID50 (No table, no axis, does have line items, but not modeled using [Line Items] marker)

http://www.xbrlsite.com/demos/console/TreeView-0001310243-09-000085.html#ID1 (Table, line items, but no axis)

http://www.xbrlsite.com/demos/console/TreeView-0000004904-09-000117.html#ID1 (No table at all)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-047977.html#ID1 (Line items, but no table or axis)

http://www.xbrlsite.com/demos/console/TreeView-0001104659-09-046313.html (No table, no axis, no line items)

http://www.xbrlsite.com/demos/console/TreeView-0000037748-09-000037.html (Table and line items, but no axis)

Why the inconsistency between the filings?  Why the inconsistency between the filings and the US GAAP Taxonomy?  The reason is that no "model" is being enforced as to how, in this case SEC filers, create their extension taxonomies.  There is no "information model" or manner specified to construct this component of the XBRL taxonomy and no automated validation to ensure that the model is being followed.

An articulated information model achieves many things, not just consistency within an XBRL taxonomy or between a base XBRL taxonomy such as the US GAAP Taxonomy and those who extend that taxonomy.

• The first benefit is that if the information model is articulated (specified) then automated validation processes can be created in order to help those creating extension taxonomies to do so in accordance with the intentions of the creators of the taxonomy which is being extended.
• The second benefit is that because of the consistency, rendering of the XBRL instance information is easier because the XBRL taxonomy is more consistent (both the base taxonomy such as the US GAAP Taxonomy and the extension taxonomies created by in this case SEC filers).
• The third benefit is that the entire process of extending can be vastly easier for users of the taxonomy.  The automated validation is only the first step.  Literally, software applications can be built in a totally different manner BECAUSE OF THE KNOWN CONSISTENCY!  Business users tend to miss this point.  Literally, the entire notion of a [Table] can be hidden from the user because software applications can be constructed to leverage the consistency, hiding the complexity of working with an XBRL taxonomy from the user.

The third benefit about is by far the most important, but it is only achieved if you also have the first two: the consistency of an articulated information model.  This points out another challenge working with the US GAAP Taxonomy: when is something a [Table]?  This problem can be easily overcome by doing what the creators of the COREP taxonomy did: make EVERYTHING a [Table].  Now, the COREP taxonomy does not call them [Table]s, they use the XBRL term hypercube. But, everything within the COREP taxonomy is constructed in one very easly to explain and leverage information model.

BOTTOM LINE

The bottom line here is this. If you articulate an information model, meaning a formal set of rules as to how that taxonomy is to be constructed, then those rules can be used to ensure that your taxonomy was created consistently and to ensure that those extending your taxonomy do so consistently. The consistency can be taken even further making using the taxonomy significantly easier if every area of the taxonomy is created in the same manner, in this case we are using [Table]s but actually [Table]s are a way to implement the multidimensional model.  If, say, every component of the taxonomy works in a similar manner, that similarity can be leveraged by software creators to make the experience of using that taxonomy easier, significantly easier in many cases.

There are a number of other entries on this blog which discuss the notion of an information model.  Also, you can read more about this in my book which will be available next month, XBRL for Dummies.