Digital Financial Reporting

The list of SEC XBRL filings which has received my 5 Star Rating has now reached 92!

You can see the list of filings receiving my 5 Star Rating below and you can go to this web page to see the detail of the analysis. (Recall that last week I posted a blog entry stating that I had found 24 SEC XBRL filings to which I could assign a 5 Star Rating.)

Criteria for Receiving a 5 Star Rating

The following is a summary of the criteria for receiving my 5 Star Rating (For more details see this blog post):

1. No XML, XBRL, or EFM syntax errors. This is indicated by having a "0" in Column 8 which is marked with "E" under "Edgar Filing Manual" on the XBRL Cloud validation report.
2. Calculation consistent.  (i.e. no calculation inconsistencies reported during XBRL validation)
3. Pass one basic business rule.  One business rule must be passed, basically checking for the existence of net cash flows and the reconciliation of the beginning and ending balance of cash.
4. [Table]s must be correctly created. The [Table] structure must follow the US GAAP Taxonomy Architecture as specified.
5. Extension concepts reasonable.  The extension concepts added must appear reasonable.  This is admittedly subjective, it would take a blatant error to be dinged for this, if everything else was satisfied.

Remember that this set of criteria is just a basic set of minimal criteria which an SEC XBRL filing should, in my view, meet at this stage of the game.  There are many other things which need to be considered in order to be considered a high quality filing.  See this blog post for more information.  This blog post relates to things accountants might need to consider.

Summary of Filings Analyzed and Analysis

The SEC XBRL filings which I analyzed were 10-K's and 10-Q's submitted between January12, 2010 and March 2, 2010.  Here is summary information about that set of filings.

• There were a total of 422 filings in this set.  Of that total, 92 received a 5 Star Rating, which is 22%.
• Of the 422 filings, 401 of them (95%) had no XML, XBRL, or EFM errors reported (criteria 1). So only 21 had these types of errors.
• Of the 422 filings, 317 of them (75%) had no calculation inconsistencies. So only 105 had calculation inconsistencies.
• Of the 422 filings, 319 of them (75%) modeled [Table]s correctly.  So only 84 had [Table] modeling issues.
• Because checking the business rules and extension concepts is labor intensive, I only checked filings which passed the other three tests for these criteria.  As such, I don't have data for the how the complete set of filings did against these two criteria.

While there were many filings doing well against one of the critera above, only 92 SEC XBRL filings did well against all 5 criteria.  Kudos to those 92 SEC XBRL filers!

Browsing These Filings

You can see the list of filings above, or you can view the filings by criteria here (these work best with a big monitor):

• Focusing on Errors
• Focusing on Calculations
• Focusing on Business Rule
• Focusing on [Table]s
• Focusing on Extension Concepts
• Filer Taxonomy
• Mashup of All Information by Filer

List of 92 SEC XBRL Filings Receiving a 5 Star Rating

This is the list of the names of companies which received my 5 Star Rating: 

