Digital Financial Reporting

The screen shot below shows a visual representation of the fact tables of two XBRL instances/XBRL taxonomies. 

The top fact table representation comes from the XBRL instance/XBRL taxonomy example in the business use case "Classes" and models the components of PPE as the [Member]s of an [Axis] (using US GAAP taxonomy lingo) or dimensions of one primary item (using XBRL Dimensions lingo).

The bottom fact table representation comes from the XBRL instance/XBRL taxonomy example in the business use cases "Simple Roll Up" and models the components of PPE as concepts within a set of [Line Items] (using US GAAP taxonomy lingo) or primary items (using XBRL Dimensions lingo).

Are the two facts which express the fact value of "Land" semantically equivalent?

You probably answered "YES".  That is the answer which I would have given.  While syntactically the two facts are modeled using different approaches; semantically they say the same thing. (If you don't agree that the answer is YES, I would enjoy hearing your rational.)

So, if they are semantically equivalent; can you just take the fact in line #1 on the top fact table out and replace it with #11 from the bottom fact table?  Of course you cannot because the modeling approach of the top fact table and the modeling approach of the bottom fact table are different.

Neither modeling approach is wrong.  However, approaches must not be arbitrarily mixed.

Yet this is a common mistake in modeling SEC XBRL financial filings which I have seen.  One of the areas where this appears the most is the modeling of classes of preferred and common stock.  Mixing these approaches causes things like balance sheets which do not balance.

Something which this brings up is how do you know whichmodeling approach to use? That is a good question.  Sometimes you don't really have a choice because if you are either extending an existing model or fitting another piece into some other model you need to fit your modeling into that existing model.  Other times there is no clear answer.  For example, in the US GAAP taxonomy sometimes both approaches are modeled and it can be confusing which to use if there are no other constraints to consider.

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.