Digital Financial Reporting

First off, before you jump to conclusions, this blog post is not about making any sort of judgment about what should be comparable and what should not.  That is for the financial reporting supply chain to figure out. This blog post shows the moving pieces of comparability and how to move those moving pieces should comparability be desired.

There are two set of prototype financial statements which I have created to work with, explore, test, and otherwise figure out how comparability works in XBRL.  Here are those two sets:

• Comprehensive example comparison: This prototype compares three financial statement-type XBRL instances which are constructed following the Business Reporting Logical Model (BRLM). This prototype is unconstrained by the idiosyncrasies of the US GAAP Taxonomy or SEC XBRL filing rules. Because I was able to create my own GAAP taxonomy, I could created it how I wanted to create it, maximizing comparability. This example shows the best comparability and how to achieve it, unconstrained by others.
• Reference implementation of SEC XBRL filing comparison: This prototype compares three SEC XBRL filings.  Each is a legal SEC XBRL filing as each uses the US GAAP Taxonomy and passes Edgar Filer Manual (EFM) validation, for the most part. Some things are intentionally done to make some specific points about comparability.

Moving parts of comparability

So what are the moving parts of comparability? When you think about comparability you need to think like a computer because it is the computer which leverages the "stuff" you provide to perform any comparisons. That stuff can take three forms: XBRL instance, XBRL taxonomy, other external stuff. Let us now look at those three pieces. (The Business Reporting Logical Model explains many of the terms used below. Section 4.3 of this document reconciles many of these terms to the US GAAP/SEC terminology used.)

