Digital Financial Reporting

Today when you go to look at XBRL tools, what you find is XBRL technical syntax editors.  This includes XBRL taxonomy creation software and XBRL instance creation software.

What is needed, in my view, is more along the lines of semantic modeling tools.  Your typical business users will never be able to work with XBRL at the XBRL technical syntax level; nor should they want to and nor should they have to.

Clearly the first generation of software tools and applications needed to be low-level functionality which allows other developers to work at the XBRL technical syntax level.  As software matures, business user applications such as applications used to create SEC XBRL financial filings and their supporting taxonomies will be more along the lines of semantic, structured modeling tools; not the XBRL syntax editors which we see today.

The IFRS Foundation released business rules in the form of XBRL Formulas for the IFRS taxonomy. I would expect that the US GAAP Taxonomy will not be far behind.

I have been a long time proponent of XBRL Formula to express business rules which XBRL calculations cannot express.  The fact is, it is extremely unlikely that you can create a quality XBRL instance without using XBRL Formula or something like it to be sure the relations between facts reported are correct.

For instance, the IFRS Foundation classifies their XBRL Formulas into the following categories (see page 2 of this document):

• Cross period validations – whereas formulae will ensure that calculation of roll-forwards from beginning balance over the total changes over the period equals ending balance.
• Earnings per share validations– whereas formulae will ensure that the EPS calculation of the Profit (loss) and the average number of shares provides correct results.
• Axis aggregation validations – whereas formulae will ensure that members of an axis are calculated to their parent members properly (if applicable for a given axis and only if the filer structured their members in a summation-like hierarchy).
• Fact equivalence validations– whereas formulae will ensure that if two facts are tagged by different IFRS Taxonomy concepts but, conceptually represent the same thing, that they are equal. Usually, one of them is in a dimensional context, whilst the other one is not (e.g. ‘Aircraft’ = ‘Aircraft [member]’ in ‘Property, plant and equipment [axis]’ with primary item ‘Property, plant and
  equipment’).
• Common accounting equivalence validations – whereas formulae will ensure that general principles of accounting are applied correctly.
• Positive / negative fact validation – whereas formulae will ensure that if a fact is expected to be reported as an amount greater or equal zero it is not negative and vice versa.
• Percentage warnings– whereas formulae will ensure that the formal of percentage fact is appropriate according to the XBRL specification.

If you are not verifying these types of things to be sure they are correct, it is highly likely that they are not.  Things may seem correct because you don't run the validation against your document. But if you do validate against business rules expressed using XBRL Formula, you might be surprised what you have missed.

In a previous blog postI explained that an [Axis] is "a means of providing information about the characteristics of a fact reported within a business report."  Looking at a very simple area of an SEC XBRL financial filing helps to better understand how [Axis] work.

For a complete set of the SEC XBRL filings examined for this analysis, grab this Excel spreadsheet or this PDF. You can follow along using this PDF which walks you through the various scenarios discussed. It is hard to make each of these images fit in the narrow blog page.

So, let us consider the document and entity information of an SEC XBRL filing which is relatively consistent. 

Scenario A: Basic document information:   Here you see the basic [Axis] used by many filers when reporting document and entity information.

All of the other scenarios build on this base case scenario where a filer is reporting document and entity information.  Again, visual images are provided in this PDF which are helpful in understanding the different scenarios.

Scenario B: Legal Entity [Axis] is Explicit:   This filer explicitly adds the axis "dei:LegalEntityAxis" to the document and entity information [Table] (as compared to the scenario above where the filer did not even create a [Table], using only the concept, reporting entity, and period [Axis]). This raises the question, why are these two SEC XBRL filings using different [Axis] on what amounts to basically the same information?

