Digital Financial Reporting

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.

WappWolf is one of the most creative things I have seen in a long time. This videobriefly explains what WappWolf does. Basically, what WappWolf does is provide "stuff" which allows you to put together a workflow.  I tried WappWolf by within a few seconds uploading a file from my computer to my FTP site.  Very straight forward and easy.

I have mentioned Yahoo Pipes before. And I have mentioned M2M before.  This company has an M2M platform.

Imagine a business reporting platform which wires all this type of stuff together.  Business users will not generally get what I am talking about, and there is no need for them to get it.  Some cleaver software vendor will eventually get it, build it, and when business users see this they will use it.

Don't be fooled because all you see is rotating images, uploading files, extract PDF text.  Use a little imagination!

This HL7 presentation talks about what you need for interoperability to be achieved: technical interoperability, semantic interoperability, and process interoperability.  Process = workflow.

Don't think in terms of technical process/workflow.  Imagine business workflow components and/or accounting system workflow components.

Stay tuned if you don't see what I am talking about.  I will dig into this more later.

Simon Sinek gave a great presentation at TED: How great leaders inspire action. In the presentation he points out that great innovators think the opposite from everyone else. I recommend this 18 minute video to anyone who is working to make digital financial reporting a reality.

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.