• AES CORP
• Aflac Incorporated
• AKAMAI TECHNOLOGIES INC
• ALCOA INC
• ALLERGAN INC
• ALTRIA GROUP, INC.
• AMEDISYS INC
• AMEREN CORP
• AMERICAN EXPRESS CO
• AMGEN INC
• ANADARKO PETROLEUM CORP
• AVON PRODUCTS INC
• BANK OF AMERICA CORP /DE/
• BARD C R INC /NJ/
• BB&T CORP
• BOEING CO
• BOSTON PROPERTIES INC
• BOSTON PROPERTIES LTD PARTNERSHIP
• BRISTOL MYERS SQUIBB CO
• BUCYRUS INTERNATIONAL INC
• C H ROBINSON WORLDWIDE INC
• CARDINAL HEALTH INC
• CISCO SYSTEMS INC
• CITRIX SYSTEMS INC
• CLIFFS NATURAL RESOURCES INC.
• CNX GAS CORP
• COGNIZANT TECHNOLOGY SOLUTIONS CORP
• CONSOL Energy Inc
• DANAHER CORP /DE/
• DAVITA INC
• DUKE ENERGY CORP
• EBAY INC
• ELECTRONIC ARTS INC.
• EMC CORP
• ENERGEN CORP
• EQUITY RESIDENTIAL
• ERP OPERATING LTD PARTNERSHIP
• EXPEDITORS INTERNATIONAL OF WASHINGTON INC
• EXXON MOBIL CORP
• FASTENAL CO
• FLIR SYSTEMS INC
• FORTUNE BRANDS INC
• GENERAL DYNAMICS CORP
• GENWORTH FINANCIAL INC
• GILEAD SCIENCES INC
• Google Inc.
• HOLOGIC INC
• HOST HOTELS & RESORTS, INC.
• HUMANA INC
• IMPERIAL OIL LTD
• Ingersoll-Rand plc
• INTERCONTINENTALEXCHANGE INC
• INTERNATIONAL PAPER CO /NEW/
• INTUITIVE SURGICAL INC
• KELLOGG CO
• KIMBERLY CLARK CORP
• KRAFT FOODS INC
• LOCKHEED MARTIN CORP
• MARSH & MCLENNAN COMPANIES, INC.
• MATTEL INC /DE/
• MCDERMOTT INTERNATIONAL INC
• MEMC ELECTRONIC MATERIALS INC
• NETFLIX INC
• NEW YORK COMMUNITY BANCORP INC
• NUCOR CORP
• OPEN TEXT CORP
• PARKER HANNIFIN CORP
• Philip Morris International Inc.
• PLAINS EXPLORATION & PRODUCTION CO
• PPG INDUSTRIES INC
• PRAXAIR INC
• PRECISION CASTPARTS CORP
• PUBLIC SERVICE ENTERPRISE GROUP INC
• QWEST COMMUNICATIONS INTERNATIONAL INC
• REGIONS FINANCIAL CORP
• RR Donnelley & Sons Co
• SCHWAB CHARLES CORP
• SIGMA ALDRICH CORP
• Spectra Energy Corp.
• SPRINT NEXTEL CORP
• STRYKER CORP
• SUNTRUST BANKS INC
• TORCHMARK CORP
• UNITED STATES STEEL CORP
• UNITEDHEALTH GROUP INC
• Unum Group
• VARIAN MEDICAL SYSTEMS INC
• WALT DISNEY CO/
• WELLPOINT, INC
• WINDSTREAM CORP
• XTO ENERGY INC
• YAHOO INC

I use the term application profile from time to time.  Do you understand what an application profile is or how application profiles provide benefits to business users?  This blog post answers those two questions.

Section 1.4 (page 4 of 44) of the US GAAP Taxonomy Architecture explains what an application profile is from the perspective of the US GAAP Taxonomy:

Application profile - These voluntary restrictions followed by version 1.0 architecture form an "application profile" for the use of XBRL features within the taxonomy. It is strongly recommended that extensions to version 1.0 stay within this application profile. Systems using version 1.0 may, at their option, set rules which force extension taxonomies to stay within this application profile.

The US SEC follows these restrictions.  For example, the US GAAP Taxonomy Architecture says that: (a) all XBRL Dimensions information must be put into the context segment element (XBRL allows them to go into either the segment OR the scenario element), (b) typed members cannot be used (XBRL allows these), (c) no tuples are allowed (XBRL allows tuples).

These restrictions of XBRL (i.e. use segments, no typed members, no tuples) are set by the US GAAP Taxonomy Architecture and followed by the US SEC.  There are more restrictions that the US SEC places on XBRL.  For example, the SEC specifies that the context entity scheme used must be the SEC CIK number scheme and that the value of the entity identifier must be a valid CIK number.

Never does the SEC or the US GAAP Taxonomy ADD anything to XBRL, they always remove from what is allowed.  If they added things to an XBRL instance or an XBRL taxonomy, they would be violating the XBRL global standard specification.  Now, they can and do add things outside the XBRL.  For example, the RSS feed which is used to make people aware of SEC XBRL filings goes beyond XBRL.  In this way, the SEC is adding things to their system.

Now, XBRL software is not expected to use this RSS feed.  So, the RSS feed, although adding to the entire SEC system, does not break XBRL.  What we are talking about here are restrictions on XBRL, always using less than what is allowed by XBRL; thus restricting how a user can use XBRL.

