Digital Financial Reporting

The folks involved with EuroFiling have come up with an interesting idea called the "data points model" approach to modeling information in XBRL. As far as I know, this web page has a bunch of information relating to this approach.  I sat through a presentation which explained the data points model approach and this is what I understood.

Basically, there are three important pieces to this idea:

• Base item: The base item is the concept of that fact.
• Breakdown: The breakdown an [Axis] or dimension of that item.
• Data point: A data point is a reported fact or a "cell in a template".

So for example, base items might be something like: assets, liabilities, equity, revenues, expenses, gains, losses, transfers to owners, transfers from owners.

For the base item "assets", the breakdown might be cash and cash equivalents; receivables; property, plant and equipment, and so forth.

It appears that the goal of this approach is to achieve better flexibility in using the information and understanding facts which go together with other facts.

As part of this approach a "table linkbase" is created.  This piece I don't quite get yet.  What I do get is that no off the shelf software supports this table linkbase and it is not a global standard approach.

This data points model approach is worth watching.  I wish they would better explain this and provide prototypes so one can better evaluate the pros and cons of the approach.

#############################

Introduction to the Data Point Model (DPM)

Data Point Modeling

EIOPA Data Point Methodology

DPM as ISO Standard

Innovation is not about special people in special places thinking up special ideas.  In this video, Charles Leadbeater explains that innovation and creativity comes from passionate users, using new collaboration tools, creating new products and paradigms that companies can't create.

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.

The evidence is very strong that there is a gap between the SEC specified requirement for SEC XBRL financial filings and the true requirement which is necessary for such filings; and this gap is causing confusion.

Further, I have not found one software vendor or one accountant/CPA who can or will state that they are able to meet the true requirement for what an SEC XBRL financial filing needs to be.  Every CPA that I talked to about this agrees that there is a gap.

The graphic below explains. (you can see the a larger version of the graphic here).

Here are the highlights:

• The red line shows the bar that an SEC XBRL financial filing must rise to in order for the SEC XBRL financial filing to be submitted to the SEC.
• The thick black box shows the true requirement needed to be specified. For example, to the right of the red line is the idea that all the roll forwards and dimensional aggregations must actually compute properly.  No one disputes this, it is a very reasonable requirement; but SEC XBRL submission does not verify this.
• Now keep in mind that some XBRL calculation inconsistencies reported are false errors, therefore some inconsistencies can exist but the SEC XBRL financial filing can be correct. That is why the light orange box is shown outside the thick black box.  Yet some software makes users think that all XBRL calculations must be passed for the SEC XBRL filing to be valid.
• The light gray boxes to the right of the red line contain other requirements which are not disputed by the CPAs and accountants which I talk to.  So, for an SEC XBRL financial filing to be truly correct, it must meet the true requirement; not just the SEC specified requirement.
• Clearly it would be better if the SEC specified the true requirement, software vendors implmented that same true requirement, and SEC filings then complied with that same true requirement.
• However, having this gap between the SEC specified requirement and the true requirement causes confusion.  It also puts CPAs in a precarious position.

On the one hand, the red line is what the SEC requires today.  Do you shoot for that level because it sure is easier and the cost of doing so will be less.  On the other hand, if you shoot for the true requirement, your costs will be higher than those shooting for the lower bar.  Besides, there is no software which makes it easy to know if you are meeting the true requirement.

Eventually this condition, the gap between SEC requirment and true requirement, will be rectified and software will exist and then the world will see the true quality of work.

The worse thing about all this is that because there is no software which can help a business user hit that true requirement, XBRL is rather useless to solve any real business problem for business users.  The good news is that the true requirement is knowable and when software does meet this requirement, XBRL will offer a lot to business users trying to make their information actionable.