« The IBM Aircraft Carrier Has Turned! | Main | Overcoming "Metadata Ignorance", Achieving Semantic Interoperability »

Disclosure Objects: Missing Layer in US GAAP Taxonomy?

Last week it occurred to me that there seemed to be a missing piece of metadata in the US GAAP taxonomy and SEC XBRL financial filings.  I posted a message to the XBRL-dev mailing list, Perhaps a Missing "Layer" in US GAAP/SEC Semantics, and there pretty good discussion about this.

All this came up as a result of my creating a prototype which joined together a number of things which had been disjointed in the past.  You can see that prototype here:

http://www.xbrlsite.com/2012/Templates/2012-04-15/Library/Viewer.html

The primary clue that something was missing is the fact that in SEC XBRL financial filings, information is reported twice: (1) as a chunk of HTML information within one fact such as within a [Text Block], (2) detailed or more granularly within a number of facts.

Interestingly, not all information is reported twice; the primary financial statements don't have the chunks of HTML provided. Not sure why the primary financial statements are treated differently.

Another important point about this situation is that the terminology used by they US GAAP Taxonomy and by the SEC EFM are different. Not sure why, but the US GAAP Taxonomy uses the terms "[Text Block]" for the chunk and "[Table]" for the detail. Whereas, the SEC EFM uses the term "table" for the chunk of HTML and the term "detail" for what the US GAAP taxonomy calls a [Table]. Don't really know why this is, seems like using the same terminology in the US GAAP taxonomy and in SEC filings would be a good thing.

Now, these "chunks" and the "detailed" or granular information is not connected in any way.  You don't know which two pieces represent the same information, one reported as a chunk and one reporting the details.  This is unfortunate. It is not that someone can go and manually articulate the connection.  That is possible, in fact that is exactly what I did in my prototype.  And that is why I can connect all these pieces together.  That connection is the missing piece of metadata which I am now referring to as a "disclosure object".

Let me give you a few examples from the US GAAP Taxonomy and point out the important ramifications. Here are a few examples. These two report elements have the same base label/name:

  • Accelerated Share Repurchases [Table] (us-gaap:AcceleratedShareRepurchasesTable)
  • Accelerated Share Repurchases [Table Text Block] (us-gaap:AcceleratedShareRepurchasesTextBlock)


There are a number of [Table]s and [Text Block]s which do NOT have the same base label/name, such as these:

  • Schedule of Held-to-maturity Securities [Table] (us-gaap:ScheduleOfHeldToMaturitySecuritiesTable)
  • Held-to-maturity Securities [Table Text Block] (us-gaap:HeldToMaturitySecuritiesTextBlock)

There are others that have more differing labels/names.  But, what is more troubling is that the documentation of the [Table] and [Text Block] are different, other than simply the difference between the granularity provided.  Why would the accounting meaning of the report elements be different?

Further, there are many, many disclosures for which there is not both a report element for the "chunk" and another set of report elements for the "details".  It seems there should be a 100% correlation between the two.

Finally, while what SEC filers are required to disclose is one thing.  How those disclosures are organized into a set of notes to the financial statements is a different thing.  SEC filers do have flexibility as to exactly how they disclose many things which they are required to disclose.  But the disclosure itself is more like an on and off switch; if the filer has certain characteristics then they are required to provide the disclosure.  All this is outlined in a disclosure checklist.

Again, exactly how the disclosure is made and where the disclosure is placed in the notes (or presented on the face of the financial statements) offeres many different permultatoins/combinations.  But the disclosure itself is a different notion.  For example, an SEC filer is required to provide a balance sheet.  That balance sheet is required to be a classified balance sheet, unless the filer is in an industry or has activities which require or allow an unclassified balance sheet.  What line items show up on the balance sheet is driven by the characteristics of the filer.  So, the disclosure is the balance sheet itself.

A "balance sheet" is the disclosure.  A balance sheet is something referred to in the conceptual framework the FASB makes available and in the Accounting Standards Codification (ASC). A balance sheet can take a number of forms: classified, unclassified, and different industries/activities construct balance sheets in different ways. But, all of these things are balance sheets and they all have characteristics which are identical: they all have assets, they all have liabilities and equity.  Assets, liabilities, and equity are all things referred to by the FASB conceptual framework.  Equity might take different forms: stockholders' equity, partner capital, owner's equity, member equity.  But, all those forms are equity.

So since the US GAAP Taxonomy is not providing this layer, someone needs to create it in order to wire things together correctly.

Take a good look at the prototype, you will see what I am trying to describe. Be sure to check out the Excel-based Disclosure Object browser.  This helps you see a few interesting things which  I will describe later, so stay tuned!

Special thanks to XBRL Cloud for making their web service, which offers easy to use logical models, available to me to create this prototype.

Posted on Wednesday, April 25, 2012 at 09:38AM by Registered CommenterCharlie in | Comments2 Comments

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (2)

I agree with these points:
us-gaap should improve the correlation of a Table (hypercube) for every Text Block (textBlockItemType meant to tag a table; naming convention [Table Text Block])
us-gaap should better sync corresponding Table and [Table Text Block] definitions - hey, how about re-using the same documentation label resource?
It is not so easy to sync up or re-use the element IDs, and (<sarcasm>thanks to LC3</sarcasm>) not easy to sync the standard Labels
SEC and us-gaap should use the same nomenclature (Detail versus [Table] and Table versus [Table Text Block]). And let's use plain English wherever possible, too!

I don't understand this:
"Now, these "chunks" and the "detailed" or granular information is not connected in any way. You don't know which two pieces represent the same information"

And you suggest your prototypes will clearly demonstrate how they can be connected; I'm not sure what you mean specifically, do you mean that Tables and Text Blocks are two (separate) links listed on the same "template"? (seen specifically in the Organization group, number 1, Variable Interest Entities prototype example)? I presume that's what you're talking about. I think that's a great way to demonstrate how these things correspond and "mean the same thing". But I argue us-gaap could (and does, in some cases) achieve the same by grouping the [Table Text Block] element and its corresponding [Table] hypercube, in the same report.

So my takeaway is that your approach is similar to an approach that is achievable in XBRL today, and I like both approaches for understanding how data "means the same thing"

So my main complaint is that the EFM recommends a different approach; because Level 3 and Level 4, which correspond roughly to (Tables) and (Details), aka [Table Text Block] and [Table] (hypercube), should be separate reports!

(A strict interpretation of EFM rule 6.7.12 precludes the [Table Text Block] (Level 3) and the corresponding Detail elements (Level 4) from being included in the same report. I think this is a silly approach. Would you agree?)
April 25, 2012 | Unregistered CommenterNate
Thanks nice information....
April 25, 2012 | Unregistered Commenterzaraward

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.