Why would anyone require such restrictions?  Well, there are a couple of reasons.  One is that XBRL is a general purpose language, it has to meet the needs of business reporting as a broader use case than financial reporting which is implemented by the SEC.  XBRL provides a number of different ways of achieving something. To make it so users of XBRL within a system pick the say way and are therefore interoperable, restrictions of the approach to achieving something are necessary.

Another reason an application profile's restrictions can be helpful is in making things easier for business users. For example, in the US GAAP Taxonomy, within a [Table], it is guaranteed that you have only two types of child concepts to a [Table] concept: an [Axis] or [Line Items]. Go look at the taxonomy and see for yourself.  Taxonomy creation applications can leverage this consistency and make many things easier for users who have to edit or extend a taxonomy.

Now, a tool which supports a specific application profile may be easier to use because it leverages that profile, but there is a down side.  The down side is that the software which supports one application profile might not support some other application profile.  However, a general XBRL taxonomy editor would support any application profile which stays within the XBRL global specification.  Should like you would never want to create such software, one which supports one application profile of XBRL but does not support another application profile of XBRL.  That is the trade off.  But, considering that business users find editing XBRL taxonomies challenging and considering the size of the SEC XBRL use case, it is highly likely that software application specific to the SEC XBRL implementation will eventually appear.

Another thing worth pointing out is that the US GAAP Taxonomy is not the only application profile of XBRL.  For example, the FINREP taxonomy has its own architecture (i.e. it has its own profile). And COREP also has its own application profile.  Other taxonomies have their own application profiles also.

The fact of the matter is that EVERY XBRL taxonomy has its own application profile!  Some are documented like the US GAAP and FINREP, and others are less documented or not documented at all.  In fact, even taxonomies which do very similar things such as financial reporting have different architectures.  For example the US GAAP Taxonomy, the IFRS taxonomy and the EDINET taxonomy have different architectures.  The International Taxonomy Architecture group is comparing these architectures and working to come up with one common architecture which all three groups can use.

It is quite expensive to create an application profile, more expensive than people first realize.  You need to document the architecture such as the US GAAP Taxonomy and the FINREP documented their architectures, you have to write tests to be sure XBRL software creating XBRL taxonomies and XBRL instances stay within the application profile.  For  example, here are the test cases the SEC had to build. There are hundreds of tests.

Is it possible for the US GAAP Taxonomy, IFRS, and EDINET to all use the same application profile.  Well, actually that may not be necessary as the world is moving toward one set of financial reporting standards, IFRS.  That may or may not actually occur.  Type will tell.  It may or may not be the case that these three rather large use cases can agree on one application profile.  Time will tell.

What if you did not have to create your own application profile; what if you could just pick up someone else's and use theirs.  For example, why couldn't someone simply use the US GAAP Taxonomy architecture and the test case implementations and other infrastructure in their application profile of XBRL.  Frankly, i think that is exactly what people will do.  Software vendors are investing a tremendous amount of money in building the software infrastructure to support the SEC XBRL filers.  That software will meet a rather robust use case.  I believe that the US GAAP Taxonomy Architecture has a good chance at becoming an ad hoc standard for other business reporting use cases.  Time will tell.

What do you think wil unfold?

Here is another blog entry which explains why business users will like application profiles.

Really want to know even more?  Here is a link to a Google search for the term "application profile" on my web site.

Making sure that your SEC XBRL filing is correct is not a matter of technical wizardry, but rather understanding the types of things which can go wrong. If you understand the types of things which can go wrong you can be proactive and make sure those things don't go wrong and if they do be sure to detect the error.

Creating an SEC XBRL filing is a lot like figuring out a Sudoku puzzle.  If you understand Sudoku than you know that there are not multiple answers to a puzzle, there is one answer.  This is also the case for an SEC XBRL filing: there is really only one right answer given a set of financial information one is trying to disclose.  If you think about it that makes sense.  Would you really want there to be more than one right answer?  How useful would that be.

