Digital Financial Reporting

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?

As part of my detailed analysis of 1474 SEC XBRL filings I am seeing four common areas of confusion relating to the selection of the appropriate accounting concept. I provide details of these four areas in this PDF file. These four areas are important because pretty much every filer typically makes use of these concepts in their company filing. Here is the summary. 

• Total Stockholders' Equity. The issue here is which concept should you use to represent total stockholders' equity if you DO NOT have "Stockholders' Equity Attributable to Noncontrolling Interest". If you do have that concept, the answer is clear, you will use both "Stockholders' Equity Attributable to Parent" and "Stockholders' Equity, Including Portion Attributable to Noncontrolling Interest."  But this is less clear if you don't have a noncontrolling interest.  Per the US GAAP taxonomy documention and per what I heard from folks at the FASB, "Stockholders' Equity, Including Portion Attributable to Noncontrolling Interest" is the proper concept to use for total equity whether you do, or do not have a noncontrolling interest.  The key is the "if any" phrase in the concept's documentation.
• Income (Loss) from Continuing Operations Before Tax. Pretty much every filer is going to have a concept which expresses what amounts to "Income (Loss) from Continuing Operations Before Taxes". But, because of all the steps or levels in the income statement, it is less clear WHICH concept to use. Many filers become so confused that they try and get around the decision by creating their own extension concept, clearly the wrong approach to take. While the label will be different, my view of which concept to use is consistent with the 73% of filers who picked the concept with the US GAAP Taxonomy standard label "Income (Loss) from Continuing Operations Before Taxes, Extraordinary Items, Noncontrolling Interest".
• Net Income (Loss) Including Portion Attributable to Noncontrolling Interest. Similar to the total equity issue, if a filer has "Net Income (Loss) Attributable to Noncontrolling Interest", they generally pick the right concepts to use.  But if they don't have a noncontrolling interest, then they get confused between picking "Net Income (Loss) Attributable to Parent" and "Net Income (Loss), Including Portion Available to Noncontrolling Interest." Consistent with total equity, I say the correct concept to use if you do not have a controlling interest is the latter, "Net Income (Loss), Including Portion Available to Noncontrolling Interest" whether you do, or do not, have a noncontrolling interest.
• Net Cash Provided by (Used in) Operating Activities. Again, same deal.  If you have discontinued operations, which concepts to use in the cash flow statement for "Net Cash Provided by (Used in) Operating Activities" is clear, you use "Net Cash Provided by (Used in) Operating Activities, Continuing Operations" and "Cash Provided by (Used in) Operating Activities, Discontinued Operations" and you may even provide a subtotal for both using "Net Cash Provided by (Used in) Operating Activities".  But, which concept should you select if you ONLY have continuing operations: "Net Cash Provided by (Used in) Operating Activities" or "Net Cash Provided by (Used in) Operating Activities, Continuing Operations"? My analysis shows that 86% of filers used "Net Cash Provided by (Used in) Operating Activities" which I would personally tend to agree with. Others have a different view. (Note that the same issue exists for investing and financing activities also.)

If you ask each filer why they picked what they picked, they each have an answer which they feel is correct; thus their choice. Having that view misses the point. The point here is that if you asked to, the choices could be different.  Guidance in these four areas should be clear enough so that give the same set of facts every filer or filing agent, or analyst would make the same choice.

Further, there are likely other areas of the US GAAP Taxonomy where issues similar to this may exist.  Concept documentation needs to be clear enough to lead filers in the right direction.  If you run across areas such as this, I would encourage you to post a comment to the FASB so that the taxonomy can be adjusted.

Every weekend I try and do some experimentation with XBRL.  Last weekend I created a prototype of what I call XBRL Techniques and Trends. This weekend I built upon that base and created XBRL Techniques and Trends 2.

This second prototype is closer to what a real tool such as this might work.  Again, granted, it is limited because of my lack of programming skills, but I think it shows where this can go. This version has actual information from the filings whereas the first version showed information from the XBRL taxonomy.  Both are useful, the actual information is more useful it seems to me.

Be aware that my prototype works against a set of only 1474 SEC XBRL filings. These filings are all 10-Ks and 10-Qs. But, some are still in the block tag phase, others detail tag their filings. Notice that you can navigate back to the SEC Interactive Information Viewer rendering from the filing from which the fragment comes.

While this only shows single concepts, mostly policies but a few disclosures; this could handle multiple facts reported also, but that would require the ability to render the information.

Imagine taking this to the next level by sending a search engine against the concepts.  Because you know the context of what you are searching against, the information returned will be both more accurate and more useful.

Imagine having this type of information available within a software application which you are using to create a financial report. And I am not talking about Microsoft Word, although having the information available using that soon to be legacy process might be helpful; imagine if the software application "understood" US GAAP. How can software understand US GAAP? Well, that possibility is provided by the structured nature of XBRL. Now, you do get some of this information from the US GAAP Taxonomy today, you will get far, far more information as more meta data is added to the taxonomy.  Things like "if this is disclosed, then this must be disclosed" are easy for a computer to check. Today we call that a disclosure checklist.  Can a computer do everything? Certainly not. Another thing a computer can do is make sure all the computations foot, cross cast and otherwise tick and tie. That is easy for a computer, harder for a human who can loose focus or get tired.

People are beginning to realize that XBRL is far more than a punitive regulator mandate. This will get easier and easier as more and more software, such as (but much better than) things like my little XBRL Techniques and Trends prototypes show where all this XBRL stuff is leading.

What ideas do you have for useful software which can leverage the nature of XBRL? Leave me a comment, I may have some time during a weekend to build another prototype.