Digital Financial Reporting

I mentioned the data points model in a previous blog post. Someone posted a video to XBRL-Public which explains the data points model approach in detail.  You can find this video here.

While this video is long (1 hour and 26 minutes), is detailed, and discusses data modeling and the data points model from the perspective of the FINREP taxonomy; this video will help one grasp the important general issues related to expressing information in XBRL.

You can distill the message of this video into one concise statement:

Build consistent and explicit data models.

What I have created and documented in my Modeling Business Information Using XBRL document follows those two key principles. So I could not agree more with those who support the data points model.

I have updated the core financial integrity analyzer prototype which I made available last year.  The prototype is built in Microsoft Excel and hooks to numerous sets of SEC XBRL financial filings.  This version runs on version 6 of the Microsoft XML parser, the older version runs on version 4 of that parser.

This prototype works on most 10-K and 10-Q filings.  It looks for core financial pieces such as "assets", "liabilities and equity", "net income" and "net cash flow" to see if they exist.  Most filings have these concepts.  The prototype does not handle all situations correctly (i.e. that is why it is a prototype and not production quality).  But, it does helps one understand the notion of core financial reporting semantics, what core financial reporting semantics exist and what they look like.

I have updated the logical model viewer so that it works with version 6 of the Microsoft XML parser.  I also fixed some bugs which makes this prototype more stable. (Note that this older version works with version 4 of the Microsoft XML parser.)

The prototype works with the:

• Metapatterns: Documentation | RDF list
• Business use cases: Documentation | RDF list
• Comprehensive example: Documentation | RDF list
• SEC Model/Reference implementation: Documentation | RDF list (additional documentation)

The logical model is explained in the document Modeling Business Information Using XBRL.  This document contains the most current information. 

There is one potentially confusing thing worth pointing out. All this logical model work started with what was called XBRLS.  While the ideas behind XBRLS were good, the ideas have matured.  The Business Reporting Logical Model (BRLM) developed by the XBRL International Taxonomy Architecture Working Group is the best model which I have seen.  I have applied those ideas to SEC XBRL financial filings, changing only the terms of the BRLM, applying the US GAAP Taxonomy terminology.  The two primary differences are terms "Table versus Hypercube" and "Axis versus Measure".  I realize that this can be confusing, sorry for any inconvenience.

SEC XBRL financial filings are representations, not presentations, of the information they contain. Many accountants see these filings as presentations.  They look at the XBRL as simply the Word document or HTML version of the report with the different pieces of the report "tagged" with XBRL. In fact I have seen training material which shows exactly this, usually written by accountants who likewise don't really grasp XBRL.

And I guess I should not be surprised by this view of XBRL because there is even software which works in this manner, "tagging the presentation" in order to fit the completed Word or HTML presentation into XBRL.

This presentation orientation is not appropriate.  SEC XBRL financial filings do have a presentation relations perspective.  But they also has a calculations relations perspective and what is called a definitions relations perspective. Now, don't confuse the linkbases or XBRL technical syntax with the meaning or semantics and don't confuse the explicit semantics of XBRL Dimensions and the implicit semantics when XBRL Dimensions is not used. These are complex conversations and I don't want to get into a deep discussion about that; I do want to make two points.

The first point is that there are three different relations, not one.  That alone provides enough evidence to show that XBRL is not a presentation.  Sure, presentation is part of the representation but it is only part and in XBRL it is a very weak part of the representation.  For a long time I have pointed out that the XBRL calculations are impotent because they cannot be used to express all the computations within an SEC XBRL financial filing. The presentation relations are even more impotent, when it comes to expressing a presentation a user would expect for an SEC XBRL financial filing.

The second point is the use of the term "tag".  There are a lot of reasons using the term "tag" is a bad idea.  First off, the term "tag" is at best a syntax term many people associate with XML.  XBRL really has no "tag" from the syntax perspective and it certainly does not have tags from the semantics perspective.  But let's pretend I am wrong and say that tags do exist (even though they don't).  What does the tag represent?  A network? A [Table]? An [Axis]? A [Member], [Line Items], a concept, an abstract concept, the reported fact itself, an attribute of the fact such as the units or number of decimals?  Hopefully you see my point. The term "tag" is too general  even if the term did exist. Fact is, you could stretch things and say that a tag exists from the XBRL technical syntax perspective, but from a semantics or meaning perspective the term means nothing.

An SEC XBRL financial filing is a representation, or model, that a computer can understand.  It is true that the XBRL technical syntax "delivers" or "exposes" the information to a computer, but it is the semantics or meaning which the computer is trying to understand.

There are two "layers" of meaning or semantics, it seems to me, when it comes to an SEC XBRL financial filing.  The first layer is the business reporting layer which uses things such as networks, [Table]s and [Axis] to break up the components of a filing into discrete pieces of the model or representation.  The second layer is the financial reporting semantics of the filings: does the balance sheet contain assets, does the balance sheet contain liabilities and equity, does assets equal liabilities and equity, does assets foot, does liabilities foot, and on and on; all those semantics which accountants know exist within a financial report.

Your representation, your model needs to work.  Your model may be different that some other SEC filers model because, say, you are a bank and they are an airline.  This is not a problem for XBRL to express in fact that is a core strength of XBRL, its flexibility to do just that.  But again, each of those models need to work, for the bank and for the airline, and the core semantics of both models should agree where they should agree.

Does a bank have assets?  Sure.  Does an airline have assets? You bet.  Does assets = liabilities and equity? Does assets foot?

That is what your representation, your model, of your SEC XBRL financial filing is all about.

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.