While the SEC does not require independent audits of XBRL filings submitted to them currently, you still need to have internal processes and checks on your work to be sure what you are creating is correct. A step beyond this is having your internal audit function check to be sure your processes are good ones and that they are yielding quality results.  Further, it is just a matter of time before the SEC will require XBRL filings to be audited by an independent accountant.  While the accounting/auditing profession works to figure out and formalize what these independent audits of XBRL will look like, being ignorant of what is required to output a quality product is really not a good idea.

Accountants like checklists. We use checklists when we issue a financial statement, a disclosure checklist.  Eventually these disclosure checklists will incorporate the things you need to do to be sure your XBRL filings are correct.  Here is a list of many of the types of the questions you should be asking yourself and ways to detect these types of mistakes so they can be corrected before you press that "Submit" button and your work goes to the SEC and is available for the entire world to see.

• Do I have the right taxonomy? If you find yourself adding a lot of concepts and relations you may want to spend a little more time seeking out additional taxonomy components you might have missed.
• Do I have the right industry concepts?(if you are in a specialized industry) While some specialized industries such as banking and insurance have specific entry points to the US GAAP taxonomy, other industry specific concepts are spread throughout the taxonomy and can be hard to locate.  Again, if it seems like concepts and relations probably should exist but you did not find them, they probably do exist.  You just need to spend more time looking.  Using a taxonomy viewer search capabilities (in a good tool) you can generally find concepts by searching for them.  Be aware that they may not be called exactly what you would call them so your searches of the taxonomy have to be pretty creative these days.  Eventually someone will create a nice synonym database which will make this process easier.
• Am I extending the taxonomy correctly?  Did you build your [Table]s correctly? Did you build your [Roll Forward]s correctly?  The US GAAP Taxonomy is not random or arbitrary.  It was built in a particular way.  You need to understand how things are built so that you can build your extensions so that they are consistent with the way the US GAAP Taxonomy is constructed.  Eventually software will provide more help, today this is more challenging.  Some taxonomy creation tools provide validation (information model validation) which helps you detect inconsistencies so you can correct them.
• Am  I allowed to extend the taxonomy in a specific location?  An extreme example will show what is meant here.  It would make no sense to add concepts on the balance sheet which were siblings to "Assets" or "Liabilities" or "Equity".  What other broad categories are there on the balance sheet?  As you get lower and lower into the details it becomes more challenging to understand if you really should be extending a taxonomy in a specific area.
• Should I create a new taxonomy concept?  When is it appropriate to create a new taxonomy concept?  For example, a minority of filers (3 of about 500) created a concept "Net Changes in Cash and Cash Equivalents" which is the sum of all changes in cash on the statement of cash flows.  The other 497 did not.  Those numbers make it seemly hard to justify an entity creating a new concept rather than using an existing concept.  In the case of net changes in cash and cash equivalents it is rather obvious that a new concept should not have been created.  In other cases it is not quite as obvious.  Judgement is needed and knowledge of how XBRL works is necessary to help you pick the appropriate course of action.
• Are all the XBRL instance fact values associated with the correct XBRL taxonomy concepts?  Should you be using the concept "Cash" or "Cash and Short Term Investments" or "Cash and Cash Equivalents" or some other version of cash from the US GAAP Taxonomy?  Was some sort of tagging mistake made?  Many types of these errors can be detected by a computation not adding up correctly.  Other tagging mistakes will not be detected using the validation of computations.  Understanding XBRL enough to understand which approach to use to detecting tagging errors is important to know.
• Are all the XBRL instance fact values associated with the correct context?(i.e. entity, entity segment, period, and so forth)  This is similar to detecting concept tagging errors.  Again, the validation of computations will help detect this type of error in many but not all cases.
• Are all numeric XBRL instance fact values associated with the correct units? (i.e. dollars, Euros, shares, pure and so forth) This is likewise similar to detecting concept tagging errors. 
• Are all numeric XBRL instance fact values associated with the appropriate decimal value? (i.e. rounded to thousands, millions, billions, or not rounded at all) This is likewise similar to detecting concept tagging errors. 
• Are all numeric XBRL instance fact values properly associated with other XBRL instance fact values?(i.e. are the computations correct) Clearly all your numbers should add up properly where they should add up.  This can be similar to detecting tagging errors, if you have the computation expressed in your business rules.  Realize that the US GAAP Taxonomy does not express all computations.  This does not mean that your numbers don't need to add up.  Just like in your printed financial it can be embarrassing when your "Increase (Decrease) in Receivables" on your case flow statement does not tie to the actual change in receivables on your balance sheet, the same relations need to work in your XBRL filing.  One big missing set of computations are those for [Roll Forward] type relations.  XBRL US does not publish those computations.  They are easy enough to auto-generate from the XBRL taxonomy.  You need to do that to create the XBRL Formulas (the best way) or some other means of verifying the accuracy of your XBRL instance fact values.
• Is the polarity of numeric fact values correct?(i.e. did you enter a number as a positive when it should have been entered as a negative) People tend to confuse how a number is presented and how it should be put into the XBRL instance: as a positive or as a negative.  Different people have different ideas on what should be shown as a positive and what should be shown as a negative on a financial statement.  For comparability purposes, XBRL had to get creators of financial information to agree.  That is why XBRL is not about how the number is presented, it is about communicating clearly whether something should be added or subtracted.  You can present it in your HTML or paper filing however you like.  Once you realize this, it is quite easy to test the polarity of a number: via the computation validation.  If a number is not involved in any computations, being sure the polarity is correct can be more challenging, it even might be a task which needs to be checked manually.
• Does the XBRL instance match the HTML or other version of the financial statements?While a short term problem which will exist when companies have to file both HTML and XBRL, you do need to be sure that what you are saying in your HTML and XBRL is the same thing.  Many companies are starting to realize that you can generate the HTML from the XBRL information. This can make the process of reconciling the two formats substantially easier.  While you may not have to file the HTML with the SEC much longer, clearly you are going to want to look at the financial information expressed in that XBRL instance. Even a "geek" cannot look at an XBRL instance and determine if it is correct.  You will likely always use some sort of rendering to help you be sure your XBRL instance is properly created.  What you do need to understand is the process used to create the human readable format so you understand what could break and give you misleading results which would potentially result in an incorrect conclusion on your part.

