Digital Financial Reporting

In a previous post I mention how metadata will reduce costs.  Metadata also increases functionality.

I put together a prototype system which provides information about SEC financial filings filed with the SEC. The prototype uses a set of 291 public company 10-K filings which I was analyzing (i.e. it does NOT contain all of the approximately 8,000 public companies which report to the SEC, only 291).  The system uses:

• SEC XBRL financial filing information
• Metadata and infosets provided by XBRL Cloud
• Metadata provide by StockSmart
• Metadata which I added to the system

The prototype information system is basically a Microsoft SQL Server database. MS SQL has an XML data type. There is ZERO XBRL being used by this system.  All the information was grabbed from the SEC XBRL financial filings, processed into easier to use infosets, the infosets are organized and stored in the MS SQL database (rather than the XBRL).

In my view, this is how people will work with financial information reported using XBRL.  Imagine how long it would take for something like the following query to execute:

"Go to each SEC XBRL filing (in the set of 291 filings), get Assets, liabilities and equity, equity, net income (loss), net cash flow, revenues, income (loss) from continuing operations, income tax expense (benefit), current assets, and current liabilities for each of those filings."

Downloading the 291 files in order to read the information with even good bandwidth would take quite some time.  But, click on this link and you can see how long it takes the database to return that information.  (From my computer it takes about 5 seconds)

You can fiddle around with all the XML (machine readable, try using Excel) and HTML (human readable) pages I made available.  But let me walk you through a few things so that you can see the power of metadata.

• Grouping by industry:  Here is a list of core financial information from the 291 filings.  Want to group that information by industry?  Well, to do that you first have to have a set of industries.  Here are three industry groupings which I have: (a) SIC Codes, but those tend to be too granular for my needs; (b) Industry/sectors, that is not too bad a list; (c) Subindustrys, this is someone else's list and not necessarily a "standard" list.  In fact, who has the "standard list" of industries? Don't know that there even is one.  But, in order to group information by industry, you have to pick some list and make sure each entity is mapped to that list.  Here is a list of entities which has been mapped to all three of those lists.  I picked "(b)" which allows me to group the entities, and generate this grouping by industry.
• Comparing balance sheets: Seems like a simple thing, you want to compare the model structure of each of the 291 filings and see how each modeled the balance sheet.  Easy enough.  Or is it?  Well, take a look at the networks used to identify the balance sheet for each of the 291 filings.  What you notice is that each network identifier is different, each network label is different.  If you look further into the networks you see that "Statement [Table]" is often used to identify the balance sheet; but "Statement [Table]" also identifies the income statement, cash flow statement, statement of changes in equity, as well as many other things.  Or, filers don't model the balance sheet in the form of a [Table] at all.  So, how do you find the balance sheet for a filing?  Well, what I did was map a disclosure object name "BalanceSheet" (see #1 on this list) to each of the networks which contained the balance sheet. You can see that here. Doing that made it possible for me to compare the model structures of the balance sheet for each of the 291 filings which you can see here. (Or you can compare them using this web page also.)
• Verification summary by generator and by auditor: XBRL Cloud gets the name of the software used to generate SEC XBRL financial filings.  I can grab that from the XBRL Cloud Edgar Dashboard RSS feed.  I entered the name of the auditor for the 291 filings in my test set.  This dashboard allows you to compare the results of entities submitting SEC XBRL financial reports, similar to the XBRL Cloud EDGAR dashboard, but focused more on financial reporting semantics.  The XBRL Cloud Edgar Dashboard allows you to filter by reporting entity.  I let you filter by generator and by auditor.  For example, here are all the PWC filings in my set of 291.  And here are all the filings where the WebFilings software was used. (As a side note, notice how many of the 291 filings pass all the verification tests which I established, that is actual data.  Basically, 98% of all SEC filers pass all of these tests.  I will run the complete set of tests against all 8000 filings in February or March of 2013 when all the year-end 10-Ks have been filed.)

There is a lot more that you can fiddle around with. Notice all the places where metadata is used to help you filter, find, organize, slice, dice, or otherwise work with this test set of 291 SEC XBRL financial filings.  It is even more useful when working with the complete set of SEC filings.

