Digital Financial Reporting

MIT's project ConceptNet 5 helps one grasp where digital financial reported is headed. The web site describes Concept5 as:

ConceptNet is a semantic network containing lots of things computers should know about the world, especially when understanding text written by people.
 
It is built from nodes representing concepts, in the form of words or short phrases of natural language, and labeled relationships between them. These are the kinds of things computers need to know to search for information better, answer questions, and understand people's goals. If you wanted to build your own Watson, this should be a good place to start!

Imagine a similar semantic network for financial reporting. Rather than people having to put things together, computers can put things together for you and you use the result.

Go look at two things which I have provided and then go read about ConceptNet 5 again:

• Financial Report Semantics and Dynamics Theory
• Digital Financial Reporting Wiki

Imagine a "Watson" type system for helping accountants create financial reports or for analyzing financial reports.

These ideas are by no means limited to financial reporting.  In fact, the really cool thing is that pretty soon it will be easy for business users to create their own "Watson"-type systems for performing all sorts of tasks.

Financial reporting is blazing a trail on the semantic web as I see it.  There will be lots of cross over to numerous other domains within business.

Jeopardy anyone?

I mentioned the disclosure templates I am creating in a prior blog post.  I have made a number of enhancements to the disclosure templates and have added additional templates, I am up to 26 disclosure templates currently.

You can get to the current index to the disclosure templates here.

(Note that I am having a little problem with the HTML5 I am using to display the index.  I cannot quite get the HTML5 correct to show the frame on the right side big enough but not end up being rendered in the wrong location.  This is due to my limited knowledge of HTML5.  If you cannot see anything on the left side after you click on something on the right, scroll down to the bottom of the page, you will find it there.  I am trying to figure out how to fix this little glitch.)

The biggest addition to the templates is more visibility into the business rules expressed using XBRL Formula.  Now, there is a list of each rule within the template description.  I also added the business rule validation results to the list of files and XBRL syntax validation results. 

Also, the number of software vendors implementing these disclosure templates has increased by one.  There are at least 4 software vendors who get the ideas behind these disclosure templates.

The next step is to now build more disclosure templates.  I hope to have 50 by the end of the month and 250 by the end of June.  I am using this analysis of 291 SEC 10-K filings to help determine the most common disclosures; those will be the ones modeled first.

Thank you to XBRL Cloud who provides this XBRL technical syntax validation (along with other stuff which makes building these easier), to UBmatrix/Edgar Online whose XBRL processor I am using to verify that the business rules are correctly created, and to CoreFiling whose product Magnify is helpful in verifying the correctness of the disclosure templates and which provides the SEC-type renderings which I use as visualizations for some of the disclosure templates.

If you are a software vendor or an accountant who wants to understand more about these disclosure templates, you know where to find me. There is a lot that you cannot see and a few things which are hard to understand simply by looking at the disclosure template prototype.

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.