Good use of things like XBRL Formula to create the business rules you need to enforce automated tests to be sure that, say, all your numbers add up and that your taxonomy is constructed appropriately can help you weave your XBRL Sudoku puzzle together correctly.  Understanding what can go wrong will help you understand the automated tests which you need to get things right.

All this seems like a great deal of work right now and it is because old processes are being used to generate a new type of output.  Besides, today an SEC filer submits both the old HTML or ASCII filings to the SEC along with the XBRL filings.  This will change.  The SEC has already stated publicly that the HTML/ASCII filings will eventually go away and the only submissions will be in XBRL.  That makes sense; why would you want to have to reconcile the HTML/ASCII filings to XBRL filings?

Eventually, when the current legacy processes are replaced with processes appropriate for creating financial statements using XBRL the process will not only be easier but the quality of the output will be improved and the effort and resources required to achieve the high level of quality will be significantly reduced.  This is because all those XBRL tags can be leveraged to allow computers to perform many, many more of the checks humans are required to perform today.  Generally accountants don't realize this yet but once this software starts showing up they will recognize the benefits.

For more information on what can go wrong in your SEC XBRL filings see this blog post.  It contains the top 10 errors which are found in SEC XBRL filings.  Also, realize that XBRL is XBRL, be it filed to the SEC or someone else.  Other XBRL is subject to the same types of errors as SEC filings.  The point is that this information is useful for XBRL submissions to any regulator, not just XBRL filings to the SEC.

I have received a number of questions about the [Table] in the US GAAP Taxonomy.  What I want to do with this blog post is point out some big picture things which help you get a better understanding of what exactly a [Table] is, how to use them, and answer a the questions which I have received.

As can be seen by this analysis the [Table] is not well understood by SEC XBRL filers.  The inconsistency of the SEC XBRL filings are a good indication of this lack of understanding.

But understanding and using the [Table] does not need to be complicated or hard to understand.  You can make this vastly easier.  When business users realize this, they will start to point software developers down the right path.  I have not seen one software application which has used any creativity to make creating [Table]s intuitive for business users.

Further, the ideas which can make [Table]s easier to use and understand can also be applied to [Roll Forward] and other information modeling patterns within the US GAAP Taxonomy. I published a document called US GAAP Taxonomy - Tips, Tricks, and Traps in 2008. These sections of that document are very helpful in understanding [Table]s:

