Digital Financial Reporting

Per Accounting Today,  Hans Hoogervorst, chairman of the International Accounting Standards Board (IASB), said Wednesday that he believes Extensible Business Reporting Language, or XBRL, has

“the potential to improve the effectiveness of financial reporting.”

Note that he used the term effectiveness.  Most people think XBRL is about efficiency, for example automating the exchange of information.

Mr. Hoogervorst seems to have a very realistic view, he goes on to say:

“We must understand what we have done well, and where there is room for improvement. We must work closely with preparers, with regulators, with the accounting profession and others to ensure that our work and initiatives are fully joined up. Most importantly, we must pay particular attention to the needs of the investor community. Investors should be beating down our doors to embrace XBRL, and we need to understand and address any barriers to its use.”

This document helps in the "room for improvement" area, helping accountants and other business users be successful.

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.

The terms "semantics" and "metadata" are increasingly showing up in initiatives which are attempting to properly position governmental organizations and private companies in our new "digital economy". Two good examples of this are the W3C Government Linked Data Working Group and the Asset Description Metadata Schema initiative in Europe.

The Asset Description Metadata Schema folks have a great document, Towards Open Government Metadata which provides some very nice definitions of semantics and metadata.

Paraphrasing from that document, they explain that semantic interoperability is an essential precondition for open, flexible information exchange. Not the only precondition, but an essential precondition.  This is consistent with what the HL7 folks say, pointing out that technical, semantic, and process interoperability are all important.

That document further describes why their "Semantic Interoperability Assets" (i.e. metadata) are important to achieving semantic interoperability:

"… the meaning of data elements and the relationship between them. It includes developing vocabulary to describe data exchanges, and ensures that data elements are understood in the same way by communicating parties."

This promotional video walks you through why semantic interoperability and appropriate metadata are essential ingredients for effective business to business information exchange.

Another part of that paper which is of particuar value in understanding the term metadata is what they call the five levels of maturity for metadata management:

• Level 1: Metadata Ignorance – Metadata is not documented, mainly because administrators are not aware of its importance.
• Level 2: Scattered or Closed Metadata – Metadata may be partially documented but a) not in a centralised and structured way or b) it is not available and accessible under an open license framework, in other words as "Open Metadata" for developers to share and reuse.
• Level 3: Open Metadata for Humans– Metadata is documented and becomes available as "Open Metadata" for reuse, but are not systematically published in a reusable format, e.g. may only be available in .pdf or .doc documents.
• Level 4: Open Reusable Metadata– Metadata is centrally managed, and published as "Open Metadata", in a machine readable format and/or an API is provided for computers to access, query and reuse the available metadata repositories, catalogues, libraries, etc.
• Level 5: Linked Open Metadata – Semantic Assets are documented using linked data principles and are managed by advanced Metadata Management Systems.

When you build your XBRL based metadata to achieve the semantic interoperability described above in order to achieve business system to business system information exchange keep these ideas in the back of your mind.

One thing that is becoming increasingly unclear how XBRL best fits into the linked data initiatives such as the two above.  These seem to be the spectrum of options:

1. Everyone should ditch their technical syntax and use the XBRL technical syntax. XBRL zealots push for this.  Yeah, do you really think that is going to happen?  I doubt it, nor does it need to.
2. XBRL ditches its technical syntax and moves to RDF like the two groups above and others. That is what the Government Linked Data folks are calling for, see their list of the ingredients of high quality linked data; they say everything needs to be in RDF.
3. All these groups agree on the business semantics and all the metadata is made available which is necessary to convert from one technical syntax such as XBRL to any other technical syntax such as RDF/OWL.

Technical syntax is important, but less important than agreement on semantics.  Or, maybe I am saying this incorrectly.  Perhaps that it is not about which is more important, technical syntax or semantics; it seems to be that there are multiple "layers" which are necessary to achieve effective interoperability.  If you have all the meaning, nothing prevents conversion from one technical syntax to another.

It seems as though some people are even questioning the XML syntax as the base for all other technical syntaxes.  For example, JSON seems to be a more compact syntax than XML with some distinct advantages.  Seems to me that the important thing is whether the technical syntax works correctly over HTTP and whether the syntax can be used globally.  XML is global.