Digital Financial Reporting

For about a year now I have contended that SEC XBRL financial filings (10-K and 10-Q) have a set of core financial semantics.  I summarized these last (and best) in my Financial Report Semantics and Dynamics Theory. Until now I was the only one that had code which proved these semantics, and my code was not commercial quality code.  That changed today.

Today, I ran those same core financial semantics rules over the same set of 8098 SEC XBRL financial filings using a commercial off-the-shelf software application.  I expressed these semantic rules using their rules language and ran the rules using their rules engine, and I got the same results using that software application that I got using the software I created.

I want to try and run the rules against my entire set of test cases; as of now I have only spot checked because I cannot execute the rules in batch mode.  Working on that. 

More to come...

Many who create (or help someone who is create) are over verifying their SEC XBRL financial filing.  Others are under verifying.  Both over verifying and under verifying should be avoided.

If you are over verifying you are doing work which takes time and costs money which either is being done already by software or could be done using software.  For example, if you are checking the type attribute value of a [Table] or [Axis]; that is a waste of time.  Every [Table] and every [Axis] is required to have a type attribute value of string (or xbrli:stringItemType).  Same sort of deal for the period type of a [Table] or [Axis]; both are required to have a type attribute value of "duration".  Pretty much all good software enforces this type of rule.

Another type of over verifying is checking things like the contextRef on facts which have zero semantic meaning.  All that a contextRef does is hook things together, pure syntax.  If you verify that the characteristics of a fact are correct; there is a 100% probability that the "hook" between the fact and those characteristics is correct.  So, why would you verify the contextRef?  No need.

If you are under verifying you are not doing enough work to be sure your SEC XBRL financial filing is correct.  An example of this is not creating XBRL Formulas for (or some other means of verifying) the many, many computations which exist such as roll forwards and dimensional aggregations which an XBRL calculation relation will not verify as being correct. This link is to a report which verifies that the some 40 computations which exist in my model SEC XBRL financial filing are correct. As you know, financial reports have many computations, if you are not creating XBRL Formulas or something else to verify that they are correct, under verifying your filing and the chance that en error exists is high.

Another type of under verifying is not checking the structure of your [Table], [Axis], [Member]s, [Line Items].  A [Table] with no [Axis] makes little sense.  A [Member] mixed in with the [Line Items] makes no sense.  All of these types of tests can be automated, checked by a software application.

In this matrix I tried to summarize the types of things which a computer software application can verify.  The matrix shows the types of report elements in the rows and the properties a report element could have in the columns.  NA means that a report element does not have that property.  Properties which carry semantic meaning are listed.

• Properties which computer software can verify 100% are highlighted in gray. 
• The type of things humans need to verify which are highlighted in yellow,
• The types of things where both human effort and software can be used which are highlighted in light orange.

There are other examples of over verifying and under verifying. But this will get you started figuring out the right mix and if software or humans should be doing the work.

Assurance on XBRL instance document: A conceptual framework of assertions, by Rajendra P. Srivastava and Alexander Kogan which was published by the International Journal of Accounting Information Systems concludes:

we come to a conclusion that there seems to be a general lack of conceptual framework of assertions that would make the assurance process effective and efficient

While you may not be interested in having your SEC XBRL financial filing go through a third party assurance process to verify it is a true representation of what is also in the HTML version; you will want verify for your own edification that it is correctly created.

This paper provides a list of many of the things you will want to do in order to make sure your SEC XBRL financial filing is correct; but it points out that it is not necessarily a comprehensive list. 

The AICPA's Statement of Position (SOP) 09-1 also provides a list, but that is likewise only a partial list.

Other partial lists exist.

But where is the definitive, comprehensive set of detailed procedures which, if executed appropriately, would yield a verifiability correct true representation of a SEC XBRL financial filing?

Stay tuned...I am working on that comprehensive set of detailed procedures.

The Financial Report Semantics and Dynamics Theory is an expository paper which explains the semantics and dynamics of a financial report in terms usable by both business professionals and software developers.

Information within this theory has been evolving for many years.  One big step in the evolution came with the white paper XBRLS: How a Simpler XBRL can Make a Better XBRL. Another big step was the idea of the Business Reporting Logical Model which was based on ideas created by work from the XBRL International Taxonomy Architecture Working Group. Analysis of the many, many SEC XBRL financial filings also contributed.

Many other bits and pieces helped pull the ideas summarized concisely within the Financial Report Semantics and Dynamics Theory.  More and more people are understanding that some sort of logical model is necessary to achieve what is hoped to achieve with XBRL and make working with XBRL easier for business users.

Be sure to check out the prototype financial report creation application which consolidates lots of ideas shared by this blog over the years.

Stay tuned...more to come!  If you care to create a proof which validates or refutes the theory, please contact the document authors.

CompSci had made a free US GAAP Taxonomy search tool available which you can find here. 

This search tool is a sign of things to come: better software! 

One of the things I would like to see, which I will mention to CompSci is that I wish there was more of a focus on differentiating the types of report elements.  What I mean is this.  Take a look at this prototype I created a while back.  Notice the report element categories I am using: Network, Table, Axis, Member, Line Items, Concept.  Those terms are both consistent with the US GAAP Terminology and quite useful in differentiating what you are looking for.

Two interesting searches to try.  Try and a search for Table. Just type the word Table, no brackets as that appears to goof up the search.  Up comes all the tables in the US GAAP Taxonomy.  Now, search on the term Roll Forward.  All the roll fowards show up.  Metadata such as [Table], [Axis], [Roll Forward], [Member], [Line Items] and such is helpful in finding information.

Now, what if you could search on accounting related metadata such as financial statement elements: assets, liabilities, equity, revenue, expense, gain, loss, investments by owners, distributions to owners, comprehensive income?  How helpful would that be?  Take this even farther and what if you could search by financial statement component such as "basis of presentation" and get all the components related to the basis of presentation?  You cannot get that information today because all this search engine understands is the syntax elements and attributes.  But, what if the search tool understood financial reporting and accounting semantics?  Kind of like this which is a prototype which organizes [Table]s organized by accounting topic.  Or maybe this which also shows the financial reporting component.

Nice job CompSci!  Thanks for making this tool available.