• Section 2.2: Organization of the Taxonomy
• Section 2.3: Understanding the Modeling Patterns Used Within the UGT
• Section 2.4: Understanding the Tables and Dimensions
• Section 2.5: Understanding Networks and Relations
• Section 2.6: Modeling Options, Syntax and Consistency

The information is slightly dated, but the general concepts are still very much applicable.  Eventually I will do a better job of organizing and explaining this information, but there are only so many hours in the day. 

Further, if you really want a good understanding of the US GAAP Taxonomy, read through the information in Section 3: General Information (applicable to all networks) and Sections 4 through 60.  These will be particularly helpful when you get into detailed tagging of the disclosures.

The Big Picture

Here is the big picture.  The [Table] is really a hypercube.  The US GAAP Taxonomy uses the term [Table] because the creators thought the term is easier for business users to relate to.  However, what that term tends to do is cause confusion between the presentation of information and the modeling of information, which is unfortunate.  Another term used to describe hypercube is simply cube or data cube.  You may be familiar with this term from business intelligence (BI) software or corporate performance management (CPM) software.

To be precisely correct, the term you really want to understand is hypercube and here is why this is important to understand.  Bear with me, you will realize that if you don't understand this you will never fully and properly understand the US GAAP Taxonomy.

• Scalar: A scalar is data which has no dimensions.  For example, the value for pi (which is 3.14) has no dimensions.
• Table or matrix: A table (think a spreadsheet or a relational database table) or matrix has two dimensions.  A table is basically a two dimensional hypercube.  Think rows and columns, you basically have an "X" axis and a "Y" axis.
• Cube: A cube has three dimensions.  Think a third dimension, you have an "X" axis, a "Y" axis and a "Z" axis.  Remember math class when they talked about that Z axis, turning a two dimensional graph into a three dimensional graph?
• Hypercube: A hypercube has any number of dimensions, or "n" dimensions.  Hypercubes are harder to express visually.  To do this you have to lock a dimension like you do in an Excel pivot table or repeat headings like is done in printed reports.  The term for this is slicer or looking at a "slice" of information.

If you are still reading, good job!  This blog post is for you.  A lot of people probably have already given up trying to understand this.  But you want to keep going because this information is critical for you, it will exist in your future.

A hypercube is a notion of the multidimensional model.  The multidimensional model is a flexible way of organizing information.  The multidimensional model is gaining more and more popularity because of its utility in making information flexible.  BI and CPM software use the multidimensional model because of this flexibility.  You may be more familiar with the term "relational model".  The relational model is used by relational databases.  The relational model is great for transaction processing but it tends to be too restrictive for analysis.  That is why the multidimensional model is used for analysis.

What does all this have to do with the US GAAP Taxonomy and the [Table]?  A [Table] is really an XBRL Dimensions hypercube.  It is expressed in the presentation relations in a certain way.  That [Table] is also expressed in the definition relations in a specific way.  The way hypercubes are expressed within the definition relations is dictated by the XBRL Dimensions specification and it MUST be the same for EVERY XBRL taxonomy.

The way a [Table] is expressed in the presentation relations in the US GAAP Taxonomy is dictated by the US GAAP Taxonomy architecture.  It is consistent.  That consistency allows for a computer application to auto-generate the definition relations based on the presentation relations.  That is how the definition relations were created by the US GAAP Taxonomy, they were auto-generated.

How do you create your definition relations?  Probably by hand.  Why is that?  Because your software vendor does not realize and leverage this fact.  But they could.

Here is another thing relating to [Table]s.  Per the US GAAP Taxonomy Architecture (see section 4.5, page 38 of this PDF), a [Table]:

• MUST have at least on [Axis] but can have any number of axes
• MUST have exactly one set of [Line Items]

So, why does your software allow you to put something other than an [Axis] or a [Line Items] concept as a child of a [Table] in your software application???

There are many other rules relating to [Table]s, [Axis]s, [Domain]s, [Member]s, [Line Items]s, and so forth.  There are other information modeling patterns such as a [Roll Forward] which have other rules.  Software can, and likely eventually will, leverage these relations.  Doing so will make it easier for business users to understand and use [Table]s and other such relations.