Cliff Shirky's article, Ontology is Overrated: Categories, Links, and Tags, takes a look at organization schemes and points out why past organization practices might not be appropriate in our increasingly digital world.

I adopted a mantra awhile back:  "The only thing better than metadata is more metadata."

Over the years I have collected metadata, did my best to figure out how to express this metadata, reorganized the metadata, read some good books about metadata, experimented with metadata, and otherwise tried to put the pieces of financial reporting metadata together that I was interested in.  Why? I believe in Tim Berners-Lee linked data vision.

Third order of order will contribute to making XBRL useful in ways most people don't even imagine at this point in time.  I have pointed out this statement by David Weinberger, author of Everything is Miscellaneous, and it is worth pointing out again:

In fact, the third-order practices that make a company's existing assets more profitable, increase customer loyalty, and seriously reduce costs are the Trojan horse of the information age. As we all get used to them, third-order practices undermine some of our most deeply ingrained ways of thinking about the world and our knowledge of it.

Here is some experimenting I have been doing.  A financial report is made up of pieces.  These pieces can be categorized: 

• Primary Financial Statements
• Organization, Consolidation, and Presentation of Financial Statements
• Significant Accounting Policies
• Financial Statement Accounts Disclosures
• Basis of Reporting
• Broad Transactional Categories Disclosures
• Industry Specific Disclosures
• Document and Entity Information
• Supplementary Information

Writing that list down on paper or using "electronic paper" like this blog is helpful.  Putting the that information into a database is even more helpful.  For example, here is that same list from a query of a relational database.  Even more useful is expressing that list using a form such as RDF/OWL which is readable by any system which speaks the language of the internet: HTTP and XML.  Here is that same list in RDF/OWL.

While that list of major categories is helpful, having the next level of information is also helpful.  The Accounting Standards Codification (ASC) calls these topics.  Here is that list of financial reporting topics from a relational database query, and again in RDF/OWL.

Drilling in a little deeper, for each topic there are a number of disclosures which reporting entities make about that topic.  I call these disclosure objects.  I have identified 1,145 disclosure objects in the US GAAP Taxonomy and SEC XBRL financial filings.  Clearly this is not a complete list, there are others.  Here is my list of disclosure objects from a relational database, and here is the same list in RDF/OWL. Note that you can filter the list of disclosure objects using the major categories and topics defined above.  See how useful metadata is? So, here is a list of the disclosure objects relating to the major category "primary financial statements" and the topic "balance sheet". And this list relates to the major category "basis of reporting" and "earnings per share".

If you look on the right side of the list, you see a link to a prototype of the disclosure object.  For example, if you go to the major category "financial statements account disclosures" and select the topic "inventory" (click here to do so), and then you click on the first item on the list which is "Inventory Disclosure" (where it says "HTML" on the right hand side, or click here) you see something which looks like the screen shot below:

If you explore that HTML page, you will see that you can get to the US GAAP Taxonomy piece which has that disclosure, a reorganized version of the US GAAP taxonomy which also has it, two viewers which let you explore SEC filings which provide that disclosure, direct links to numerous SEC filings which contain that disclosure, and a handy list of common report elements which are used to create that disclosure.

All these things are hooked together by the name of the disclosure object.

How useful is that?  There are lots of other things one can link to.  For every financial report elemental, you can get to the definition of the pieces of the disclosure, references to the accounting standards codification and other information complements of the US GAAP taxonomy.  If you have a subscription to the ASC, you can navigate directly to the FASB site.  Eventually, the FASB will recognize that they need to make the ASC available as a web service so the ASC can be used directly inside applications used to create financial reports.

All of these pieces has existed in the past, but it was impossible to hook them all together effectively because the information was in different books, physical links were therefore not possible; humans linked these things together, going to the different resources as they needed them, if they had the resource.  The internet is a web of all these resources.  Metadata hooks the pieces together.

Yesterday I posted information about a prototype comparison tool I created.

