Digital Financial Reporting

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.