Issues with [Table]s

The first problem with [Table]s is that if you DON'T build your [Table]s consistently (i.e. you do this) you CAN'T use this leverage.

But there are other issues which you may, or may not, be thinking about.  But the issues do exist:

• [Table] express business semantics: A [Table] expresses business semantics, or is supposed to.  For example, this [Table] says the following:  A balance sheet has two [Axis], a "Scenario" and a "Class of Stock".  Those two [Axis] apply to every concept within [Line Items] of that [Table].  Opps! The concept "Cash and Cash Equivalents" has a class of stock [Axis].  Yes, that is what the [Table] says.  More on this in a moment.
• [Table]s are connected to other [Table]s: For example, summary information is connected to detailed information such as this line item from the balance sheet which also exists within the disclosures.  This is a business semantics, not a technical idea.  The disclosures provides details of the summary item which appears on the balance sheet.  Yet, in the example shown, the concept inventory is shown in a [Table] on the balance sheet, but it is not in a [Table] in the disclosures. This brings us to another issue, which we will cover next. But, in many cases different concepts are used to express exactly the same business concept used within the summary information and as the total of the detailed information and no real connection understandable by a computer exists.
• Some things are [Table]s, other things are not:  Basically a multidimensional model is mixed with a non-dimensional model, not a good idea.  In the case of inventory above the same concept is used in both the summary balance sheet and in the detailed disclosures and the connection is clear.  One reason this is bad is that XBRL Formula works either with a dimensional model or with a non-dimensional model.  Mixing the two causes serious issues.  To work around this to a degree XBRL Dimensions "default dimensions" was used to hack a connection and to try and get this to work correctly.  Another way of looking at this is what if everything were a [Table]?  One could be explicit about [Axis] (rather than implicit) and there would be now issues relating to mixing a dimensional model and a non-dimensional model.
• Sometimes dimensions are an [Axis] other times dimensions are items: Here on the balance sheet, Property, Plant and Equipment is an item, as is Land and the other classes of PP&E.  But here in the disclosures, Land and other classes of PPE are members of an [Axis].  Why the difference?

This is only a taste of some of the issues relating to [Table]s.  These will become more clear as detailed tagging of the disclosures begins to take place.

So now we circle back to the beginning of our discussion of hypercubes (i.e. [Table]s).  An understanding of the multidimensional model, an understanding of how XBRL Dimensions works, an understanding if data modeling, and an understanding of the financial reporting concepts being modeled are necessary to model the US GAAP Taxonomy correctly.  Likewise, an understanding is also necessary to build SEC XBRL filer extension taxonomies correctly.

In some areas the US GAAP Taxonomy is well modeled and a good example of how [Table]s should be constructed.  In other areas, [Table]s are not modeled well.  There are many reasons for this that I will not get into.  Three big contributors to the issues of the US GAAP Taxonomy are:

• An inapproprate obsession on presentation of information rather than modeling the data correctly.  What does not seem to be relized is that if the data model is correct the presentation is easy to model.  But if the data model is incorrect, one may be able to present the information correctly but you cannot model the data correctly.
• Mixing a dimensional model and non-dimensional information.  This leads to having to be implicit about certain information such as belonging to the consolidate entity.  It also leads to misuse of default dimensions in the US GAAP Taxonomy and to issues making XBRL Formula work correctly (because XBRL Formula supports either the dimensional or non-dimensional taxonomies, not a mixture of the two)
• Insufficient understanding of how hypercubes work and of the multidimensional model by the majority of business users modeling the US GAAP Taxonomy.

All of these issues can be addressed and corrected.  The first step to doing this is for more business users who understand the domain of financial reporting and what the semantics of the US GAAP Taxonomy SHOULD be saying to see what it is currently saying.  This will be seen within the SEC XBRL filings.  The next step is adjusting the taxonomy to say what the domain users really want it to say.

These [Table]s, hypercubes, the multidimensional model and such may be challenging to understand and it may take an investment in time.  I know that this was very challenging to me and it took a while to grasp and I am not saying that I grasp everything perfectly; I still have a lot to learn.  However, you have to admit that there are pretty good questions and observations.

