Digital Financial Reporting

The key to making XBRL extensibility work correctly is the notion of "controlled flexibility". Having those extending XBRL-based taxonomies do so randomly can never work. Further, if one can make XBRL's extensibility serve you it seems that an entirely new class of software application is possible.

This is what I mean.  First off it is important to understand the spectrum of flexibility. There are two extremes:

• Form: At one end of the spectrum you have a form which is an example of 100% control.  With a form someone specifying some information they want to collect can "specify blanks" and then the user basically "fills in the blanks".  Seems pretty straight forward.  Now, if you think about this a little more you start to realize that you have another layer of control even with a form.  For example, if you have a box that specifies an answer and you mean for the person filling out the form to enter "YES" or "NO"; but you don't control that appropriately and some people enter "MAYBE" then your data fields might be specified and users must fill in each field, but you will have data errors because what the user enters is not controlled appropriately. That is what something like XML Schema Data Types is all about, restricting what someone can enter into a form. Going further, if the form says the user needs to supply the value for "Assets" and also the value for "Liabilities and equity" and those two values must agree, but the form does not enforce that then you can get errors in your data.  Something like XML Schema Data Types cannot enforce even that type of mathematical computation. So the reality is that even with a form where you "fill in the blanks" you still have to do other work to make sure that the quality of the information put into that form is intact.
• Freeform: At the other end of the spectrum you have "freeform". The definition of freeform provided by Google is "not conforming to a regular or formal structure or shape."  An example of freeform is creating a Microsoft Word document such as a financial report.  You have all sorts of issues controlling what a user does (i.e. the user has a lot of flexibility).  From the perspective of the creator, they have a lot of flexibility to "fill out the form" however they see fit because there is basically little constraining what they create.  From the perspective of a consumer of that information; while the information is richer because of the flexibly the user has in providing the information (i.e. they are not forced to fill in a form), using that information poses challenges because of the lack of structure.

But what if there were another way?  What if there was something in between "form" and "freeform"?  Would all information fit into that middle category?  No.  Are there advantages of having a middle category?  I propose that there is.

Let me repeat the definition of freeform: not conforming to a regular or formal structure or shape.

First off, does something like XBRL have a "regular or formal shape"?  Most people would say no, but they would be incorrect.  XBRL does have a formal shape.  If you look at the XBRL Abstract Model 2.0 you can see that formal shape. If you tried to map that XBRL Abstract Model 2.0 to things that exist in the real world you can also see that shape.  I mapped the XBRL Abstract Model 2.0 to my model of a financial report expressed in the Financial Report Semantics and Dynamics Theory.

And I went even a step further.  I tested 100% of SEC XBRL financial filings (all 10-Ks) to see if they fit into that model. Guess what: 99.99% of all representation or model structures and 95.8% of all such XBRL-based filings fit into that structure.

And so, XBRL-based business reports "fit" into a regular, formal structure/shape. But is that enough to capture high quality information?  Well, first understand that XBRL uses XML Schema Data Types to enforce field level data quality.  XBRL uses XML Schema Data Types.  You can use any of the data type restrictions to provide things like enumerated lists of values such as "YES" or "NO", very powerful.  XBRL also uses XBRL calculations and the more powerful XBRL Formulas to enforce mathematical computations.  So those two pieces mentioned above are covered.

Is that enough?  No.

Proof that that is not enough is the quality of today's SEC XBRL financial filings themselves.  They don't have the quality they need.  So what is missing?  Well, here are specific things which are missing:

