Digital Financial Reporting

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.

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?

Here are some nuances that most people don't really understand when it comes to modeling XBRL.  This is one example of a theme.  The theme relates to consistent meaning within an XBRL taxonomy.

The Detail

Consider the following SEC XBRL filing taxonomies.  These are renderings which I generated. Here, we will be looking at the networks (i.e. extended links with the same role) and hypercubes. This is more about providing you with some detailed information to look through should you find the need.

• Ebay: This balance sheet is within a network, it has a [Table], that table has [Axis] and line items.
• All these are the same: You can look through all these and they are all the same as Ebay.  All these filings were created by Edgar Online.
• Another way to look at the same thing: You can look at the same thing in yet another way.  Each extended link has a hypercube called "Statement [Table]", each hypercube has at least one [Axis] and exactly one set of [Line Items].
• More Inconsistent: This set of SEC XBRL filings is more inconsistent. Some have [Table]s within the networks, some don't, some use [Axis] and [Line Items] on the [Table]s, some don't.

The Summary

So what is going on here and what is the point? The big picture is that XBRL and the SEC allow you to model an XBRL taxonomy with the following options:

1. Within a Network (i.e. an extended link of a specific role) which contains no hypercube. (Qwest does this.)
2. Within a Network which does contain a hypercube but each hypercube has the same name. In the examples above you see the hypercube "Statement [Table]" being used over and over. (Citigroup does this, 34 networks, "Statement [Table]" used 34 times.)
3. Within a Network which does contain a hypercube and each hypercube has a different name. (Carnival is the closest to this, but many of the hypercubes don't have [Axis] and/or [Line Items].) 

The Analysis

What is going on? What do these different options or varieties actually mean? What is the difference between one or the other? The answer is no one really can know because it is not documented.  Are these wrong? No, none is wrong as they all pass SEC XBRL validation.  Are these right? Sure, they pass validation, but they may not be the best of practices.

Basically, these are possible ways to construct an XBRL taxonomy:

• Network alone.
• Network with one hypercube (and therefore they can have the same name).
• Network with multiple hypercubes (this required different hypercube names).

How will each of these be rendered by the SEC XBRL rendering engine?  Where does the network show up in the rendering engine and where does the hypercube show up?

Why can't these be consistent?  What possible downside could result?

Important Characteristic of Hypercubes

Hypercubes do something useful that not using hypercubes can never achieve.  You have to articulate the [Axis] and the allowed values for each [Axis] which are called [Member]s or [Domain]s in the taxonomy.  Further, you can only use what has been specified in the taxonomy.  Whereas, there are no constrains on things like the entity identifier and period portion of context; they are unconstrained by the hypercube.  This has two affects.  First, users have no real idea of what you want reported unless you document it somewhere else because it is not documented in the taxonomy.  Second, you get stray fact values showing up in things like calculations because the hypercube cannot constrain entity identifier and period.  Or, another way of looking at it is that the more you use hypercubes the more control you have over what facts are used by the hypercube...that is what the hypercube does is constrain the concepts, [Axis], and [Member]s.

Bottom Line

Properly build hypercubes are easy to render because you can use the [Axis], the concepts, the [Domain]s, and the [Member]s to help in the rendering process.  Frankly, there is really little need (i.e. no need) for both networks and hypercubes to have semantics.  Hypercubes are better than networks because hypercubes provide more useful features/characteristics.

Many times when I hear people discuss XBRL or evaluate how XBRL is suited for a task I get the sense that they are looking at XBRL from what amounts to an incorrect perspective. This is particularly true to XBRL as it is applied to financial reporting.

The Big Picture

XBRL is a tool which must be applied properly to achieve an agreed upon set of domain objectives. If the domain objectives are ambiguous the results will also be ambiguous. Creating a logical model of a domain is a technique to ensure a technical implementation will work correctly. If a sound logical model is created, any implementation which follows that logical model correctly will work, no matter what technical implementation or syntax is used.  However if the logical model is either the wrong model (i.e. the logic is not correct) or ambiguous (i.e. multiple legal implementations can be created within the logical model because the model is flawed and allows undesired variations), undesired outcomes will be the result.

Some reasonable questions one might ask relating to the financial reporting domain might be:

• What is the logical model for financial reporting? 
• Who specified that logical model?
• Is that logical model the logical model which we desire?
• Is there undesired flexibility in that logical model allowing for undesired results which employs that model?
• How well do the domain master craftesmen employing the XBRL tool understand the tool?

XBRL is a Tool

The first important thing to recognize about XBRL is that it is a tool. Yes, XBRL is a tool, just like a saw is a tool. You can take advantage of a tool in different ways.  And while it may only take a few hours to learn how to use a tool, it can take more time to become competent with the tool and even more time to master the tool.

A saw is a tool.  You can learn the basics of using a saw in less than an hour. But does that mean that you have the skills to build a high quality piece of furniture?  Of course not.  In the hands of a master craftsman a tool can be used to create a beautiful piece of furniture.  In the hands of a lesser skilled individual, what they create with the same saw is likely not something that you would want to put into your living room.

Applying the XBRL Tool to Financial Reporting

Just like the person who has a saw and wants to build a piece of furniture has the responsibility of understanding what they want from that piece of furniture, any domain, such as the domain of financial reporting, it is critical to have a clear vision of what they want to get out of the tool.

What does financial reporting want to get out of XBRL? Well, the US GAAP Taxonomy Architecture explains this to a degree for SEC financial reporting. Section 2, the Domain Model explains what that implementation of XBRL wants out of XBRL. But is this what the financial reporting domain wants? And how do you know that the desired functionality will result, without undesirable characteristics?

That same document, section 3, explains the Logical Model employed by the US GAAP Taxonomy to help figure out the physical implementation of the domain wants from XBRL. Section 4 of that document goes on to explain the Physical Model. The physical model is basically the physical implementation of the logical model to meet the needs of the domain.

Logical Model is Key

The logical model is key to getting the implementation correct. If the logical model works well, any good implementation of that logical model can potentially work, no matter what syntax one uses.  If a physical model or implementation is based on a poor or an incorrect logical model, the physical implementation cannot possibly work as desired.

There are two moving pieces relating to that logical model. First, the logical model needs to be the logical model that you desire.  Is the logic of correct?  Is the logic the desired? Second, the logical model needs to work as desired. If the logical model is ambiguous and allows for undesired variability, two people using the same model can have two different end results.  Both are legal under the logical model.

Let me give an example using Microsoft Excel.  You have all used Excel spreadsheets.  Under that logical model a workbook has one or more spread sheets. A spreadsheet has rows, columns, and cells which are the intersections of a row and a column.  A workbook cannot contain a cell.  A cell cannot contain a workbook.

A Good Logical Model Can be Implemented in Any Syntax

A clue that a logical model is good is that it can be modeled in any syntax.  XBRL is a syntax. RDF/OWL is also a syntax. To a domain user, syntax is not really as relevant as consistent semantics (i.e. meaning). Inconsistent semantics is bad because you simply cannot make up for inconsistent semantics in any syntax.

Logical Model for Financial Reporting

What is the logical model for financial reporting? Well, in the case of SEC XBRL financial reporting, that is determined by the US GAAP Taxonomy Architecture since the US GAAP Taxonomy is based on that.  The logical model is also based on the EDGAR Filer manual and whatever else the SEC might allow.

Is that logical model the correct logic?  Well, that is for those in the financial reporting business domain to decide.

Is that logical model unambiguous (meaning can users create different and potentially incompatible implementations based on that one logical model)?  Inconsistent implementations are quite easy to see and evaluate against a good logical model.

UML for Documentation of Logical Models

Many times logical models are documented with UML (Unified Modeling Language). UML is a communications tool.  It allows business domain experts to communicate with technical experts.

Where is the UML model for financial reporting? Here is a draft UML model for financial reporting. Is that the right logical model? This is certainly not for me to say. If the model is mine, than it is proprietary and therefore other proprietary models would likely be created and this would defeat the vision of one electronic model for financial reporting used globally.  Is there one logical model for financial reporting?

If you are interested, this blog post shows the sorts of things which one might include in a logical model. These have nothing to do with the XBRL technology, they have to do with the business domain.

Financial Reporting Domain is Responsible for the Logical Model

The financial reporting domain is responsible for creating the logical model they need for financial reporting. Technologists can provide the tools, such as XBRL, to implement that model.  Technologists can also help the domain users create their model.  But the logical model is the responsibility of the financial reporting business domain. The financial reporting domain needs to determine the logic.

This responsibility cannot be passed on to others, nor would you want to pass this important responsibility on to others. To do this some domain users need to master the tool to a certain degree.

The challenge here is that it takes a master craftsman to build such a logical model and most financial reporting experts are not also logical modeling experts.  That is the tightrope which must be successfully traversed.  It takes technical experts and business domain experts working together to create such a model. Applying the technology incorrectly is not the technology's fault. Ultimately, that responsibility rests with the business domain.

Here are some inline XBRL examples.  Some people call inline XBRL "iXBRL". Either way, here are the examples.  I cannot speak to the quality of these examples as I don't have an inline XBRL validator yet.  I did run these through the W3C validator for XHTML.  That validator has issues with the inline XBRL concepts in these samples/examples because it is not aware of the inline XBRL schemas.  Anyway, these can get you started if you are curious about inline XBRL (iXBRL):

• IASCF: A financial statement.  Note that this has an XML extension so it will not render pretty in your browser.  Let's you look at the guts.  But if you download the file, change the extension to ".html", it will render nicely.
• VT Software: Sample regulatory report/financial statement.
• State Factbook: This is just a table of information.  (iXBRL is not only for financials.) Be sure to check out the sample extraction application for iXBRL here.
• XBRL International: Sample US SEC filing.

More information on iXBRL later.