« Understanding the Need for Exemplars for SEC XBRL Filings | Main | Four Common Areas of Confusion in SEC XBRL Filing Accounting Concept Selection »

Seeing a Core Financial Integrity Layer

In prior posts I discussed how a logical model can be leveraged to make working with the XBRL technical syntax much easier. I even went as far as proving this to myself by creating a strawman implementation of the Business Reporting Logical Model (BRLM) created by the XBRL International Taxonomy Architecture Working Group. This logical model is good because it is flexible.

I took this a step further and applied the BRLM to SEC XBRL Filings. Nothing really new, this simply uses US GAAP taxonomy terminology within the model rather than the BRLM terminology.  I also built out the notion of information model a bit and added the notion of dimensional aggregation which was not built out in the BRLM.

In applying the BRLM to SEC XBRL filings, I started using the term "financial integrity" to communicate the notion that the pieces of an SEC XBRL financial filing have to fit together properly, just like a paper financial report has relations between the pieces of on the report.  Accountants, especially auditors, understand these relations innately, it is a cornerstone of our training to understand these relations.  But two things change when information is expressed in XBRL.  First, information is expressed using the XBRL medium so to do that correctly you have to understand the XBRL medium. Secondly, because the information is structured you can articulate these relations and communicate these relations to computer software.

In looking at SEC XBRL financial filings for the purpose of seeing how filers where applying XBRL and trying to tune the US GAAP Taxonomy I noticed something.  At the highest levels these filings are quite consistent and where they are not consistent where you would expect consistency, the inconsistencies could be explained.  What I mean by this and what I mean by financial integrity can be seen with the following examples:

  • A balance sheet always has "Assets" and "Liabilities and Equity".  Equity could take the form of either stockholders' equity or partners' capital. The only except to this rule in the 1474 SEC XBRL financial filings which I looked at was one trust who uses "Net Assets".  No problem, add possibility to the rule.  Both "Assets" and "Liabilities and Equity" foots (i.e. each adds up) and the totals of each agree (i.e. the balance sheet balances). There are other rules such as if you have a classified balance sheet you have "Assets, Current" and "Liabilities, Current".
  • An income statement always seems to have two things: what amounts to "Income (Loss) from Continuing Operations Before Taxes" and what amounts to "Net Income (Loss) Including Portion Attributable to Noncontrolling Interests."  These can be called by different terms, but they always seem to exist. The income statement foots.
  • A cash flow statement always has "Net Change in Cash". That net change in cash always foots. A cash flow statement also always has a cash concept (one of about 8 different ones in the filings I analyzed).  That cash concept always appears on the balance sheet, and the beginning balance of cash for the period being reconciled plus the "Net Change in Cash" for the period always equals the ending balance of cash for the period.
  • A statement of changes in equity always have each of the equity accounts from the balance sheet, always has "Net Income (Loss) Including Portion Attributable to Noncontrolling Interests" and all the other breakdowns in that concept which relate to the different components of total equity, and the beginning balance of each account plus changes expressed on that statement always equals the ending balance of each account.

These are rock solid relationships. Are there some variations to these? Sure they are quite possibly, just like a few trusts report "Net Assets". Fine, either create new models or adjust the existing model to make it fit reality.  For example, a few SEC XBRL filers put the "Effect of Exchange Rate on Cash and Cash Equivalents" in a different spot in the computation. Most accountants I talk to say that what they do is a mistake.  Either way, no problem; adjust the financial integrity model.

Most accountants will think that I am insane even pointing out those financial integrity rules. Of course all those things foot, cross cast, tick and tie.  Well, the point is that the XBRL going into the SEC is both following those rules in most cases, there are some exceptions and those rules; and more importantly that every one of those rules can be verified using computer software.

Are their other relations? You betcha. That discussion for another day.  This is about the core financial integrity.

So now here is my question. Can this core financial integrity be leveraged to make working with XBRL easier?  I think that it can.  This is like adding another layer on top of the logical model layer.

I found some resources which explain this:

  • Semantic data model. From this, the following statement resonates with me, "This means that the model describes the meaning of its instances."
  • Conceptual schema. Note the focus here on semantics.
  • Three schema approach. Note the diagram in the lower right had corner which shows the conceptual model layer above the logical model layer.
  • Zachman Framework. This discusses enterprise architecture frameworks.  This is way over my head.

So the question in my mind is this: Is US GAAP itself a semantic layer or conceptual layer which can be leveraged both to validate the core financial integrity layer but ALSO within software applications to provide an even higher level "layer" for a business person to work with?

I don't think this is a question of "could you", I think it is more a question of "should you".  This is what I mean. XBRL is a very general, flexible, comprehensive, robust technical syntax. No one uses 100% of XBRL.  Each implementation that I have seen takes a portion of XBRL, what amounts to an application profile.  COREP did that. The FDIC did that.  The SEC and US GAAP did that. These profiles are described by the architecture of the profile, for example here is the US GAAP Taxonomy architecture.

When you do this, you gain something, but you also give something up.  For example, US GAAP gave up the features for defining typed dimensions, tuples, etc. What they gained is an easier to use application profile, but software created which takes advantage of that profile looses the ability to work with implementations of XBRL outside that profile. That is not necessarily a good or bad thing, it depends on the balance of pros and cons.

So what if software was constructed which could only work with US GAAP and was built to leverage the core financial integrity which I am describing above? In essence, US GAAP is the schema.  That application will not work with IFRS.  Again, this is not inherently good or bad, it just offers different options.

Another way of saying this is that XBRL is like a Swiss Army knife. The US GAAP Taxonomy architecture is like a more specialized knife, it won't do everything but it does what it is built to do better than a Swiss Army knife. Is it the right thing to do to build software which will only work with the US GAAP Taxonomy or maybe even make it more specialized and only work with SEC XBRL financial filings.  Maybe.  That application would certainly be much easier to use than a general XBRL software application.

My point here is twofold.  First, I point out this core financial integrity layer.  Second, personally I think that at least some software will go down this more specialized path eventually.

What do you think?

Posted on Saturday, April 2, 2011 at 09:02AM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

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):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.