Digital Financial Reporting

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.