Digital Financial Reporting

I was made aware of a web site which provides a data feed of SEC XBRL financial filing information expressed in RDF. The web site is the SEC Edgar Linked Data Wrapper. Nothing magical really, it is simply a conversion of one syntax to a different syntax which some people might find preferable.

• SEC filing home page
• XBRL instance from SEC
• SEC Interactive data viewer form
• RDF from this site
• Per XBRL Cloud

Over the years I have done a lot of fiddling around with RDF/OWL in trying to grasp how to best make use of XBRL.  Just as XBRL is a tool, RDF/OWL is a tool.  As is said, "If the only tool you have in your toolbox is a hammer, then everything looks like a nail."  Not that having a big tool box and a lot of tools makes one a great craftsman; understanding which tool is the best tool for a particular job does have its advantages.

While I do get the big picture when it comes to RDF/OWL and intuitively I understand RDF/OWL has lots of power which can be leveraged when working with XBRL, I regretfully don't get the details very well yet.  But, I do understand a little.  More importantly, I am investing to understand more because I grasp why RDF/OWL will be so useful.

The Financial Report Semantics and Dynamics Theory breaks down a financial report into logical pieces. The US GAAP Taxonomy and SEC XBRLfinancial reports are instantiations of "digital financial reports". US GAAP, as defined by the FASB, has semantics.  All these things can be tied together semantically using RDF/OWL.

This is a link to where I am currently in hooking all this semantic information together, this ontology for a digital financial report.  It is really only the beginnings of an ontology. The XML file can be hard for humans to read, but it is not really meant for humans; it is meant for computers to read.  This diagram can help you understand what is in that ontology currently:

If you are interested in understanding what is under the hood here, Stanford University makes a tool available called Protege which can help you visualize RDF/OWL ontologies. The tool is rather technical so most business users won't relate to it very well most likely.

What does all this mean? Well, it means that financial reporting is about to go through a big change.  While the XBRL technical syntax enables that change; XBRL is not the change. If you don't understand what terms like "semantics" and "metadata" mean, you are at a disadvantage because you don't understand the moving parts of the puzzle.  If you are an accountant obsessed with the financial concept of an SEC XBRL financial report (a form of myopia like the marketing myopia which we all studied in college) you will be out of place when this new paradigm takes hold.

Not quite sure what to do?  This is a good place to start: Guide to Verification of an SEC XBRL Financial Report. 

It may not seem like the right starting point, but trust me when I tell you that it is exactly the right place to start. Like Stephen Covey says in his book 7 Habits of Highly Effective People,

"Begin with the end in mind."

In a previous post, I mentioned the notion of a "disclosure object". Others agreed with this notion and the possible need to connect the disclosures made via a [Text Block] and the same disclosure made via a [Table].  Basically, both a [Text Block] and a [Table] are two ways of disclosing the same information.

Additionally, it seems to me that a "disclosure" made within a financial report is something that is required by law or deemed to be necessary per the professional judgment of an accountant.  Once one understands that some disclosure must be made, those creating a disclosure or presenting information on the face of a financial report have options as to how they can make that disclosure or present that information.

For example, SEC rules say that a public company needs to provide a cash flow statement; but the reporting entity can decide if they want to use the direct or indirect method for providing that cash flow statement.  This choice can be driven by preference or professional judgment.  Other disclosures work the same way.

The point here is that there is a difference between a disclosure which is required or deemed necessary and how that disclosure is made. They are two different things, it seems to me.

And so, for a specific required or necessary disclosure, there are many different approaches to satisfying the need for a disclosure.

Therefore, it seems to me that there is yet another notion which is necessary here when working with financial reports in addition to a disclosure or disclosure object.  That piece is the actual "implementation" of the disclosure or disclosure object.

I refer to this implementation of a disclosure as a disclosure template.  Further, I have created a prototype of disclosure templates which you can use to understand what I am trying to get at here.

Now, I may be using inappropriate terminology at this point, I am still thinking through these ideas.  But, what I can clearly see is the difference between a something like the US GAAP taxonomy which contains all possible options for a disclosure (theoretically, that is what I think is trying to be achieve), the actual approach to make a disclosure or present information, and the actual disclosure itself.

Another way of looking at this is through the lens of how accountants review a financial statement today.  When I was an auditor, we always read through a disclosure checklist to make sure that a financial statement contained all the things that it was supposed to contain.  For example, here is a link to a disclosure checklistprovided by Deloitte.

Imagine a physical link between the disclosure checklist and the actual financial report via the implementation of that disclosure in the financial report.  Literally, a physical link which can be navigated by a computer software application.  How useful would that be?  Really useful, I believe.

Or how about taking this even deeper into the workflow during the creation of the financial report.  For example, imagine an application like this CCH AutoCheck Disclosure Checklist integrated with your financial report creation software application.

Basically, imagine that all this workflow was connected.  You would physically move from the instantiation of a disclosure or presentation of information within a financial report back to the accounting system and other information used to create the report; everything is connected.  You can do this today but the connection is not a physical connection, it is mainly information which is contained in an accountant or more likely an entire accounting teams collective brain(s).  The only way to navigate these links is manually because a computer cannot navigate the links.

But what if they could?

In fact, I think that is exactly how financial reports will be created in the not to distant future.  The role a disclosure template plays in this process is that it is a 100% correct disclosure.  Those creating financial reports don't change templates, they change the properties of a template.  Disclosure templates are defined by folks like the Financial Accounting Standards Board (FASB), the International Accounting Standards Board (IASB), maybe even the SEC, etc.

Those instantiating a disclosure within their financial report do so by determining if they need to make a specific disclosure, picking an approach to disclosing the information per available options, and then they change the properties of that disclosure to fit their reporting entity.

Think of a template in Visio.  If you want to put a circle in your Visio diagram, you don't re-invent a circle each time.  You pick a shape template for a circle, you drag in onto your Visio diagram, and then you change the properties of the circle template, setting the background color, the size of the circle, etc.  Same idea for creating a PowerPoint presentation.

Users can still create their own disclosure objects from scratch if they need to make a disclosure which is totally unique.  No problem, they can do that also.  But they will not do this for every disclosure.

Not sure if this makes sense to you now, I have to think about this some more and figure out how to articulate it better.  A working software product which actually does this would go a long way toward explaining what I am trying to communicate.