• Extension points: Where an XBRL taxonomy can and cannot be extended is not communicated in either the US GAAP XBRL Taxonomy or SEC Edgar Filer Manual (EFM) rules.  For example, financial statements have "Assets" and they have "Liabilities and equity".  Should SEC filers be allowed to create an extension at this level in the US GAAP XBRL Taxonomy, creating another category of financial information?  Probably not.  And they generally don't because the financial reporting rules are pretty clear that you cannot.  But, a mechanism which controls where an XBRL taxonomy can be extended is not provided.  But what if such a mechanism to control extension points was provided?
• Extension rules: How to properly extend the US GAAP XBRL Taxonomy is not controlled nearly enough.  An example of a seemingly good control mechanism can be a good example of the possibilities.  First of, suppose that every report element in the US GAAP XBRL Taxonomy were categorized into one of the 10 elements of a financial statement defined by the FASB in the US GAAP Conceptual framework: Assets, Liabilities, Equity, Revenues, Expenses, etc.  Next, when an extension is created, the filer creating the extension must SPECIFICALLY associate that extension with one of those 10 core elements of a financial report?  That is an example of control. This can be achieved using XBRL definition relations.  Now, that list is not sufficient in my view, I use those 10 elements of a financial statement to make a point. Controlling extension rules is possible.
• Unchangeable concept framework:  Imagine that a report had some sort of a "skeleton" or framework which every report followed.  The fundamental accounting concepts is that framework for financial reports.  Testing of SEC XBRL financial filings shows that financial reports follow this framework 98% of the time.  It makes no sense for a filer to change the category of a concept.  For example, if the US GAAP XBRL Taxonomy defined a concept to be an "Asset" and a filers used that concept on the cash flow statement, that would make no sense.  It would likewise make no sense for a filer to change the relations between two of these concept categories.  For example, "Assets = Current Assets + Noncurrent Assets"; why would a filer need to change that relation?  Now a filer might not have noncurrent assets because they provide an unclassified balance sheet.  That does not break the rule, that rule would not apply to them. If a filer did have a classified balance sheet but did not report noncurrrent assets, that would likewise not break this rule because noncurrent assets can always be imputed by: Noncurrent assets = Assets - Current assets.  (If a filer does provide a classified balance sheet, they will ALWAYS provide assets and they will ALWAYS provide current assets.  And so this set of unchangeable concepts and unchangeable relations between concepts controls extensibility by making sure SEC filers representing their information don't break that framework.
• Leverage common relation patterns: The elements which make up the "regular or formal structure or shape" have common patterns.  These common patterns can be leveraged for many, many purposes.  One of these purposes is managing extensibility.  This is what I mean.  First, there are two primary categories of relation patterns. The first are "member arrangement patterns" or "whole-part" type relations. The second are concept arrangement patterns: roll up, roll forward, adjustment, variance, hierarchy, etc. (For the back of your mind, another use of these common relation patterns is rendering of information in human-readable form.)  Again, controlling extensions can be achieve by specifying the patterns that extended information fits into.  For example, it makes little sense to have a roll up which has no total or two totals.

It might be the case that I am missing something, but I am pretty certain of two things:  (1) If a system is not controlling the things mentioned above problems will occur which relate to how different creators of information extend an XBRL taxonomy; (2) if the things above are specified appropriately, it will control the flexibility offered to users of the system to employ and that controlled flexibility offers very useful between what is offered by a "form" and what is offered by "freeform" information gathering systems.

While I am providing SEC XBRL financial filings as an example of how controlled flexibility can make extensibility work for financial reporting, what I am showing is more generally useful.  Perhaps a taxonomy has different extension points, different extensibility rules, a different unchangeable concept framework, and different common relations patterns; it is the creation and management of these which will make extensibility work for other business reporting domains.

Finally, the notion of "extension points", "extension rules" and "patterns" are not my idea.  These ideas were origionally discussed as a group of us created the US GAAP XBRL Taxonomy Architecture.  That document talks about the notion of "diciplined extensions".

For more information see this blog post.

Don't understand Big Data?  Here is a fantastic timeline which explains the history of big data. A good way to go through this is to start at the very beginning of the paging thing in the center of your screen and check out the pieces you like.  The slides link to source information which you can drilldown into as you might desire.

Yesterday I posted this.  I adjusted this creating the following significant updates.

1. I added presentation relations for everything.
2. I created one schema which combines everything together, see "All Combined" below.
3. I changed the cycles attribute on the arcroles I am providing from "none" to "undirected". I was getting some cycle errors; the cycles are OK where I have them.
4. I updated the Financial Report Ontology a bit, adjusting and adding some things.

Here are the most current versions: (If you are not technical but interested in this, you want this HTML.)

• All combined: XSD | HTML | XML
• Financial Report Ontology (fro): XSD | HTML | XML
• Topics: XSD
• Disclosures: XSD
• Key ratios: XSD
• Fundamental accounting concepts (fac): XSD
• Fundamental accounting concept rules (XBRL Calculations): XSD
• Fundamental accounting concept rules (XBRL Formula): XBRL Formula
• Map US GAAP XBRL Taxonomy to fundamental accounting concepts: XBRL Definitions
• Arcroles (which provide semantics): XSD

What I want to do next is decouple the schemas and linkbases, making this more modular.  I have documentation and references for a lot of stuff, want to provide that and references.

Most of this information is in a Microsoft Access database. All the XBRL is generated via software, no XBRL taxonomy editor necessary.

I was trying to articulate a financial report ontology using OWL.  I did not really like what I created because I did not understand it and very few, if any, other business users understood it.  How can you tell if the ontology is correct if business users don't understand what they are looking at?

And so I did the same thing using XBRL (prototype).  See the graphic below. This is not perfect, but it is WAY, WAY closer to being understandable.  Plus it meets the needs of business users because computations can be easily articulated using XBRL Formula and XBRL calculation relations.

While I am not totally convinced that I can really call this an ontology, it certainly has a significantly higher level of semantics than most XBRL taxonomies that are being created.

Here is the XBRL taxonomy schemas for the pieces of this:

• Financial report ontology (fro): http://www.xbrlsite.com/2014/Protototype/fro/fro.xsd | HTML | XML
• Topics: http://www.xbrlsite.com/2014/Protototype/fro/topics.xsd
• Disclosures: http://www.xbrlsite.com/2014/Protototype/fro/disclosures.xsd
• Key ratios: http://www.xbrlsite.com/2014/Protototype/fro/keyRatios.xsd
• Fundamental accounting concepts (fac): http://www.xbrlsite.com/2014/Protototype/fro/fac.xsd
• Fundamental accounting concept rules (XBRL Calculations): http://www.xbrlsite.com/2014/Protototype/fro/fac-rules.xsd
• Fundamental accounting concept rules (XBRL Formula): http://www.xbrlsite.com/2014/Protototype/fro/fac-formulas.xml
• Map US GAAP XBRL Taxonomy to fundamental accounting concepts: http://www.xbrlsite.com/2014/Protototype/fro/fac-MAP-to-USGAAP-definition.xml
• Arcroles (which provide semantics): http://www.xbrlsite.com/2014/Protototype/fro/fro-arcroles.xsd

The primary thing that I was trying to do in OWL is to get one graph of all the "things" which play a role in a financial report.  Well, I now have that.

I am not saying that all of this is correct.  Got something better?  Let me know.  Have ideas for improvements? Send me an email.

The document Arriving at Digital Financial Reporting All Stars: Summary Information provides information obtained from a detailed analysis of 6674 SEC XBRL financial filings. The purpose was to determine what it takes to actually be able to make use of reported financial information.

While not a scientific experiment or perhaps not perfect in any regard; this exercise was very useful and yielded pragmatic insight into creating and consuming digital financial reports and other types of digital business reports.  This information is useful to professional accountants wishing to position themselves well for the future of financial reporting.  It is useful to software vendors who might choose to build software to support digital financial reporting.  It is useful to regulators who might be considering implementing systems which leverage XBRL-based digital financial reporting for compliance purposes. In is useful to other organizations who might want to experiment with XBRL-based digital business reporting within their organization.

The following is a summary of specific conclusions I have reached and other key insights I have obtained which I believe might also be useful to others. Details can be obtained from the above PDF.

• Currently 19% of all SEC XBRL financial filings analyzed satisfy minimum criteria and 95% are 5 or fewer errors from meeting criteria
• Specific identifiable and observable reasons exist for every issue pointed out
• Using SEC XBRL financial information need not and should not be a guessing game
• Minimum criteria are not judgmental or subjective in nature
• Validation and verification of the seven criteria are 100% automatable
• Current generation of digital financial report creation software has systemic issues
• Need for a framework for tuning the quality of SEC XBRL financial filings
• Need for a roadmap for tuning the quality of SEC XBRL financial filings
• My next level of criteria
• Any system which desires to implement XBRL-based digital financial reporting or XBRL-based digital business reporting can learn from SEC XBRL financial filings

The last point is the primary, key point.  If someone wants to make XBRL-based digital financial reporting or XBRL-based digital business reporting work within their systems, SEC XBRL financial filings provide plenty of clues to help figure that out.

I have this vision.  It is a simple vision.  It is an achievable vision. It is a useful vision.  Here is the vision:

Click for larger view of image

Imagine that every software vendor passed 100% of the seven minimum criteria which I outlined in this analysis.  What would that mean?  It would mean that fundamentally usable information would be provided by all those SEC XBRL financial filings.  Yes, it would mean that.

But it would mean much more.  What it would mean is that the concept of digital financial report would have been proven to work.  What it would mean is that a digital financial reporting beachhead would have been established. What it would mean is that a framework for improving the quality of these digital financial reports even more would have been identified.

I will not go quite as far as saying that for the first time an open system has successfully been implemented, but it is a step in that direction. More on that later.

What it would mean is that about 34 different software vendors have provided off-the-shelf software which was used by 6,674 different public companies to report information to a government regulator and that information can safely, reliably, predictably be used via 100% automated processes to provide reported financial information to countless analysts and investors. This is a meaningful exchange of information.

Tell me that is not useful.

But we are not quite there.  The analysis shows that 19% of SEC XBRL financial filings meet this vision, 1281 All-Stars as I call them. But even more encouraging is that 95% of all SEC XBRL financial filings are 5 or fewer errors from achieving this goal. So the vision is already within grasp and what is necessary to achieve that vision is clear.

This is where we currently are in terms of all stars by generator (software vendor or filing agent): (average is 19%; green is at average or above average)

You can interpret this information however you want.  This is how I interpret the information.  If a software vendor or filing agent does not have 100% all stars, then there is some sort of systemic problem with the software.  Full stop.  Now you can play the blame game all you want, try and pass the buck.  That helps nothing.  Solving the problem helps.  Achieving the vision helps.

If a software vendor does not understand this or believe this, then they certainly don't understand the bigger opportunity.  This is only the tip of a much larger iceberg. Smart digital financial reporting tools are the future.  If software cannot control these extremely basic things, there is no way that software can provide smart digital financial reporting functionality.  If software does not pass the hurtle of these seven basic criteria, there is little hope that the software will ever be helpful to a professional accountant.

Achieving the vision helps the SEC be successful, it helps the FASB be successful, it helps XBRL US be successful, it helps public companies who are mandated to use XBRL be successful, but most importantly it helps software vendors be successful.  The software vendor would have created something that works and is beginning to show signs of usefulness.  It will also help the software vendor understand what professional accountants really need.

If software vendors pull this off, achieve the vision above, create something that really works; the software vendors might be able to expand the market: some 8 million private companies, 360,000 not-for-profits, 90,000 state and local governmental entities, and that is just financial reporting in the US. This is not about "save as XBRL".  This is about machines assisting professional accountants in the creation of a financial report which is an extremely complex task. In digital financial reporting the output can still be a paper-based financial statement.

If software vendors don't achieve this vision, the market will certainly not expand, it might even contract.  Case in point: the legislation to eliminate the XBRL filing requirement for smaller reporting entities, market reduction of 60% by some accounts.

Now, it would be best if all software vendors and filing agents worked to achieve this vision.  Some will, some won't.  The enemy is not each other, the enemy is the status quo.  What if only one achieves 100% all-stars?  What will the market do?  What will likely happen is that some will achieve this goal, some won't.

I have provided this information to every software vendor and filing agent contact that I have.  I have provided the information to the FASB, the SEC, XBRL US, and many others.  New software vendors are also entering the market who want to fundamentally change accounting work practices.  Be interesting to watch what happens. Be interesting to see who grasps this opportunity.

Am I nuts?  Maybe.  But that is what I see.  What is your view?