Digital Financial Reporting

In 1998 I created a prototypeof what was to become XBRL.  Since that time I have created more XML using my favorite application as I say, Microsoft Notepad (actually I prefer Ultra Edit), than I actually care to think about.  I still have a copy of that prototype.

There probably will not be many takers, but for those who like details, here is a deep dive into XBRL. I took the summary pages I worked with and organized them in one spot to make them easier to find. Here is that list:

• Really Early Stuff (2000 to 2005). 2005-12-31
• Early Stuff. 2007-01-01
• XBRLS Era. 2008-04-15
• Differences Between XBRL, RDF, XML, iXBRL, XHTML. 2010-01-15
• Business Reporting Logical Model. 2010-08-01
• Business Reporting Logical Model applied to SEC XBRL Financial Filings. 2010-09-30
• Semantic Model on top of Business Reporting Logical Model. 2011-04-11

The end result of all this is summarized in the document Understanding SEC XBRL Financial Filings. There are two other summaries.  The FRUX book and XBRL for Dummies.

In my popular video How XBRL Works (pushing 12,000 views) I did my best to explain three important notions needed to properly understand XBRL.  This is a better articulation of that information. Watching the video can also be helpful in gaining a better understanding of these important key terms. If you don't have a proper understanding of these terms, it is doubtful that you have a proper understanding of XBRL.

Unstructured versus structured information

Digital information comes in two forms:

• Unstructured which means the information contains no identifiable structure and therefore it is unrecognizable and therefore not usable by computer software. Further, no controlled navigation within the pieces of the unstructured information is possible due it its lack of structure.
• Structured which means the information has identifiable structure which can be recognized and utilized by computer software. Further, because of the structure navigation within the pieces of structured information is possible because of the structure.

Truth be known, everything that a computer works with has to be structured at some level and the level of structure determines what a computer can do with that digital information.

Structured for presentation versus structured for meaning

There are two approaches to structuring information digitally:

• Structure for presentation. An example of that is a Word processor document which is structured using headings, sub headings, paragraphs, tables and lists. An Excel spreadsheet is also an example of structuring for presentation, it uses worksheets, columns, rows, and cells.
• Structure for meaning.  An example of that is database or a taxonomy or other type of classification system. A database structures the presentation into rows and columns, but the rows and columns are associated with defined names which have specific meaning.

Syntax versus semantics

More often confused are the two parts of structured information.  Both parts are important, but for different reasons:

• Syntax describes the form of the information and is generally not relevant to a business person. This is syntax: <Name>John Doe</Name>. Syntax is important to technical people.
• Semantics communicates the meaning of the information. For example, "the balance sheet balances" is semantics. Business meaning is key to the digital world.

Interoperability = Business benefits

What does all this mean to you?  More than you might think. Properly weaving business systems together provides significant business benefits. For example, SAP says in this article that its customers have sharply cut costs of creating regulatory reports by 75 percent. If you are not experiencing that magnitude of benefit you may be confusing some of these terms.

As his video about HL7 points out (see slide 4) you need three things to create useable business system interoperability:

• Technical interoperability is concerned with the conveyance of payload. This is syntax, what physically gets transferred.
• Semantic interoperability communicates meaning unambiguously. Semantics are domain specific. The business systems on both sides of the transfer need to have the same understanding of the meaning for the transfer to work effectively.
• Process interoperability enables shared human understanding that is needed to coordinate work processes and enable business systems to interoperate. Basically, the work flow needs to be understood.

Think "Semantic Spreadsheet"

This short 6 minute video helps you see the world differently (the first video, "Basics of Quantrix Modeler"). In the video the narrator makes up the terms used in his matrix, "Net Income", "Revenue", "Expenses". For financial reporting use of that semantic spreadsheet or what the narrator calls a "matrix", you would generally not create the concepts used yourself; you would generally pick most of them from the US GAAP or IFRS taxonomy.

Evolution

We are not there yet.  Business software is not what it needs to be. For example business intelligence software is too focused on OLAP, it does not handle text well preferring to work with numbers, and it is "read only", you cannot write information back to the database generally.  The US GAAP Taxonomy is modeled like a the documents accountants are used to, not like the data model that it should be. Each implementation of the XBRL standard is unique to that implementation, for example the SEC and FDIC implementations of XBRL don't interoperate.

All these issues will be worked out over time. Don't make the mistake of confusing the moving pieces to this puzzle.  The better you understand the moving pieces, the fewer mistakes you will make in working with new technologies such as XBRL.

I have been trying to articulate the benefits of unique, explicit [Table]s in the US GAAP Taxonomy for quite sometime. In trying to figure something else out I stumbled across a paperwhich helps communicate why unique, explicitly [Table]s are superior to [Table]s which are not unique and [Table]s which are implicit.

First off, let me explain what I mean by unique [Table]s and by explicit [Table]s.

A good example of a non-unique [Table] is the "Statement [Table]" which appears in the US GAAP taxonomy.  What does the "Statement [Table]" represent?  Well, it represents many things and that is the underlying problem. It could represent a balance sheet, an income statement, a cash flow statement or actually anything because some vendors are using "Statement [Table]" to express every [Table]. So, what I mean by unique [Table]s is exactly the opposite and exactly as it sounds.  Just like concepts or other things in the US GAAP Taxonomy each [Table] has ONE meaning, one name.  Rather than using "Statement [Table]" to identify multiple things, each [Table] is specific: Balance Sheet [Table], Income Statement [Table], Cash Flow Statement [Table], and so forth.

