Digital Financial Reporting

In this video, Craig Lewis, Chief Economist and Director of the Division of Risk, Strategy, and Financial Innovation (RiskFin) at the SEC, describes the accounting quality model and Robocop.

One thing Craig Lewis mentions is his desire to use Inline XBRL.

Don't understand accounting enough? This video explains the accounting equation: debits on the left, credits on the right...

There is not one SEC XBRL financial report creation application nor application used to analyze all that information which I am aware of which includes a reasoning engine. When these applications begin including the missing reasoning engines which they will eventually include, the true value of XBRL will be revealed.

SEC XBRL financial report creation applications point out that they leverage the following sorts of things but they neglect the last two items on this list:

• Workflow engines. Software developers can build workflow into their applications, but they could also leverage a workflow engine that allows more flexibility and options in routing work. Here is a comparison of workflow engines.
• Content management systems. Financial reports contain "content" or pieces. The content needs to be organized, users need to collaborate in this process of content creation. Content management systems, and there are a lot of them,  can be used to manage this content.  Or, software vendors creating software can create their own content management functionality.
• XBRL processors.  One special feature involved with something like an SEC XBRL financial filing is the ability to interact with XBRL.  XBRL processors do that, and there are lots of those.  Or, software developers can build their own XBRL processor.
• Business rules.  Business rules simply articulate some constraint which can be evaluated as being true or false.  Financial reports flow lots of rules. "Assets = Liabilities and equity" (i.e. the balance sheet balances) is a business rule.  The required disclosures under US GAAP in specific situation are business rules. Disclosures required by the SEC are business rules.  These rules need to be articulated, managed, and any financial report created needs to be evaluated against these rules to make sure you are constructing the report correctly from all perspectives.  Business rules could be hard-coded into software. But business users managing business rules as metadata is much more flexible.
• Reasoning engine or business rules engine. A reasoning engine or semantic reasoner, business rules engine, or reasoner, is a piece of software that both evaluates business rules but also can infer new information.  (Another term for this is a deductive database.) Software vendors can build the ability to evaluate rules within their software, or they can leverage a reasoning engine or business rules engine provided by middle-ware.

Yet, it is this last piece of functionality, the reasoning engine or business rules engine, which will reveal the true value of XBRL. Yet why is it that not one software vendor provides the functionality of a reasoning engine or business rules engine within their software products?

Well, some software vendors do have business rules engines but they don't expose them very well to users.  Most good XBRL processors support XBRL Formula which is both a syntax for articulating business rules and a rules engine for evaluating those business rules.  But the XBRL Formula technical syntax is hard for most business users to use and software vendors implementing XBRL Formula simply throw that at users and expect them to make use of it.  There are better ways.

Further, XBRL Formula which very useful is not sufficient for expressing all the business rules creators of financial reports need.  More is necessary.

The software vendors who implement this sort of functionality will create the "smart applications" promised by the semantic web. These "guidance-based, model-driven, semantic-oriented authoring tools" will have knowledge "baked in" to the application. New knowledge can be added or inferred based on a robust set of business rules. These software applications will be agile and adaptable to ever-changing conditions. These applications will be "integrated" with other systems which both provide the inputs and even those which except the outputs created.

Business users looking for software should be aware of and ask for all of this functionallity.

I did an analysis of [Table]s and the use of [Axis] on those [Table]s for the 7,160 SEC XBRL financial filings (All 10-K filings) which I have been looking at.  Here are some stats (You can get the raw data here in Excel):

• 12% of [Table]s are filer extensions!  Of the 156,494 explicit [Table]s used in the set of 7,160 SEC XBRL financial filings, 17,531 or 12% were filer extension.  Of the total, 75,785 was the table "us-gaap:StatementTable", 49% of all explicit [Table]s used.
• Maximum number of [Axis] is 24: Another surprise was one reporting entity had a whopping 24 [Axis] on a [Table].  What was even more surprising is that the [Table] related to their significant accounting policies which I would have never expected.  You can see the [Table] with 24 [Axis] here. (Shown in XBRL Cloud Viewer)
• 95% of [Table]s have 5 or less [Axis]: Of all the [Table]s in the 7,160 SEC XBRL financial filings, 95% of them have 5 or less [Axis]. This does NOT include the [Table]s with ZERO [Axis].
• [Table] with no [Axis] appears 6,112 times: There are 6,112 [Table]s represented which have no [Axis] at all which makes zero sense. For example, see this balance sheet which has a [Table], but no [Axis] (Shown in XBRL Cloud Viewer)
• 98% of [Table]s have 4 or less [Axis]: If I include the 6,112 filings which have [Table]s with no [Axis], then 98% of all SEC XBRL financial filings have 4 or fewer [Axis].

This is a chart of [Axis] usage (number of [Axis] on the horizontal and number of [Table]s on the vertical; so for example 100000 tables make use of 1 axis, 28000 make use of 2 axis):

 
This is interesting information. What do you think?

I wrote a guest post for The Insight Forum.  You can see that post here.

Inspired by something David vun Kannon said a few days ago on the XBRL-Dev mailing list and something Eric Cohen said a month ago on the XBRL-Public mailing list; I did something which is, I think, rather interesting.

For probably three or four years at least, I have been fiddling around expressing XBRL related stuff in OWL.  That resulted in the Financial Report Ontology which is still a work in progress.

But what if you flipped that around.  What if you expressed OWL stuff in XBRL?  What if one were to express in XBRL all the raw information one needs to create an OWL ontology?  Well, here is a prototype of exactly that: http://www.xbrlsite.com/2013/fro/fro-2013.xsd 

The key piece is this schema which defines a number of arcroles used to define predicates which relate objects and subjects: http://www.xbrlsite.com/2013/fro/fro-arcroles.xsd. The objects/subjects are expressed as XBRL concepts in the XBRL taxonomy schema.

I would suspect that a transformation could be created to turn the XBRL into OWL.  I would likewise suspect that a transformation could turn the same information expressed in OWL to XBRL.

This is either clever or insane.  Don't know which yet!  What do you think?

There are less than 300 "things" in the Financial Report Ontology; I think I will represent all of them using this approach and give the transformation a shot.

So, here is the list of "things" (objects and subjects): http://www.xbrlsite.com/2013/fro/fro-2013_Relations.html

The predicates used to relate the objects and subjects have only been set for a few of the relations.  All relations (subClassOf, hasPart, partOf, equivalentClass) will be set.  There are likely other types of predicates.

The more objects, subjects, and predicates defined; the more useful the metadata. The relations for a set of "graphs" or "networks", see Network Theory.