Digital Financial Reporting

There was a discussion on XBRL-Public and CORBA was brought up.  I wanted to summarize information about CORBA so that I could get back to that information.  Here is that summary.

Sees that CORBA is maintained by OMG.

CORBA, or Common Object Request Broker Architecture, is defined by this tutorial as follows:

The Common Object Request Broker Architecture (CORBA) is a standard framework allowing software objects to communicate with one another, no matter where they are located or who has designed them. The Object Request Broker (ORB) is the "middleware" which performs the communication. Objects may reside on the same computer, or different computers connected by a network.

This is the CORBA Basics page published by OMG.

CORBA is similar to Microsoft's DCOM (Distributed Component Object Model).  It seems that ActiveX or most people are probably more familiar with OLE (Object Linking and Embedding) or OLE Automation or COM (Component Object Model).

The following web pageprovides a bunch of good information on CORBA and DCOM.

I was seeing something incorrectly which made it more difficult to see why problems in the form of complexity and errors occur.  So basically, it appears that my perception was incorrect.  This line of thinking below seems to be more correct about the advantages of "model-based" approaches to working with XBRL.

The bottom line it is not about whether to use a modeling-based approach; you have no choice but to use some sort of model-based approach.  The real question is about the "level" of your model.

This is what I mean.

When you want to get a computer to do some sort of work for you there is always a need to use some sort of "model".  It is the model which enables you to express your business problem in a form where you can communicate with a computer and the computer can understand you.

The problem with most software vendors software when it comes to XBRL is that they have exposed the wrong model level to both business users and other software developers who have to use their XBRL processors and other business reporting infrastructure.  Almost universally software vendors expose the XBRL technical syntax level to both business users and to software developers.

That means a number of things.  First, everything is harder and more complex because everything relates to the XBRL technical syntax model which is complex, hard for business users to relate to, offers a lot of flexibility because there are numerous ways to achieve the same thing within the XBRL technical syntax, and so forth.

But the biggest missing piece from XBRL processing capabilities implemented at this level is the notion that semantics even exists in that model.

That means two things.  First, business users have to "reconcile" the semantic model of their business problem to the exposed technical syntax model themselves.  And so, while business user can do this correctly because the XBRL technical syntax can work correctly to express the business semantics of the information; business users can also get things wrong because the flexibility exposed by the XBRL technical syntax level offers many/multiple ways to achieve some result.

Therefore business users could pick a right or wrong approach and in order to understand the difference, the business user needs more training on the complex technical syntax level to be sure they are expressing the semantics correctly (which they do understand) using the technical syntax (which most business users will never understand and every business user will struggle to understand.

But what is even worse than the above is the fact that because these XBRL implementations which are built using the XBRL technical syntax model; they have no notion at all of any semantic model.  Not only does this make things complex and therefore more costly to work with but there are significant gaps between the XBRL technical syntax which must now be crossed.

The only way to cross these gaps is for business users to work with IT people, project by project, system by system, business report by business report; because business users simply do not have the means to cross this gap by themselves.

There are exactly two types of processes which can be used to identify semantic mathematical and logical mistakes/errors: automated processes and manual processes.  Automated processes are best because they are performed by computers, they are more reliable, they can get you to 100% reliability because computers do the work consistently every time without fail, and overall automated processes cost less.   Manual processes must be employed whenever automated rules are not provided or where automated processes simply cannot achieve the result. In both those cases, humans must do work manually.

All that "stuff" that the business user and IT technical users would need to create could, and should, be built into any business reporting platform or system.  Why would it not be built in?

If these things needed to cross the gap between semantics and technical syntax were built into systems then the business users could then simply configure, without need for technical people to get involved, the business semantic level mathematical and logical rules.

The business users would not need to worry about technical syntax verification/validation with either modeling approach, technical syntax model or semantic level model.  Both of these modeling levels clearly need to verify that the technical syntax is correct.

It is this gap between the technical syntax modeling level and the semantic modeling level which provides the most value to business users because it both hides the complexity of the technical syntax level and it keeps things safe and technically correct for the business user because it ONLY allows business users to express the semantic mathematical and logical rules correctly. 

Now, the business users can also make mistakes of expressing the semantic mathematical and logical rules inconsistently.  But incorrectly and inconsistently are different problems caused by different things.  If a business reporting system provides something like a set of profiles from which a business user might pick, each profile correctly configured by a highly-skilled IT engineer or architect; then the business user would be free to pick the profile they desired and safely work with the XBRL technical syntax using that profile.  Or, maybe the business user would pick some other profile but still a set of correct and safe choices.  Or, perhaps the system allows for in addition to picking from some set of available profiles the ability for a business user to collaborate with an IT technical person with the right skills to define or change an existing profile.  Each of these approaches enables different levels of flexibility but also assures that the reconciliation or implementation of the technical syntax to be consistent with the best practice uses of the technical syntax to correctly express business semantics.

Now, XBRL International can solve this at a higher level and these "profiles" can be agreed to at a higher level, shared between implementations and taxonomies making all this even safer and simpler.  That is what the XBRL Abstract Model 2.0 (created by XBRL International) does.  It makes these people articulating taxonomies realize/recognize that they must also, in order to achieve true interoperability, make some of these decisions, or select which options should be used in essence articulating their implementation profile of how the XBRL technical syntax should be used for their system.

Some software vendors are beginning to implement semantic level layers within their software offerings.  These semantic layers offer this sort of higher-level modeling.  Each implementation does not have to figure out the correct architecture; that has been done by highly-skilled technical users which have a true grasp of the XBRL technical syntax.

I see at least three big advantages of using such a modeling approach with a higher-level semantic model built right in with other XBRL processing capabilities:

• Ease of switching between technical syntax.  say between different XBRL technical syntax options or even versions or even totally different syntaxes such as to the W3C Government Linked Data RDF/OWL Data Cube Model or some other form of XML
• Safety.  Business users can work safely at the business semantics level and not make bad technical choices, most reporting problems could likely be solved without IT assistance at all but by following good IT practices.  But, if need be, business users and IT professionals could collaborate to create new profiles as necessary.
• Ease of use.  Complexity is significantly reduced because business users work at the semantic level, not the technical syntax level.

Understanding the moving pieces at play here will help you pick the software solution which provides you with the appropriate level of flexibility.  Not everyone desires 100% flexibility because they may not need it or they wish to avoid expense involved with basically starting their implemantation from scratch.

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.

Oxide Solutionsprovides the Oxide Web is an interesting and apparently open source cloud-based application which helps you use SEC XBRL information. 

This is an overview of that open source tool.

You can use Oxide which is a Flex application, a link is provided from the Oxide Solutions web site.  Fiddle with it, you can determine for yourself if this application provides value to you.