Digital Financial Reporting

Accountants are generally obsessed with the financial concept characteristic of a reported fact to the detriment of other important characteristics, relations, and properties.  This obsession needs to end for SEC XBRL financial reports to be modeled correctly and for its information to be useful.

In a post to XBRL-public, David vun Kannon of Deloitte lamented about this to a degree when he was articulating why today's modern, complex business' financial position cannot be fairly presented to the capital market through a series of tables and text. Specifically, the statement was (emphasis added):

The whole hypercube and nothing but the hypercube. The data _and_ the dimensions. Standard dimensions are as important in every axis of the hypercube as they are in the financial account dimension.

I agree with this statement. The statement is a bit technical; a "dimension" and an "axis" is simply a way to express a characteristic. A "hypercube" is a way of organizing the characteristics of the different components which make up a financial report such as a balance sheet, income statement, or the many disclosures.

What I mean is this.  Accountants are all over the financial concept or financial account as it was put above, for example "Cash and cash equivalents" or "Net income (loss)".  A financial report such as an SEC XBRL financial filing, reports fact, those facts have values such as "100,000" and those facts are described by a number of characteristics such as:

• The financial concept such as "Cash and cash equivalents" as opposed to perhaps "Net income (loss)".
• The reporting entity such as CIK 1234567890 which identifies ABC Company as opposed to the CIK of 0987654321 which might describe XYZ Company.
• The period such as December 31, 2011 or current balance sheet date as opposed to December 31, 2010 or prior balance sheet date.
• The business segment of consolidated entity as opposed to one of the specific business segments.

These are only some examples of characteristics which describe the fact, there are many other examples (see section 2.7., Common characteristics of financial facts exist, of the Financial Report Semantics and Dynamics Theory for more examples).

These facts, values of those facts, characteristics which describe the facts, relations between the characteristics, and properties of the facts, characteristics, relations are what make up a digital financial report.  Reported facts are organized into components such as a balance sheet, income statement, cash flow statement, policies, or disclosures.

All this "stuff" makes up a digital financial report or computer readable model; use whatever term you like.

As pointed out in my document Guide to Verification of an SEC XBRL Financial Report, to be a true and fair representation of an entities financial report, all of this "stuff" has to be correct, complete, consistent, accurate, possess fidelity and possess integrity.  All of it.  Not just the financial concept or financial account.

To achieve this objective, accountants need the assistance of good software.  Modeling this information correctly; the financial concept characteristic and all the other characteristics, relations, and properties; is detailed work, but no more detailed than expressing that same information in a Microsoft Word document. 

What is different is that accountants need to build computer readable models and not presentation-based text and tables.

As I see it, part of the cause of the obsession with the financial concept characteristic is the complexity of the overall process of creating something like an SEC XBRL financial report.  Accountants are simply grasping onto something, anything, understandable.  The financial concept is one thing, the presentation of the report is another.

You cannot really fault accountants for this.  Personally I fault software developers who have not delivered appropriate software.  Accountants are smart people.  This model-based approach to financial reporting is new to them.  You cannot expect them to jump from what they have been doing for years to something as complicated as the XBRL technical syntax.  But that is exactly what software vendors have built for accountants to use: XBRL technical syntax editors.

CEOs, CFOs, accounting managers, and other business users involved in the process put their names on this financial information and they need to be able to understand if the information is correct, complete, consistent, accurate, has fidelity, has integrity and is a true and fair representation of a reporting entities financial information.  All of it, not just the financial concept.  If they cannot achieve this objective, there is zero probability that digital financial reporting will ever replace paper-based or electronic paper-based (i.e. HTML, PDF) financial reporting.  Nor should it be allowed to.

People have often used the metaphor that it takes a lot of effort to change the course of an aircraft carrier to describe how hard it would be to get big companies to embrace XBRL. Well, if the number of times the keyword "XBRL" shows up in the agenda of the IBM Vision 2012 Conference (Financial Governance, Risk Management, Performance Optimization) is an indicator; the IBM aircraft carrier has changed its XBRL course, it is at flank speed, and all hands are on deck!

Go to the link above, then go to the sample agenda builder, and type in "XBRL" to search on that keyword and watch what shows up. Wow.

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.