The payback for business people understanding this is easier to use software.  Once business users realize that is going on here, they will be far better equiped to tell software developers what they need from software applications.

The really good news is that the US GAAP Taxonomy is not as complicated as string theory where their are somewhere between 11 and 14 dimensions one needs to wrap their heads around.

Several weeks ago I published pieces of the analysis which I had done on the SEC XBRL filings where were being submitted to the SEC.

I am doing a similar analysis for the second quarter of SEC XBRL filings and you can find information on that here on my blog.  I am doing this a little differently this time, learning from the past analysis.  You can go look at the information, it is all summarized on that link above and you can drill into detail if you want.  I will provide some information below to help you figure out how to navigate and read this information, see that below.  I do want to thank XBRL Cloud for the base of my analysis.  Without that list of all the filings and without some of the heavy lifting which is being done there, I would not be able to do as much as I can.  So thank you to XBRL Cloud.

If you are looking for summaries, this is what you want to check out the following items on this page, which is the same link as above:

• (A). Analysis Comments: Summary of analysis by filing. Shows interesting observations, issues, and specific errors identified within a set of 403 SEC XBRL filing. This is a complete list of SEC XBRL filings analyzed. (Note that this is updated periodically, so check back.)
• (B). Reported Calculation Inconsistency Summary:  Of 403 filings analysed, only 90 produced XBRL calculations inconsistencies. This shows a list of each SEC XBRL filing which has calculation inconsistencies reported by XBRL Cloud. This does NOT necessarily mean that the calculation are not valid, but rather point to filings which are being investigated further to determine if calculations are valid. See the analysis comments for a list of any confirmed calculation inconsistencies.
• (C). Reported Test XBRL Formula Issues Summary: Of 403 filings analyzed, only 55 produced XBRL Formula validation results which were different than the expected results. This shows a list of each SEC XBRL filing which had an unexpected result for one XBRL Formula which was used to test the cash flow statement roll forward. This does NOT mean that the filer had an error, but rather it identified where a filer used different concepts then were provided for this roll forward in the US GAAP Taxonomy, or they changed a computation in some manner, or the added additional concepts to the computation for some reason. See the analysis comments above for resolution of these issues.
• (D). Validation Errors Reported by XBRL CLoud Summary: Of 403 filings analyzed, only 28 produced XBRL Cloud validation errors. These errors were not detected by SEC validation upon submission for a number possible reasons including different interpretations of the EFM by XBRL Cloud and the SEC validator, different interpretations by a software vendor and XBRL Cloud, and other such issues. These issues should eventually be resolved as the SEC validation conformance suite continues to be built out, software vendors resolve these interoperability issues, etc. This list does NOT mean that the filer had an error, but rather it identifies possible software interoperability issues which should be resolved. See the analysis comments above for resolution of these issues.
• (E). Information Model Summary: Of 403 filings analyzed, a hand full appear to have used the [Table], [Axis], [Line Items] concepts consistently with the way the US GAAP Taxonomy was created and consistent with the US GAAP Taxonomy Architecture (see section 4.5 Implementation of Tables, page 38). There appears to be no guidance coming from the SEC as to how to properly model [Table]s, thus the variety. This analysis is making no judgment as to what is correct or incorrect, only pointing out the wide variety that [Table]s are being used. It is likely there are similar issues relating to the [Roll Forward] and other patterns within the US GAAP Taxonomy.
• (F). Excel Data Analysis Demo: This Excel spreadsheet allows someone to extract information from the set of 403 SEC filings. The macros used provide examples of how to get at the information in an SEC XBRL filing without using an XBRL processor. (Clearly you can do vastly more with an XBRL processor, but the point of this is to see what you can do without an XBRL processor.)
• (G). Excel spreadsheet with XBRL Cloud Error Information Sliced and Diced: This Excel spreadsheet slices and dices the information reported by XBRL Cloud. It focuses on errors and calculation inconsistencies. No informational messages, warnings, and best practices.

I am thinking about taking this information, condensing it, and providing it in the form of a high level summary of this detailed information.  Not sure if I will, or will not, undertake that task.  If you have an opinion, let me know.