Digital Financial Reporting

Mike Willis of PriceWaterhouseCoopers wrote a good article about how disclosure management software is improving the process of creating financial reports by 30%. In that article Mike mentions the notion of a reporting template.

Last year I created a set of 75 reporting templates. I have updated those reporting templates to the 2013 US GAAP Taxonomy, corrected a few XBRL Formula errors, and updated the visual of the reporting template.  Other improvements have been made.  You can take a look at these updated reporting templates here.

One of the more useful things that I added to the library of reporting templates is this visual index of all 75 reporting templates.  This visual index is interesting to me for two reasons: (1) It quickly allows you to find a reporting template, (2) It shows renderings which are generally pretty good.

The renderings of each reporting template are provided by XBRL Cloud.  The renderings are screen shots of the renderings provided by the XBRL Cloud Evidence Package and/or XBRL Cloud Viewer (click on the "Viewer" button on that page).

Personally, I think the renderings are pretty good.  Granted, they are not perfect and there are other disclosures which are more complex and maybe they would not render so good.  However, I am not so sure that even complex disclosures would not render correctly or at least good enough to be readable.

There are two things which contribute to poor renderings as I mentioned on my blog a year ago:

• Poorly represented information (i.e. bad modelings)
• Poor rendering engines

If you have a poorly represented disclosure there is no rendering engine which would be capable of rendering that poor representation correctly.  Likewise, you can have the best representation in the world but if the rendering engine is not so good you could likewise not get a good rendering.

So both the representation AND the rendering engine contribute to achieving a usable/readable rendering.  I am not talking about a pixel-perfect rendering.  I am not talking about a rendering exactly as one person might want the rendering to be.  Specifically satisfying every person's preference with one rendering approach is impossible.  Not is that a use case for XBRL as I see it.

The goal is a usable and readable rendering for any disclosure.

Something like Inline XBRLcan get a rendering closer to "pixel-perfect". The Table Linkbase created by the folks pushing the Data Point Modelcan help also.  But are Inline XBRL and the Table Linkbase really necessary?  I am not so sure.  Constructing the Inline XBRL or Table Linkbase information includes additional work.  Perhaps there is some benefit for some specific use cases but personally I don't want custom renderings; what I want is to be able to compare information.

But don't rush to judgment.  Be sure you are looking at a good information representation using a good rendering engine before you determine that XBRL can or cannot be rendered correctly.

This article, A Vision of XBRL, articulates a grand vision of "a single channel of reporting from the firm all the way through to the European supervisory bodies" in Europe, in real time.

The article points out the tremendous success the US FDIC had with XBRL saying,

According to a 2006 report by the agencies, the introduction of XBRL resulted in a marked improvement in the quality and timeliness of the reported data. Data cleanliness improved from 66% to 95%, and 100% of data received met mathematical requirements, as opposed to 70% prior to introducing XBRL. Data accesses and inflows also increased significantly and staff productivity increased, allowing staff to handle between 10%-33% more cases.

Yet, of the US SEC implementation of XBRL the article points out a lukewarm response to public company filers who submit information to the US SEC stating,

“XBRL has promised more than it has delivered” so far, and is at risk of becoming obsolete for most analysts and investors unless their concerns are addressed.

and

While the authors argue that the initiative has succeeded in providing freely available information of the reported data, they express “numerous reservations” about its future unless stakeholders improve the usability and data quality. Questions are also raised about the simplicity and stability of the taxonomy and a lack of user tools to help make the most of the data.

And finally I will point out a proposed solution to this problem which a paper referenced by this article suggests:

“XBRL technology development needs to be taken over and run by technologists, rather than accountants and regulators.”

I would propose that the solution to the problems encountered by the US SEC is not to take accountants and regulators out of the loop but rather to PROPERLY put accountants, regulators, and other business users into the loop.

I would point out the difference between the FDIC and SEC systems.  The FDIC does not allow extensions to its XBRL taxonomy.  The SEC system does allow extension.  It is that extension process which causes many of the data quality problem encountered by the SEC.

Another "solution" to this problem is to eliminate the extensions, make the reports submitted to the SEC more like forms. This is an absurd suggestion because it would greatly reduce the richness of the reported information and the primary value of US GAAP financial reporting.

The errors caused by extensions is not the problem, the extensions are a symptom of two problems:

1. Lack of sufficient business rules. The first problem is the lack of business rules which keep the information correct thus helping to control the extension process by articulating things like fundamental accounting concepts which must exist and the unbreakable relations between those concepts. The only way a meaningful exchange of information of information can occur is the prior existence of agreed upon semantics and syntax rules.
2. Lack of clear semantics. Software developers building software have no choice but to expose business users to the XBRL technical syntax unless there is a clear set of easier to use semantics. The Financial Report Semantics and Dynamics Theory shows that such semantics do exist.  It even shows that the vast majority of SEC XBRL financial filings adhere to those semantics.  The business rules mentioned above is one type of semantics that shows both that (a) 98% of SEC XBRL financial filings are shown to follow those semantics and (b) why the other 2% don't. That information can be used to either fix the errors or change the financial report ontology.

The real solution to the problems which ails the SEC and US GAAP Taxonomy implementation of XBRL is an agreed upon set of financial report semantics articulated in a form which is understandable to business users.  Business users are the only ones which can tell you if the semantics of a financial report are correct; there are no technologist which understands those semantics, particularly the important nuances.

None of these challenges is unique to XBRL or financial reporting. The article An Introduction to the Semantic Web points out that what people are trying to achieve with technologies such as XBRL are not only necessary, they are inevitable, for pretty much every domain.

Trying to simplify the domain of financial reporting by disallowing extension or trying to remove accountants, regulators, and other business users from the process may seem convenient.  I say it is not a solution to the problem, it is the cause of the problem.  Technologists need to do a better job of communicating with business users by building them tools and processes they understand.

Anyone can build something that is complex.  It takes real talent to build something which is simple to use.  I am not talking about simplistic, I am talking about simple to use.  There is a big difference between the two.