Digital Financial Reporting

Someone made me aware of Anzo Express which is one of the most advanced digital business reporting interfaces that I have seen.  If you want to understand Anzo Express, go to this web page and watch the first tutorial "Your First Simple Anzo Application".  It is 15 minutes long and starts out a bit slow, but trust me; it is worth watching the entire video.

Cambridge Semantics, the maker of Anzo, describes Anzo as:

Anzo Express is a complete spreadsheet data management solution. It enables users to link data from multiple Excel spreadsheets and relational databases together in real-time for data collection, collaboration, and reporting. Anzo Express also includes a state-of-the-art Web dashboard tool so that you can easily share your integrated Excel data with your colleagues.

One of the most critical things to understand which is said in the video above is the statement, "... this isn't a Google search, it is a really sophisticated semantic search ..." or something to that affect.

Most people still don't really understand the difference between a Google search of mainly textual information and a truly semantic search which leverages a rich set of metadata.  Once they see the benefits of a semantic search, they will begin to understand that statement and will understand the true power of semantic or "smart applications".

In prior posts I looked at XBRL and databases and basics of querying XBRL-based information. This blog post synthesizes what I have discovered into a concise set of conclusions which I have reached based on what I have discovered.  This is a summary of those conclusions: 

• Querying from physical files not good for query performance; pre load information into some sort of database: Having to "move" XBRL documents (XBRL instance and XBRL taxonomies) from the SEC web site to your computer to use that information in a query is not efficient in terms of query performance.  Information needs to be moved from the SEC web site into some more accessible place, such as a database, significantly improves performance. Basically, this is an internet bandwidth issue.
• Querying an information exchange format is not good for query performance; preprocess information into a more queriable format: XBRL is an information exchange format and is not optimized for query. To achieve good query performance the information contained within an XBRL instance and all related XBRL taxonomies need to be converted from the information exchange format into a more queryable format. Basically, having to "resolve" all the information at the time of the query is inefficient.  Staging information you want to query into a more queryable format vastly improves query efficiency because the XBRL processor does not have to "resolve" all the relations at query time.  Everything was resolved in advance. 
• Querying business information without some sort of query language makes queries harder to create; use an information set specific query language:  Extracting information from some database with properly formatted information is still hard for business users and even developers.  Or said another way, if a business user or developer had a information set specific query language, querying would be much simpler. This includes setting up the correct indexes, organizing additional useful metadata correctly, understanding the different "joins" which are commonly used, etc.
• Querying business information without having dealt with information set idiosyncrasies in advance can make querying problematic; resolve these idiosyncrasies in advance: A simple example will make this point clear.  SEC XBRL financial filings are submitted to the SEC.  Those submissions can be amended.  If you do a query against an information set which has both the original filing and the amended filing which updates that original filing and this idiosyncrasy has not been dealt with you will get incorrect query results. Dealing with this idiosyncrasy at the time you perform the query reduces query performance. Resolving them in advance improves performance.  This is not the only idiosyncrasy of SEC XBRL financial filings; it is an example of many such idiosyncrasies. For example, another SEC EDGAR system idiosyncrasy is that searching for "us-gaap:Revenues" is not as simple as it seems because many different concepts could have been used to report revenues.

Having efficient and effective queries comes from prior planning.  Minimizing system idiosyncrasies and being sure you provide what is necessary to easily extract meaningful information from your XBRL-based information set is best done proactively rather than reactively.  Test, test, and then test some more!

An updated prototype of the Financial Report Ontology (FRO) has been made available.  You can get to this most current version of the prototype here:

http://www.xbrlsite.com/2013/FinancialReportOntology/Prototype03/

If interested, you can follow discussions about the FRO on the Semantic XBRL LinkedIn Group.

In a prior post I talked a little about XBRL and databases. In this post I want to go a little deeper and talk about querying the financial information reported using XBRL which is found in databases.  There are several key things I want to point out.

I am fiddling with the business segment, legal entity, and geographic area breakdowns. 

The first point I want to make it that you can read this information from the XBRL presentation relations, XBRL labels, and XBRL taxonomy schema(s) which contain this information.  Reading this information is possible, but you have to pull all these pieces together.  You could use an XBRL processor to do that.

Or, you could simply read an XML infoset such as this which has had all that information pulled together for you. If you are a bit of a programmer, using XPath axes are a great way to walk these infosets to work with specific sets of information.

I used XML infosets generated by XBRL Cloud to read information about the business segments, legal entities, and geographic areas of the 7160 public company 10-Ks I am analyzing.  This Excel spreadsheet has that information.

Another point I want to make relates to the problem of inappropriate extenson concepts and how that hurts querying information.

Say I want to search for information reported about sales reported in the geographic area which represents the United States.  The SEC provides a taxonomy with country information. That taxonomy "country" has the element with the name "US" which represents the country the United States. In an XBRL file, the value would look like "country:US".

If you go through the Excel spreadsheet above or you query SEC filings, you find "country:US" used 479 times. If you were to look at this in a database, it might look something like this if you queried for reported facts which relates to the US:

 This is what that information looks like within SEC XBRL financial filings:  

So sure, you do get the 479 SEC filers who properly used "country:US" as shown in the first graphic.  In addition you get 184 other variations of how "United States" is represented.  The namespace which preceeds the report element name, such as "iphs:" indicates that the filer created their own concept (as opposed to "country:" which mean that the report element came from the SEC taxonomy.  Even if the different filers spelled the report element name exactly the same, say "UnitedStatesMember", it is a different concept.

What you see is the problem of SEC filers creating their own concept to represent something which the SEC already provides. This makes it extremely challenging to query SEC XBRL financial filings and return meaningful results.  Can this little issue be worked around?  Sure it can.  But the real problem is that it is not just this one concept "country:US" where there is a problem.  This problem exists with virtually every concept reported by SEC XBRL financial filers to some degree.

Some reported facts are worse than others.  The most consistent reported facts are things like "dei:EntityRegistrantName" which is required and where inbound SEC validation tests to see if that required concept exists.  100% of filers comply, due to the validation/verification process used when a filing is submitted.

Some reported facts such as "us-gaap:Assets" are used by 98% or more of SEC filers. A success rate of 98% is pretty good.  But, when you have, say, 500 different reported facts, a 2% error rate, and 8,000 SEC filers; that adds up to 80,000 errors.  Inbound validation rules created by the SEC can minimize the number of errors.

What is worse, there is no real reward for properly using "country:US" and no penalty for a filer who creates their your own extension concept which makes using information harder.  Perhaps RoboCop will resolve this unfairness.

So finally I will repeat my mantra about meaningful information exchange an point out that proper inbound validation provided by the SEC can significantly reduce errors: "The only way a meaningful exchange of information can occur is the prior existence of agreed upon semantics and syntax rules."

There is a direct correlation between good rules and meaningful queries.

If I can find errors within filings after they get into the SEC system; these errors can also be found by inbound verification/validation processes PRIOR to allowing a submission to go through.  Finding and forcing SEC XBRL financial filers to fix these errors prior to the SEC accepting the filing will vastly improve quality.  Not all errors can be found in this manner; however many more than are being found now could be found.