Digital Financial Reporting

This post begins a series of posts where I point out the benefits of the Business Reporting Logical Model.  If you are unfamiliar with the Business Reporting Logical Model, be sure to check out my straw man implementation of this model.

In my straw man implementation of the Business Reporting Logical Model, I created a prototype application in Excel called the "Hypercube Viewer" which allows you to extract and render XBRL instance information. The prototype application does not actually read XBRL, rather it reads an info set generated by an XBRL processor which supports the Business Reporting Logical Model.  The prototype starts by reading an RSS feed which contains links to XBRL instances.  My straw man implementation uses this RSS which points to two XBRL instances: ACME Company and Sample Company.  Here are the info sets for those two companies:

• ACME Company: Fact Groups, Measure Relations, XBRL instance
• Sample Company: Fact Groups, Measure Relations, XBRL instance

If you follow my blog, you may have heard about the State Fact Book prototype which I had created to test some things. I created this prior to the Business Reporting Logical Model being available. I did use XBRLS in creating the State Fact Book which has many characteristics of the Business Reporting Logical Model.

What I wanted to do is refactor my State Fact Book XBRL example to use the Business Reporting Logical Model. To do that, I made two changes to my State Fact Book XBRL implementation.  First, I corrected the data I was using to fix the error in the US Census Data which I had discovered and the Census Bureau subsequently adjusted. Second, I modified the State Fact Book taxonomy to use the Business Reporting Logical Model. I then generated the info sets for the three XBRL instances I was using which you can see here:

• Population Trends: Fact Groups, Measure Relations, XBRL instance
• General Information: Fact Groups, Measure Relations, XBRL instance
• Financial Information: Fact Groups, Measure Relations, XBRL instance

Next, I organized those three XBRL instances with the XBRL instances above into a new RSS feed which you can see here. This RSS contains all 5 XBRL instances, all created using the same Business Reporting Logical Model. I then pointed a new version of the Hypercube Viewer to that new RSS feed to see if the Excel application would read those new info set files generated by the XBRL processor.

After fixing a few bugs in the State Fact Book XBRL taxonomy and the application, my Excel application would read all five sets of information and render the sets consistently in the way I would have expected the information to be rendered.  You should consider trying this for yourself.

For the intellectually curious who understand a little about Excel, you may want to consider reverse engineering the Excel application to create something which reads those info sets.  In doing so you will realize the benefits of the consistency enabled by the Business Reporting Logical Model.

Even if the Business Reporting Logical Model never becomes an XBRL International standard, everyone creating an XBRL taxonomy will have to use something to ensure consistency in the XBRL taxonomies created. This is less important if you do not use taxonomy extensions, it is vital if you do allow extensions. Those creating extensions have to be guided to create extensions which are consistent with the taxonomy they are extending.

What I learned from this exercise is that some of the things I thought were important are not really important at all. I have always tried to keep taxonomies consistent by using the presentation linkbase.  It is clear to me now that that is the wrong approach.  I also thought that you would never get consistency unless you ditched a number of the pieces of XBRL such as typed members and tuples.  That really is not necessary. You do need to control those pieces and others, but you don't necessarily need to ditch them all together.

Consistency is key.  The Business Reporting Logical Model does allow for creating consistency.  There are certainly other alternatives. While smart software engineers can figure out all the ins and outs of XBRL and generate an info set with information similar to the ones generated for my straw man implementation of the Business Reporting Logical Model, the "channeling" of XBRL syntax which the model does makes it significantly easer to process the XBRL syntax to generate that info set. Once you have the right info set, you can convert that into whatever syntax you might like. The syntax is really unimportant.  It is the consistency of the business semantics which is important. The Business Reporting Logical Model is one way to achieve that consistently.  There are others.

In order to both test the Business Reporting and Financial Reportin Logical Models and demonstrate how to implement SEC XBRL filings using those models, I created a mapping from the logical models to the SEC XBRL implementation.  You can get that mapping here. If you wanted to contrast that to the mapping of my straw man implementation, that mapping can be found here.

What is easy to see from the mapping I created is that it is very possible to use these logical models in creating SEC XBRL filings and their related XBRL taxonomies.  What is harder to see is why that is beneficial.  To see the benefits, one would need to use a software application which leverages the logical models, making it so you don't have to struggle with XBRL at the syntax level.

As I have mentioned on a number of occasions, the XBRL International Taxonomy Architecture Working Group is working to create a business reporting and financial reporting logical model.  I am part of that working group.  It is my hope that XBRL International will make modifications to the next version of the Financial Reporting Taxonomy Architecture (FRTA) to address:

• interoperability issues between financial reporting taxonomies (i.e. why is the  SEC, IASCF, EDINET having to reconcile their taxonomy architectures, the Interoperable Taxonomy Architecture Group), 
• XBRL usability issues (i.e. XBRL is too hard for business users to use such as for SEC XBRL filings), 
• system implementation issues (i.e. why can't the FDIC and the SEC XBRL implementations work together; why does the SEC have to write 400+ rules to implement XBRL within their system; why don't vendors agree on SEC XBRL error messages)
• software creation issues (i.e. why is it so hard for software vendors to create XBRL software which business users can actually use)
• taxonomy extension issues (i.e. why are SEC XBRL company extensions so inconsistent)

This blog post looks into possible future scenarios of XBRL adoption, taking the realities of the list above into consideration.

What more details about these sorts of issues and how to solve them? If so, you are in luck. I created what I am calling a straw man implementation of the business reporting and financial reporting logical models in order to both show the problems and why they are problems, and to show a solution to the issues outlined above. The straw man implemention also proves the issues are all solvable, showing specifically how to solve them.

Straw Man Implementation