Edgar Filer Manual Section:  The EFM states in essence that if you do not explicitly provide a "dei:LegalEntityAxis" it is assumed or implied that all information reported relates to the "consolidated entity" (which is represented in the US GAAP taxonomy by the member "dei:EntityDomain". Personally I believe that being explicit is better, particularly now with XBRL viewer and analysis software not being very mature.  Further, generic off-the-shelf XBRL software does not understand what the SEC is or is not implying.

Scenario C: Legal Entity [Axis] is Implied:   So in essence, even if the an SEC filer does not explicitly provide the dei:LegalEntityAxis with the value of dei:EntityDomain, which represents to consolidated entity; it can be implied that the information relates to the consolidated entity. This scenario repeats scenario A, just showing that the legal entity, although it is not physically there, semantically it actualy does exist.

Scenario D: Legal Entity [Axis] is Explicit, Class of Stock [Axis] Explicit:   This SEC filer makes both the legal entity explicit, and also provides a class of stock [Axis].

Edgar Filer Manual Section:  The EFM states in essence that if you do not specify which class of stock a fact relates to, then it is implied that the fact relates to all classes of stock; basically implying a class of stock [Axis]. This seems to be consistent with how the legal entity axis works.

Scenario E: Legal Entity [Axis] is Implicit, Class of Stock [Axis] Implicit:   This SEC filer provides neither a legal entity nor a class of stock [Axis]; however, because of the SEC rules both these [Axis] can be implied.

Scenario F: Legal Entity [Axis] is Implicit, Class of Stock [Axis] Implicit; Scenario [Axis] is explicit:   This SEC filer provides neither a legal entity nor a class of stock [Axis]; however, because of the SEC rules both these [Axis] can be implied. This filer does, however, provide a scenario [Axis] explicitly.

Edgar Filer Manual Section:  It seems to be the case that if no scenario [Axis] is provided, that the scenario us-gaap:ScenarioUnspecifiedDomain is implied per the EFM.

Scenario G: Document information and entity information in separate [Network]s:   The majority of filers report document and entity information within the same network.  Yet here, two filers report document information in one network and entity information in a different network.  From a business semantics perspective, as can be seen from the [Axis] of the facts; which network is used makes no difference in the characteristics of the information.

Scenario H: Does the Entity Registered Name, Document Type, or Document Fiscal Year Focus Really have a Class of Stock?:   The [Member] or value of an [Axis] articulates a characteristic of a fact.  An [Axis] relates to an entire fact table.  Does it really make sense that concepts such as entity registered name, amendment flag, document type, and document fiscal year focus to have a class of stock [Axis]?  Or, would it make better sense to model facts which share characteristics in on [Table] and other facts with different characteristics in a different [Table]?

The Bottom Line: 

Does cash and cash equivalents, receivables, payables, long term debt, or other such balance sheet line items have a class of stock?  If you model a balance sheet with a class of stock [Axis] that is precisely what you are articulating.  What does have a class of stock is preferred and common stock, not the entire balance sheet. 

This is just like property, plant, and equipment or debt or some other detailed disclosure being modeled with an [Axis] differentiating the classes of that line item; but the balance sheet itself does not have that [Axis], only the disclosure does.

The document and entity information is pretty basic, but thinking about the characteristics which are associated with these basic facts can help you grapple with other more complex areas of an SEC XBRL financial filing.  Think about the semantics of what you are communicating.

I created a prototype application using Microsoft Excel which allows you to see even better how using infosets, rather than working with XBRL directly, can make your life easier.  The Excel prototype is a great learning tool also.  It lets you better see what the information articulate by XBRL communicates.

The prototype hooks directly to the metapatterns, business use cases, comprehensive example, and SEC reference/model samples/examples which I have created. It lets you have a closer look at the meaning of information articulated within an XBRL taxonomy and XBRL instance. All the business use cases which I have run across are covered.

The rendering does not work as well as I want at this point because it does not leverge the information models (the metapatterns) yet and it does not support more than one [Axis] on columns or rows.

All the infosets have been pre-processed for these samples/examples in advance for these examples (complements of XBRL Cloud) which contributed two style sheets which transforms their infosets to the format which I use. That means that this application does not even need to use an XBRL processor. The infoset format is my strawman implementation of the Business Reporting Logical Model (BRLM) created by the XBRL International Taxonomy Architecture Working Group.  I have since abandoned that implementation format in favor of the US GAAP Taxonomy Architecture model which is used by SEC XBRL financial filings. That model is documented here. The two models are, however, interchangeable.

If you look within SEC XBRL filings you can see that their creators still have confusion about what exactly an [Axis] does.

As explained in on the SEC XBRL Financial Filing Glossary and Logical Model, an axis is:

A means of providing information about the characteristics of a fact reported within a business report.

Nothing scary or technical about that explanation and that is all an axis really is.  Now, some people refer to an axis or [Axis] as seen in XBRL taxonomies using other terms which can make them seem confusing.  Some common terms are: dimension as used in the XBRL Dimensions specification, aspect as used in the XBRL Formulas specification, measure as used in the multidimensional model and in the Business Reporting Logical Model, to name most.  I will use [Axis] as used in the US GAAP Taxonomy and in SEC XBRL financial filings.

But what exactly does an [Axis] do?  Walking through this will make exactly what an [Axis].  Consider the following two facts:

The two facts have values.  What do those values mean? Well, you don't really know, you need more information. So, you add an [Axis] to provide additional characteristics. Now, consider this next screen shot:

So above, I added the Concept [Axis] and provided values for each fact to both explain and differentiate the two fact values.  The value of an [Axis] is called a [Member]. We still don't have quite all of the information we need yet, this next screen show will make that clear: 

So now we are getting closer and closer to something which is becoming useful. Knowing the period and the entity reporting the fact, in the case of SEC XBRL financial filings the CIK number, is commonly desired.  In fact, it is so common that XBRL requires these three [Axis] on every single fact: the concept, the period, and the reporting entity.

But, do we have enough information?  Well, that depends.  Take a look at the next screen shot and we will bring up a few more things about an [Axis]. 

XBRL provides the ability to add even more, in fact any number of, [Axis]. Here we added the business segment [Axis] and indicated that our fact values both relate to the the consolidated entity.

When do you know if you have enough [Axis]? Well, that is dependent on whether you have communicated all the business information you are required to communicate. A fact is comprised of a value and all the characteristics which describe that value. There is nothing technical about what an [Axis] does so don't let a poor software implementation or some consultant who speaks using $150 an hour jargon tell you any differently. Yes, it really is that simple and straight forward.

Rather than complicating this explanation with more details, I will call this good.  You can find more definitions of the report elementswhich make up an SEC XBRL financial filing in that same glossary.

I will go into some of the more common mistakes I am seeing in SEC XBRL financial filings later.