Digital Financial Reporting

In a prior blog post I explained a bit about what a semantic reasoner does. This presentation, Knowledge Representation for the Semantic Web Part I: OWL 2 by Pascal Hitzler, Markus Krötzsch, Sebastian Rudolph; provides additional insight on how these technologies will be employed.

Slide 39 of their presentation provides the following summary, beyond simply editing and inferencing, which helps one grasp what semantic technologies are all about:

• Explanation: reasoning task of providing axiom sets to explain a conclusion
  (important for editing and debugging)
• Conjunctive querying: check entailment of complex query patterns
• Modularisation: extract sub-ontologies that suffice for (dis)proving a certain conclusion
• Repair: determine ways to repair inconsistencies (related to explanation)
• Least Common Subsumer: assuming that class unions are not available, find the smallest class expression that subsumes two given classes
• Abduction: given an observed conclusion, derive possible input facts that would lead to this conclusion

Focusing on XBRL as simply a means of some company to provide information to some regulator is missing the point of XBRL.  Company's provided information to regulators before XBRL even existed.  What has changed is that the information is structured, as contrast to a big blob of information which is not usable by computer processes.

Because the information is structured it can be reused.  As David vun Kannon points out on his blog, financial information is "bushy". Bushy basically means metadata is high because the relations between the different pieces of information is high.

Some of these relations are expressed in the US GAAP Taxonomy.  If I had to guess, I would speculate that the ratio between the relations expressed in the US GAAP Taxonomy to the total relations which could be expressed would be less than 10%.  Probably significantly less than 10%.  The exact number does not matter, what matters is that there are opportunities to express more relations.

That is part of what I am trying to do with the Financial Report Ontology, express more relations. I am making that information, that metadata, available free of charge.  The reason is that it is foundational to getting digital financial reports created correctly.  The Financial Report Ontology also can be leveraged by software to make working with digital financial reports easier, and I want that.  Basically, I see much of what you can see in the Financial Report Ontology as basic and necessary for getting digital financial reports created correctly.

One of the first uses of Financial Report Ontology metadata will be the first and fourth items in the list above: explanation and repair of digital financial reports. Many people are frustrated by an inability to reuse all that information provided by public companies to the SEC. Metadata such as "Assets = Liabilities and Equity" (i.e. balance sheets balance) and other metadata can be used to first expose and then correct errors.

But beyond the fundamental nature of the Financial Report Ontology are likely to be many, many secondary use ontologies which will not be free.  These secondary use ontologies will be knowlegebases of significant value.  Those who understand how to create those ontologies and have professional knowledge to put into those ontologies will have the proverbial key to the kingdom of our increasingly digital world.

It takes knowledge of two things to gain the required level of understanding: an understanding of the tools and an understanding of the domain knowledge.  If you don't have the domain knowledge, you will not understand the domain rules which might be expressible.  But if you don't understand the tools, you won't understand what the tools might have to offer or you won't understand how to express your domain knowledge using the tools.

The reason that I have been hammering and hammering those SEC XBRL financial filings is because it is a great way to understand the technology and tools.  I have a good grasp of the financial reporting domain being a CPA.  It has been an investment; and like any good investment you will eventually get a good return.

Investing and gaining a good understanding of the technologies and tools which will form our ever increasingly digital world does take effort, particularly these days.  Tools can be hard to use.  Understanding which path to follow can also be a bit of a challenge due to the misinformation which seems to be prevalent.  But not sorting through all this is becoming increasingly risky.  There is not much of a market for people who make buggy whips when there are no buggies.

One example of secondary use ontologies and metadata is something like the SEC's fraud fighting RoboCop.  If you think through the details of how something like that might work, it helps one see why secondary use ontologies and metadata will be useful. This is not something that a technologist can create on their own.  They will need domain experts to talk with who understand how to communicate with technologists.

And this situation does not just relate to the financial reporting domain. It will work similarly for other domains which go digital.

One big issue with XBRL presentation relations in general and the US GAAP Taxonomy in particular is the vagueness of the "parent-child" relationship which is used to express relationships.

Basically, the arcrole "http://www.xbrl.org/2003/arcrole/parent-child" used to communicate that there is in fact some sort of relationship leaves open to interpretation exactly what that relation is and what it means.  While what is expressed might be clear to those who use the "parent-child" relationship to express something; the intent tends to not come through, be misinterpreted, be inconsistent because of different people working on different areas of a taxonomy, and in general leads to confusion.

Providing some general examples helps one understand why this is a problem. The document A Taxonomy of Whole-Part Relations goes into detail. This presentation (on slide 9) explains the difference between a taxonomy and a partonomy and provides these general categories of relations:

• component-integral object: for example (pedal – bike)
• member-collection: for example (ship – fleet)
• portion-mass: for example (slice – pie)
• stuff-object: for example (steel – car)
• feature-activity: for example (paying – shopping)
• place-area: for example (Everglades – Florida)