Here is another one. This comparison tool lets you select a financial report component and then an industry group.  This limits your comparison to a specific industry.

Pretty straight forward stuff, if one can figure out which components of each company which you want to compare.

Here is why this is someone challenging. In order to compare a component, you need to identify the component you wish to compare.  No problem, every SEC 10-K and 10-Q filing has a balance sheet.  But, every SEC filer identifies the balance sheet differently.  Here is a list of the balance sheet identifiers for this set of 291 SEC filings I am working with: Balance sheets.

All different.  Same for the income statement, cash flow statement, document information, significant accounting policies.

So, why is it the case that the SEC or FASB or someone could not say "To identify the balance sheet, use the network identifier 'http://fasb.org/financialReportComponents/BalanceSheet'?  Well, they could have.  Or, even better in my view, if everyone creating a balance sheet used the table "us-gaap:BalanceSheetTable".  That would work also.  In fact, that is sort of another problem, what identifies the component, the network or the [Table].

Very, very frustrating for anyone trying to use the information.  Now, you CAN figure this out.  If you read the section of the Digital Financial Reporting resource related to analysis, which you can get here, and check out the section on prototype theory; you will see that it is still possible to identify things; but it is still harder than it really needs to be if you ask me.

Perhaps there is some reason why every filer creating their own unique identifier for every single component expressed in a financial report is better.  If you know the reason why, please let me know.

I created a little SEC XBRL financial report component model stucture comparison tool prototype.

If you are an accountant, I would really like to hear from you to see if you think a tool like this has value.  The reason is that I am trying to get software vendors to build stuff like this.  Keep in mind that THIS IS A PROTOTYPE! Clearly there are a lot of other useful features such as filtering companies by industry/activity and it would be great if EVERY financial report component and EVERY reporting entity was available for comparison; however, my programming skills are limited.

This second tool allows you to look at all the SEC XBRL financial filings within the set of 291 which have the component you select, letting you compare how each of the SEC filers modeled that component. (This is another version of the second tool, less stable but has more components.)

The comparison tool works off of a database of 291 SEC XBRL 10-K financial reports which I created earlier in the year.  The idea is pretty basic: compare things.  Here I am showing a comparison of the XBRL model structure.  You could also compare the actual renderings.

Because neither the US GAAP Taxonomy nor the SEC has a defined notion of what a "component" is nor do they actually define names for these components, I had to map from the networks and tables within a submission to the components I know exist within a financial report.  A component is something like document information section, balance sheet, income statement, cash flow statement, significant accounting policies, long-term debt maturities, pension disclosure, and so forth.

Now, does it have to be the case that these components have to be individually identified so that users can actually easily do comparisons such as this? No, the FASB and/or SEC could define the notion of a component, what makes up a component, how to construct them, and even give them names so users of the information can query against the component information.

Keep in mind the difference between financial disclosure information and how that financial disclosure information is organized in the form of notes within a financial statement.  Financial disclosures are far more consistent that how filers organize those financial disclosures within a financial statement.

All this can be sorted out manually and then computers can do lots of useful things.  However, that organization is expensive.  It is far less expensive than having to go through all the HTML filings to pull out this information.

Fiddle with the comparison tool, it is useful for understanding SEC XBRL financial reports.  For example,

1. Why do these two filings construct the document information model differently, one using a [Table] and the other not using a [Table]?
2. Why does company A in this example use the document information [Axis], company B use the legal entity [Axis], and company A above does not use ANY [Axis]?
3. Here both Company A and Company B both use the document information [Axis].
4. Here you have Company A using a class of stock [Axis]; yet I would ask two question: First, don't most of those filers have classes of stock and why don't they use that [Axis]? Second, does the entity name and CIK number facts actually have a class of stock characteristic?

While the document information section of a financial report is actually one of the more consistently created components, it does help point out issues which exist with other SEC XBRL financial report components.

Thank you to XBRL Cloud who has made the XML infosets of these SEC XBRL financial filings available to me which allowed me to fairly easily create the renderings of the model structure and in mapping the networks to the components used in this comparison.