Digital Financial Reporting

I hear a lot of people, far too commonly auditors, make statements like, "I don't care about creating SEC XBRL financial reports correctly, all I need to do is comply with the EFM rules," Or something to that affect.

Personally, I see things a little differently.  For example, if 97.9% of all SEC XBRL financial filings do something one way and only 2.1% take some other approach and that other approach used by that 2.1% is not rational, is illogical, and contradictory; that approach could be difficult to justify.

While it is true that Edgar Filer Manual (EFM) rules are not provided for structuring your financial report representations correctly and while it may be true that the US GAAP Taxonomy Architecture does not do the best job of articulating allowed and disallowed relations; that does not mean that there are not logical and illogical representations of such structures in digital financial reports.

Understanding Model Structure Rules is a document which helps those trying to become XBRL master craftsmen understand the different categories of report elements which many less knowledgeable people incorrectly refer to collectively as "tags".  It also helps you understand the sensible, logical, rational relations and avoid contradictions, inconsistencies, and communicating information which simply make no sense at all in your SEC XBRL financial filings.

Here is an example. Consider this screen shot: (see in XBRL viewer here)

Improper model structure

If you open the larger image by clicking on the screen shot above you will see that this SEC filer put a [Member] within a set of [Line Items] which makes no sense at all.

The model structure is made up of distinct categories which all the report elements of an SEC XBRL financial filing fit into: Network, Table, Axis, Member, Line Items, Concept, Abstract.  There are logical and sensible relations between these different report element categories.  Understanding these report element categories and the relations between them will help you realize that the term "tag" does not belong in your vocabulary when it comes to digital financial reporting.

Avoid creating absurd representations of your SEC XBRL financial filings.

For the past four months I have been poking and prodding 7,160 SEC XBRL financial filings.  All were 10-K filings. If you follow my blog, the results of this poking and prodding has been made available piece-by-piece.  This document provides a summary of my analysis. The document pulls all this information into one place, summarizes my conclusions, and provides some recommendations for those creating taxonomies or building systems which utilize XBRL.

The primary drivers for the analysis was:

1. Understand how to build better XBRL taxonomies
2. Understand the dynamics of concept extension by SEC public company filers
3. Understand how to create quality SEC XBRL financial filings
4. Understand the dynamics of comparability of SEC XBRL financial filings

The following is a summary of the results of my analysis:

• 99.9% pass XBRL technical syntax rules 
• 86.1% pass Automated SEC EDGAR Filer Manual (EFM) rules
• 97.9% pass US GAAP Taxonomy Model Structure 
• 95.8% pass US GAAP Domain Level Rules 
• 79.1% provide Roll up rules for balance sheet, income statement, cash flow statement 
• 99.2% provide a detectable "root of reporting entity" so that information can be properly discovered using automated processes
• 98.0% report 51 fundamental accounting concepts and those concepts adhere to 21 unchangeable relationships

 Go to the PDF document above which provides a "Conclusions Reached" section and a "Recommendations" section.

This blog post is part of a project on the Semantic XBRLgroup in LinkedIn.  The goal of the project is to convert some XBRL formatted digital financial information into RDF/OWL. The intent is to use the proper financial report semantics to structure the RDF, enforce that structure to the extent possible using OWL, and then be able to do useful SPARQL queries against that digital financial report information expressed in RDF/OWL.

This blog post is intended to be a resource to help those working on that project to understand the financial report semantics, have access to information which helps them understand the process and steps, provide test cases and examples, etc.

NOTE!!! Because this is a work in progress things may not tie together as well as they need to.  For example, terminology is adjusted as new things are learned and examples may use a mixture of old and new terms.  The goal is to tune and get all these sorts of things in sync as part of this project.

Understanding the semantic representation

The first step in this process is to understand the semantics which we will be working with. The document Financial Report Semantics and Dynamics Theory summarizes those semantics. You can see those semantics implemented here within the XBRL Cloud Evidence Package. 

• Here is a rendering of a balance sheet which is one "component" of a financial report. 
• Here is the fact table which lays out the facts and their characteristics for the report component.
• Here is the model structure which shows the relations between the facts within the fact table and provides other details.
• NEW!!! Here is a ZIP file which contains an Excel spreadsheet application which reads numerous model structure and fact table infosets and loads them into the spreadsheet.  It also uses the models structure, the fact table, and additional rendering information to create a prototype, but limited, rendering.

So that is a representation of this information in human readable form.  All those pieces relate to this reference implementation of an SEC XBRL financial filing. From that page you can get to all the pieces of that digital financial report. (NOTE!!! Something else which is helpful is this HTML version of that digital financial report. HOWEVER, that HTML is a older example so the HTML will not tie exactly to the current reference implementation.)

Another view of the exact same information is an XML infoset of the fact table and the model structure.  PLEASE NOTE!!! The element names are not totally correct in these examples.  There are extra attributes which don't belong in the infoset.  There are pieces which SHOULD be in the infoset which are not there.  Remember, this is a work in progress.

The Financial Report Ontologyis a greatly expanded set of financial report semantics. Again, this is a prototype.  Pieces of this are shown in OWL, but this is NOT what the end product will look like.  What you see today is the best that a CPA can do given a good understanding of financial reporting, a good understanding of XBRL, and a basic understanding of RDF/OWL.  This ontology will evolve to what it needs to become.

Something which is helpful in understanding the overall represention which the Financial Report Ontology will represent, or rather the best guess for now, is this VUE mind map. The point of this mind map is to provide something helpful to business users.  The formal representation of the ontology will likely be in UML or OWL or whatever the technical people decide works best.  But business users MUST be able to understand the ontology in their terms.  Eventually, I believe that will be within working software applications.  Until that software is build, some method to explain the moving parts of a financial report is necessary.  This is my best attempt to communicate such information.

Further, we are NOT ARTICULATING 100% of this financial report ontology in this project.  This project is focused on only the financial report level semantics at this phase.  The goal of this phase is to convert only the XML Infosets into RDF.  That is all for this first phase.  And so, we will be dealing with the report components, facts, characteristics which describe those facts.

Implementation model

The reference implementation is of an SEC XBRL Financial Filing.  Such filings make use of the US GAAP Taxonomy.  The US GAAP Taxonomy uses specific structures and terminology.  Those terms are not financial reporting related, nor are they totally XBRL related.  They basically bridge a gap.  This terminology uses term such as Network, Table, Axis, Member, Line Items, Concept, and Abstract.  You can see these terms explained here.

If you notice the XML infosets, they follow this representation within the fact table and model structure. That could be a mistake.

The XML infosets were generated by XBRL Cloud who has implemented these infosets.  The Arelle open source XBRL processor has an implementation of the model structure infoset, but not the fact table infoset at this time. What would be highly desirable is to have the Arelle open source XBRL processor output both the XML infosets and output RDF.

Prototype output

This blog post has some experimentation with serializing XBRL as RDF and running a SPARQL query to return some useful results.

This RDF, which uses this OWL ontology, when loaded into Protege, and you try and run these SPARQL queries, do work.

For phase 1, I propose a goal of the following:

1. RDF of the reference implementation fact table and model structure which loads into Protege correctly.
2. OWL ontology which supports the RDF.
3. SPARQL query which returns the model structure of a report component.
4. SPARQL query which returns the fact table of a report component.
5. SPARQL query which tests the model structure and fact table against the OWL ontology to make sure the RDF follows the semantics of a financial report (relates to relations between report components, facts, characteristics as expressed by networks, tables, axis, members, concepts, abstracts.