It is pretty easy to see that if the relations in something like the US GAAP Taxonomy were made explicit that the intent of the creator of the taxonomy would come across more clearly, the discipline of having to follow an explicit scheme of communicating relations would lead to better consistency, and understanding and using the taxonomy would be significantly easier.

Further, extensions create by say the 10,000 public companies which file with the SEC would be easier to interpret if relations where explicit.

On his blog, David vun Kannon explains what "bushy data" is and the difference between "big data" and "bushy data". Big data is a current buzz word. I had never heard the term bushy data before David used that term but I think I understand what he is getting at.  This is David's definition of bushy data:

Bushy Data is data where the ratio of data to metadata is very high.

And I agree that financial information is bushy data. As a certified public accountant who works with financial information I know how bushy.  And so, for years I have been trying to express this metadata in ways that I could take advantage of that "bushy-ness".  I created Excel spreadsheets, Access databases, XBRL files, XML files and many other instantiations of this metadata.

Why would I do this? Ever heard the phrase, "Content is king." Well, metadata is content.

Realizing that it was hard to work with all that metadata in different formats, I tried to figure out "the format" to use to express this metadata.  This is when I started fiddling with RDF and OWL as a metadata storage mechanism.

My fiddling around led me to the creation of this instantiation of all that metadata. Then I tried to weave the pieces together better into an ontology, which yielded this version.  There were many other versions which were created along the way.

All that testing led to the idea of the Financial Report Ontology (FRO). Testing and feedback of that led to the understanding that ontologies needed to coexist with other ontologies. For example, the FRO would likely need to interact with the FIBO (Financial Industry Business Ontology). That led to the FRO leveraging the BFO (Basic Formal Ontology).

This work led to people who really understand ontologies and how to properly create them (i.e. I am a CPA, not a technologist; I only know enough about technology to be dangerous).

That interest led to this project. That project led to this "prototype 03" of the Financial Report Ontology. That work help move toward a more appropriate architecture of the FRO.

At the same time I was tuning and testing metadata.  I create prototypes such as this web service and this prototype application. That is just a sample of applications I created to test the metadata.

Also toward the goal of testing the metadata, I helped a handful of software vendors such XBRL Cloud leverage that metadata within their GAAPWatch and EDGAR Report Information web service. That also provided good information about what worked, what did not work, and what additional metadata was necessary.

Why have I been trying to figure out all this stuff for all these years when no one else seemed to be paying attention?  Well, there were people who have been paying attention.  Also, now that the FASB says that they are "going semantic", all that I have been doing might be making more sense to people.

Those who don't "get" what is going on are at a disadvantage.  What is happening with XBRL is part of a much larger trend, a trend toward another buzz word caused "the semantic web".  Just as many people did not seem to understand the Internet when that came along, others don't really understand the Semantic Web. Achieving this vision means achieving meaningful information exchange by business users. And personally, I agree with Wired.  This is not about "the web", it is about the internet.

Abe Lincoln said, "The best way to predict the future is to create it."  I also think that the best way to fit into the future is to create the future you desire.

If you want to help create the future of the very bushy era of digital financial reporting, help create the Financial Report Ontology. Doing so will also help you understand your future.

One of the best compliments which anyone ever paid me was, "Charlie, you create elegant XBRL taxonomies." Elegant XBRL taxonomies.  Think of it! Who would have ever thought to use those two words together in the same sentence.

Yes, XBRL taxonomies can be elegant. Just as the elegance of the iPhone changed the fundamental nature of smart phones in general; understanding and creating elegant XBRL taxonomies will change the nature of digital financial reporting.

Here is one example: disclosures which run together.  Consider this fairly basic example of an SEC XBRL financial report disclosure for inventory:

That representation results in a rendering which looks like this in the SEC interactive data viewer:

Notice how what amounts to a roll up of the inventory components and the "long-term material purchase obligations" runs together. This is a very, very basic example to make the point clearly.  Imagine larger disclosures which run together and cause incomprehensible renderings of disclosure information.

Here is a rendering of the exact same information in the XBRL Cloud Viewer (click here to go to the actual filing):

Now, what if the representation of the disclosure was changed slightly in the SEC filer's taxonomy.  Say to something like the following:

No drastic changes and certainly no change in the meaning of the information communicated.  But look how the two individual pieces now stand out in the representation rather than running together. Just like paragraphs and sections within a document make reading the document easier, a well constructed XBRL taxonomy makes understanding the digital financial information easier.

I fiddled with the XBRL Cloud viewer and made it simulate the representation above (i.e. I did not re-represent the information):

See how that makes understanding the information easier?

Here is a more complex disclosure which appears to me to have three sections which all run together to create a hard to read SEC interactive data rendering:

Empty cells is a good sign of run in information, notice all the empty cells above. Notice how the yellow block of information seems to be a good candidate for a separate representation. You can have a look at the rendering and the representation (model structure) here via the XBRL Cloud Viewer.

Generally, many smaller focused sections are better than fewer sections which pack together information but then make that information hard to read. Breaking up a larger section by the well-thought-out placement of some [Abstract] concepts helps organize your representation so that those analyzing your information have an easier time of it.