By explicit [Table]s I mean that there are no implicit [Table]s.  What I mean by that is that today, everything exists in a "[Table]" in the US GAAP taxonomy.  And of course you will say, "No, that is clearly not correct, one can cleary see that is not the case." But, this is exactly my point.  True, you can't "see" the [Table], but it is there.  What I mean is that after you address all the explicit tables identified by the XBRL hypercubes marked with a "... [Table]" in the label and name, you have one more table which implicitly exits.  Basically, it is the "everything else [Table]" which has no name.  It has two [Axis], the "Reporting Entity [Axis]" which is instantiated using the XBRL syntax "entity identifier" portion of a context and the "Period [Axis]" which is articulated using the XBRL syntax "period" portion of a context.

Don't make the mistake of confusing syntax and semantics. Just because it is called part of the XBRL context does not mean that from a business perspective that it is not an [Axis].  First off, be aware that ALL [Axis], be they XBRL Dimensions defined or XBRL 2.1 defined, are expressed using part of an XBRL context element.

So, what I am saying here is rather than modeling things to show up under the "unnamed [Table]" implicitly, it is better to be explicit and define the [Table].  Further, having multiple "unamed [Table]"s violates the first notion of making every [Table] unique.

"Why?", you ask.  Here is why. Navigation and use of the taxonomy and the SEC XBRL filings is superior if [Table]s are unique and explicitly defined because navigation within the pieces of the taxonomy and/or SEC XBRL filings because of the unique "handles" of the [Table]s.

If [Table]s are unique, you dont also have to use the network to uniquely identify WHICH of the non-unique [Table]s you mean should you be trying to tell a computer software application which of the non-unique [Table]s you desire to use.  Further, there is no need to ask what defines the [Table], the hypercube which defines the table with the "... [Table]" label/name on the end or the set of [Line Items] which make up the [Table].  You will not have that question because every [Table] is unique and you will never run across that situation.

Computers need these unique handles to understand exactly what you desire. Unique, explicit [Table]s provide the handles needed to control navigation between pieces of a taxonomy or SEC XBRL financial filing.  Without unique [Table]s, there is no way you can get around using network information to create unique handles.

If you need more details please read the paper. It is quite technical, but it lays all of this out quite nicely.

This document summarizes information which contributes to resolving four significant areas of confusion within SEC XBRL filings. I have provided for each area of confusion facts and evidence which is helpful in trying to figure each of these issues out. I am doing the best that I can to get formal resolution of these issues.

These four areas of confustion were first brought to light on this blog post. Subsequent to that I created a number of what I call exemplars which clearly articulate the issues and resolutions to the issues. I have shared this information with a number of others who have provided feedback which I have incorporated into this document. You can also get to these same exemplars here.

I would encourage others to provide me any feedback they might have which will help resolve these issues consistently across all SEC XBRL financial filings. Alternatively or in addition, I would encourage you to communicate your views to the FASB and XBRL US. The SEC does not seem like they will provide guidance on this type of issue any time soon, but you may want to point out your view to them also.

A greatly updated/enhanced US GAAP Taxonomy Exemplar/Component viewer is available to dink around with. There are lots of things to check out including:

• View the US GAAP taxonomy components by accounting standards codification.
• A sample/prototype applicationfor showing you how to grab pieces of the US GAAP taxonomy within a software application. (NOTE: This is an Excel spreadsheet which contains macros.)
• Remember the Four Areas of Confusion I pointed out.  Here are exemplars which show you options for modeling those pieces of an SEC XBRL filing.
• Connected the XBRL Techniques and Trends Prototypes to this prototype so they are easier to find.
• Broke the larger pieces of the US GAAP Taxonomy into physically smaller pieces to make focusing on a piece easier.
• Renamed the RDF files to be consistent with the terminology used elsewhere.
• Other enhancements.

It is helpful to read this blog post to understand the components I see and to better understand my prototype.

So what is the point of all this?  Well, there are four primary points:

1. Possibilities. This is what using the US GAAP Taxonomy COULD be like. I admit I am not a very good programmer, but I think I am showing some things which could be quite useful to business users.
2. An approach. You cannot easily automatically reorganize the US GAAP Taxonomy as it stands today like I can construct reorganizations.  The reason is that I put in a lot of manual effort to put the consistency into my reorganized version of the US GAAP taxonomy which I needed in order to provide these reorganizations.  If you find these types of organizations useful and feel constrained by the current US GAAP Taxonomy organization, point this out to the FASB.  Ask them to be more explicitly and more consistent.
3. Meta data.  I have added only some meta data to the taxonomy using RDF.  Eventually others will realize the possibilities here.  What can be added is endless really. This meta data will make things even easier.
4. Maintenance.  I contend that maintenance required of software vendors, and the FASB for that matter, when it comes to periodic updates of the US GAAP Taxonomy is made easier by more consistency and explicitness in the taxonomy.

Keep in mind that these ideas are not limited to the US GAAP Taxonomy but are rather practices which will serve any taxonomy one might desire to create.