Digital Financial Reporting

Michelangelo, one of the great creators in Western history, put it succinctly:

"Criticize by creating."

I have been maintaining what I ended up calling a "reference/model implementation" of a digital financial report since about 2004 or so.  The intent of the reference/model implementation was to put all the different "patterns" which I discovered within financial reports together to see if I could get everything to work correctly.

This process was a struggle.  The good thing is that I learned a lot by undertaking that struggle.

 Software did not work correctly, even when software would detect errors different software reported different sets of errors, few things were documented, few examples were provided, everyone seemed to have a different opinion as to what the "right" approach was, many people were secretive and did not share information; I could go on but I think you might understand what I am saying.  The bottom line is that it was hard to create examples and it was even harder to make sure you did not make any mistakes.

I am putting the final touches on my next iteration of a reference/model implementation.  This time things are different.  I cannot get into details now, but I can say that software is improving significantly, there are plenty of examples to learn from, there is less need to deal with things at the XBRL technical syntax level, there is more agreement as to business report semantics; there are other reasons things will be different.

These disclosure templates are a step toward understanding what a digital financial report expressed using XBRL might best look like.  Many of these are more complicated examples, I have spent the last year or so understanding these, piecing them together into an improved reference/model implementation of a digital financial report, and trying to understand how best to create such reports.

Why do I go through all this effort?  Why do I persist in this struggle?  To learn.  Here is the way I see it. This "SEC XBRL experiment" and these other such XBRL experiments around the world will either succeed or fail.  Sticking with the SEC experiment; one of two scenarios are going to play out:

1. Abandon XBRL.  The SEC and public companies are going to walk away from XBRL, abandoning this experiment for being too costly for public companies with too little benefit in terms of usable information.
2. Embrace digital financial reporting.  If it is embraced and used, clearly it will have to work correctly.

There are many different definitions of "embrace digital financial reporting".  It could be embraced in certain progressive areas of the world, it could be adopted globally, it could be adopted only for public company financial reporting, it could us IFRS only, it could use IFRS and US GAAP, it could include private companies, not-for-profits, state and local government financial reporting; there are lots of permutations and combinations which are possible.

One thing seems pretty clear. The probability of the "abandon XBRL" scenario being part of our future is going down.  With the investment companies are making trying to get XBRL to work appropriately it is hard to believe that those companies are going to want to simply walk away from XBRL.  But maybe.

Either way, both to avoid the abandonment of XBRL and to have a contingency plan for the global adoption of digital financial reporting, I struggle to figure out how to best harness this technology for accounting and financial reporting.

And that is why I continue to create things such as this reference/model implementation of a digital financial report.  To learn about the tools, to help the accounting profession learn about the tools, and to otherwise figure all this stuff out.

So, you don't think that what I am creating is what digital financial reporting should be like, how it should work?

Criticize me by creating an alternative.  Prove that your alternative works better than what I have created.  Or, if you don't have the where-with-all or understanding to create your own example; look at my example and the examples of others, ask good questions, and reach your own conclusion as to what might be the best approach.

Let me explain what I have put together and why and the criteria I use to evaluate it.

A financial report has many components.  A component is simply a piece of a financial report.  A component defined as being a set of facts which go together for some specific purpose within a financial report. A component can also be broken down into subcomponents.

The reference/model implementation I created has about 30 components.  Each component is provided for two reasons. 

1. Provide examples of how to model different components of a financial report. 
2. Show how the components of a financial report and that the components fit together correctly.

The reference/model implementation is a balance between providing too little and providing too much.

On the one hand, the reference/model implementation digital financial report should look like a financial report.  On the other hand, real financial reports can be quite large, repeat the same sorts of things many times, and be an overwhelming example to work with because of its size.  The reference/model implementation looks enough like a financial report and has the pieces of a typical financial report and therefore will not confuse accountants which understand what a financial report should look like.  But the reference/model implementation also has all the moving pieces which need to interact with one another correctly.

Everything in the reference/model is there for a specific reason.  Accounting is well understood and the reference/model is not about accounting and not about changing accounting or financial reporting.

The reference/model is about figuring out how to use structured mediums such as XBRL to articulate information which is expressed today using unstructured mediums such as paper and electronic paper-type mediums such as HTML, PDF, or Microsoft Word.  The reference/model is about figuring out what a digital financial report should look like, all things considered.

The reference/model implementation "works correctly" by one definition of works correctly.  Each aspect of "correctly" can be shown and also "incorrectly" can be pointed out because "correct" is so explicitly defined.  (This is as opposed to the situation where correct is not well defined and therefore it is hard to figure out if something is, or is not, correct.)  If a modeling approach is changed in one area of the reference/model implementation which breaks the model in another area, that modeling option is not considered as an option because it cannot be made to work.

It is the objective balancing of all the allowable options and the fact that when used together the financial report works correctly from a financial reporting perspective and from a technical perspective which decides whether some modeling approach is appropriate or inappropriate.  The intent here is to minimize subjectivity.  When multiple options work, the option which seems to work the best, all things considered, which is used.

While the reference/model implementation is correct, by this author's definition of correct; other definitions of correct are possible and other definitions of "best modeling approach" are possible.  That other approach could be a slight tweaking of this reference/model implementation or it could be a totally overhauled version.  However, any other version of any digital financial report should be able to pass the criteria established for this reference/model implementation.

Others may have additional criteria which a digital financial report must have.  Perhaps this author missed something or for some other reason neglected to include an important aspect of a digital financial report.  If that is the case, the reference/model implementation should be tested against that criteria.  On the other hand, any other implementation of a digital financial report should either be able to (a) pass this author's criteria or (b) show why this author's criteria is incorrect.

The criteria which were used to judge my reference/model implementation are enumerated here.  These are the self-imposed criteria which were used to evaluate this reference/model implementation and define "correct":

• Every model structure is logical and consistent.  Meaning there are no inconsistent and therefore perhaps confusing or potentially misinterpreted modeling situations.  For example, an [Axis] as part of a [Table] definition makes sense; an [Axis] within a set of [Line Items] does not.
• Every computation is expressed and proven to work correctly.  Every computation must be proven to work correctly by passing one or more business rules.  If a computation relation exists and it is not expressed, then there is no way to tell if the computation works correctly per the XBRL medium.
• No duplicate facts.  Duplicate facts result from modeling errors and therefore should not exist.
• Everything is consistent.  If there is no specific reason for an inconsistency which can be articulated which justifies the inconsistency; then you are being inconsistent and one of the approaches must be dropped.  Inconsistencies cause additional training costs and additional burden, and unnecessary burden on the user to somehow rationalize the inconsistency.
• Each property is correct.  Each property of any component, fact, report element, or parenthetical explanation must be correct from a business meaning or semantics perspective.
• Meaning can be logically explained to a business user.  The meaning of each and every aspect of the digital financial report can be explained, logically, to a business user.  If the meaning cannot be explained, then it cannot be considered to be correct.

Do you feel that I am missing some criteria?  Please let me know.  I will consider your feedback, determine if it seems like an appropriate criteria, maybe ask you some questions, and then improve my criteria.  I have no problems with making things better.

Think about taking me up on my challenge.  It is important that us as accountants to figure out how to properly harness and use, or not use, digital financial reporting within our profession.

Who am I to define "correctly works"?  However, if I am not the appropriate party to establish such a definition, perhaps you can point me to a better definition or improve upon my definition.