Here is information about my straw man implementation:

• Overview: This is a good starting point, it provides an overview.
• Semantics to XBRL Syntax Mapping: This maps the logical model semantics to its XBRL syntax in my implementation.
• Processing Model: This shows the processing model or steps in working with the business reports. 

I do realize that this is a lot of information. All this information is the first step in doing what I want to do. The next step is to take this detailed information and summarize it down to its essence in order to show business users why the efforts of the XBRL International Taxonomy Architecture Working Group to create this logical model are a good thing and why a global standard is better than the proprietary solutions to the XBRL issues (which I mentioned in this blog post) which will be created should XBRL International not address these issues.

As I see it, this is the future of XBRL, be it via a global standard (my preferred option) or proprietary solutions (if nothing is done).

Take a look at this information and let me know what you think.

More and more people are expressing an interest in XBRLS. If you are interested in XBRLS, then you will likely be interested in my new category for this blog: Business Reporting Logical Model.

Stay tuned for more information which will be coming soon!

XBRL has proven itself as a useful tool which regulators can leverage.  But will XBRL ever achieve broad use (i.e. mass adoption) and become something any business user can make use of to exchange information with another business user, independent of IT department assistance?

Exchanging information is tough, but IT departments can pretty much get any business system to talk to any other business system with one hand tied behind it's back.  XBRL provides leverage in this process even to IT departments, implementations of XBRL such as the US Federal Deposit Insurance Corporation (FDIC).  There is ample proof of this. But not every business has the budget of a big government regulator.

So, there are "paths" through XBRL. What I mean by path is that XBRL is a general purpose specification. No one uses all of XBRL and the same thing can be achieve in different ways. These different paths cause interoperability challenges, particularly when you use XBRLs best feature: extensibility. Each implementation today picks their own path which takes highly skilled XBRL experts and can be expensive. But what if one global standard path was created which software vendors could use to implement something workable for business users?

Is XBRL destine to remain only a tool IT departments can leverage? Or will business users ever be able to make use of XBRL: one business user exchanging business information with another business user without the involvement of the IT department?  That is why I am interested in XBRL.

Here are the scenarios which I believe might come to pass. It is hard to say which will play out, only time can answer that question.  But, understanding the scenarios provides clues if one desires to help their desired scenario to unfold.

• IT departments leverage XBRL.  This is where we are today. Why would the status quo magically change on it's own?  It won't. More time will not make XBRL usable by business people. Someone is going to have to do something different for the status quo to be different.
• Proprietary XBRL implementations.  Is it possible to make XBRL easy for business people to use? It is absolutely possible.  The problem is that there are many paths within XBRL to achieve this objective. Also the skills needed to pick the right path through XBRL take too much time to obtain. If individual software vendors implement systems which make use of their selected path through XBRL to achieve business user to business user information exchange, we end up with what the business intelligence (BI) world has which is BI systems which don't talk to each other. BI systems are not interoperable across BI software vendors. You can work around this, but that takes time and costs money. Perhaps this is the destiny of XBRL.
• Proprietary XBRL monopoly. One specific vendor could get lucky or do a good enough job to achieve the status of Microsoft Excel or Microsoft Word as a de facto standard path through XBRL.  One company would certainly like this, the one whose proprietary implementation became the standard; they get to become the monopoly.  This isn't all that bad, but it does have its drawbacks.
• De facto XBRL standard. Maybe one vendor will create their path through XBRL and other vendors will adopt that path.  For example, what if, say, XBRLS caught on and multiple vendors implemented that making some businesssystems able to talk to some other business systems for ad hoc business information exchanges. Some interoperability is better than no interoperability. Perhaps this could happen, it happened to PDF. It is very possible to create products which would yield what business users need from XBRL, there is increasing evidence of this. A de facto XBRL standard would be fine. The control of this whether this happens is really in the hands of the market. Not a bad thing.
• Ad hoc interoperability via global XBRL standard. Having some global standard path through the technical complex XBRL quagmire, rather than each implementation having to figure out their own path, build their own infrastructure; each implementation solving the same problem over, and over, and over. This certainly does not make business sense (i.e. look at all what the SEC system had to do to make XBRL work). But does XBRL International have the funding, the motivation, and the other pieces of the mix to create this path. Time will tell.

Let me be very, very clear about my point here. My point is not that XBRL is complex. It does not have to be complex. All you need to do is give up features. That sort of misses the point of using XBRL though. My point is not that XBRL can't work, in fact XBRL does work, there are more and more business systems which use XBRL but are not interoperable being built all the time.  It is not that every XBRL system has to be interoperable with every other XBRL system. The point is not that XBRL does not have value, it certainly does.

The point is that if a business person picked up XBRL and tried to exchange business information with another person, they could do it but it would be far to expensive.  All they need to do is throw a lot of money and time at the IT department and they could get whatever they might desire, and XBRL certainly contributes to what they could have.

But what if a business person could achieve what they need without the cost.  That is the point. Effeciency.  The more effecient XBRL is, the broader the adoption XBRL will realize. What could be achieved with XBRL is similar to what the personal computer and the electronic spreadsheet provided the business user: freedom from the IT department.

This is not about diluting XBRL and changing its nature as a general purpose tool.  XBRL International consciously chose to solve the problem of business reporting not just financial reporting. I think that was the right choice. But, there would be advantages to an easier to use path. This is not about creating something simplistic or taking features away. It is not about creating "THE" standard path through the XBRL quagmire, it is about creating "A" path which will likely fit 98 percent or more of all system use cases. Then, the business people can pay the technical people to solve 2 percent which does not fit, should they have that need. This means that 98 percent does not need to be reinvented every time XBRL is implemented.

Do you see other possible scenarios?