• XBRL instance: The XBRL instance has all the fact values and meta data values which gives contexts to the fact values which you want to compare. Meta data values provide contexts for the fact values.  The fact values are the values.  For example, say you have a value "1000". The fact value is the value, plus the collection of measures which describe the value such as the concept which might be "Cash", the period which might be "December 31, 2010", the legal entity which might be "ABC Company", etc.  A fact value also has attributes which provide additional information such as the currency of the value which might be US Dollars or Euros (called units) and the rounding information of the value (called decimals).
• XBRL taxonomy: The XBRL instance contains all the fact values, the XBRL taxonomies defines much, but not all, of the meta data used by the XBRL instances. XBRL taxonomies do not define the periods which can be used, the entity identifies which can be used, the currencies or other units, or the rounding values; those are defined by the XBRL instance and unconstrained. But the taxonomy defines everything else including: networks (some people call these extended links but that term is actually incorrect, network is the correct term), hypercubes (called [Table]s in the US GAAP taxonomy, dimensions (called [Axis] in the US GAAP taxonomy), concepts (called [Line Items] many times in the US GAAP taxonomy), and values for dimensions/[Axis] which are called members (called [Member]s in the US GAAP taxonomy.  A special type of member is the domain (called [Domain] in the US GAAP Taxonomy.
• Other stuff: Other stuff, external to XBRL, is important to understand because you do need it and there are no standards for this as it is beyond the scope of XBRL, but these things are still needed.  One example of other stuff is some way for a computer to find the set of XBRL instances you want to work with, such as an RSS feed. The SEC created an RSS feed to provide links to XBRL instances. If you look at my comparisons, I followed the SEC lead and used RSS as the format for providing my list of files.  Others have their way of getting a computer application to a set of XBRL instances you will want to compare. Another thing you will need is a way to map meta data defined multiple times by different filers to indicate that it is the same. Other types of mappings are used to overcome meta data issues.  You will understand this better after the discussion we will have next.

So those are the moving pieces. Again, keep in the back of your mind that you need to consider how a computer deals with all these moving parts, not how a human deals with them.  The whole point here is to automate the process and avoid using human effort where possible.

Working with the moving parts

Now we look at some examples of working with the moving parts and how comparability is impacted. Differences may seem subtle, and they are.  But it is these nuances which make comparability work or not work. We will walk through this from the top down.

• Defining networks: Networks, which many people refer to as extended links or groups, is one tool which can be used to achieve comparability at the highest levels.  For example if you tell the computer you want to compare balance sheets, you can give it the network name for the balance sheet and grab that from each XBRL filing which you want to compare.  For example consider this network, this network and this network of ABC Company, XYZ Company, and QQQ Company of the reference implementation above. Not that they are all the same, "Network: 104000 - Statement - Statement of Financial Position, Classified (http://xbrl.us/us-gaap/role/statement/StatementOfFinancialPositionClassified)" from the US GAAP Taxonomy.  Well, that is actually illegal per SEC XBRL filing rules.  Each filer is required to define their own networks.  As such, networks are not helpful in comparing balance sheets or any other pieces of SEC XBRL filings because every network of every filer is unique for everything! By contrast, the vast majority of the networks of the comprehensive example comparison are the same. So, to improve comparability; define networks so they can be shared between filers which improves comparability.
• Defining hypercubes or [Table]s: Drilling deeper into XBRL taxonomy models the next highest level we run into after the network is the hypercube or [Table] in the US GAAP Taxonomy. Looking at the same portion of the taxonomies of ABC, XYZ and QQQ companies, the balance sheet, let us look at them another way; via the [Table] rather than the Network. If you check out the three links you will see that each is to a [Table] with the label "Statement of Financial Condition, Classified [Table]".  Now, look a little more closely and notice that the concepts are actually different, the are NOT the same.  Each company defined their own concept for the balance sheet table.  How will a computer understand that each of these are the balance sheet?  Well, it will not. By contrast look at this [Table] which is the same for ABC, XYZ, and QQQ. All three use the concept from the US GAAP taxonomy "us-gaap:Nonmonetary Transaction, by Type [Table]". Now, this is easy for a computer to understand to be the same [Table] so it can easily be retrieved and compared from all three prototype SEC XBRL flilings.
• Defining dimensions of [Axis]: OK, now go back to taxonomies of ABC, XYZ and QQQ companies and this time focus on the [Axis] of the Nonmonetary Transaction, by Type [Table].  Notice that the [Axis] "Report Date [Axis]" is defined by each company individually which can be seen by the different namespace prefixes abc, xyz, and qqq in each taxonomy.  By contrast, look at the "Nonmonetary Transaction Type [Axis]" which has the "us-gaap" namespace in each taxonomy, so that is the same [Axis] in each.  Again, the same helps comparability, different hinders comparability.  Now, analysts can create a mapping which tells the computer that they are the same, but that takes humans to do work which takes time and costs money.
• Defining domains: You get the general idea, so I will not repeat this for the [Domain], basically if the [Domain]s are defined in the US GAAP Taxonomy they are more comparable than ones defined in the individual company extension taxonomies.
• Defining members: Same deal for [Member]s.
• Defining concepts or [Line Items]: Same deal for [Line Items].
• Defining units: It is worth pointing out how units works a little differently.  Imagine every individual company having to define their own units, such as "USD" for US Dollars.  Not good. If each GAAP taxonomy, US and IFRS, defined the units then cross taxonomy comparisons are harder, mapping would be involved.  XBRL defined the attribute "units", so that can be shared between taxonomies, in fact, it must be as it is required on all numeric facts. Even better, XBRL actually relied on the ISO standards, specifically ISO 4217 which defined currency codes, such as the code for US Dollars "iso4217:USD" which is the global standard for specifying what currency something relates to.

So who defines the information/meta data has significant impact on comparability as you can see. Global standards such as ISO codes enable the most comparability. Things defined by XBRL itself are slightly less comparable. Next are things defined by a US GAAP Taxonomy.  Last are things defined by individual filers. Experiment with the two comparison prototypes above and see how they work in software applications. You can learn even more about the nuances of working with XBRL to create the comparability which you desire.

Impact of financial integrity on comparability

Financial integrity has a big impact on comparability. For example, if there is no agreed upon foundational definition of a balance sheet, income statement, statement of changes in equity, cash flow statement then those creating analytical software have to create one and normalize every different financial statement created by each individual SEC filer in order to create comparability.  That means two things: (1) Different analysts or data aggregators can create different definitions of the foundational definition of statements and (2) It is so complex to get data out of the many different filings that you will have to go through some data aggregator to get useful data.

But what if there were an agreed upon foundational definition of financial statements, certain policies, and certain disclosures? Then, querying the information at the highest levels would be quite easy.  At the lower levels, individual filers still have the flexibility to show the information they want to show but there is at least some basis for comparing.  Another way to say this is that computers don't do to well with random.

Conclusions

Try comparing the information in the two sets of XBRL instances above.  The results you get from the "comprehensive example" comparison will be better than the "reference implementation" comparison. That is because the comprehensive example was built to be comparable.  The reference implementation was constructed to communicate some comparability issues and had to follow the US GAAP Taxonomy and SEC XBRL filing rules.

Comparability is not an art, it is pure science and testing comparability is quite objective. Some financial reporting supply chain deciding WHAT will be comparable is an art and is quite subjective and political. Whatever the supply chain might decide can be expressed in XBRL. Understanding how to use the XBRL medium helps one use the features of the XBRL medium far better than leaving things to chance.

Again, this blog post deals with the science of comparability, not the art of what should be or should not be disclosed. That is a different discussion.