Digital Financial Reporting

I mentioned in another blog post that I was creating a prototype State Fact book and using that to compare and contrast XML, XBRL, and RDF. This expands on my brainstorming in another blog post where I was trying to figure out which of the three (XML, XBRL, RDF) were "best".  I expanded that to also include XHTML and iXBRL.

Most of the "raw data" for this comparison is located on this page, the State Fact Book Index.  On this page there are 8 different sets of information.  Each of those sets are made available in XHTML so you can easily see what the data looks like.  I also made each available in XML.  Three sets are available in XBRL (but those three sets contain 100% of the information for the other sets).  The first set also contains an iXBRL (inline XBRL) example and an RDF example. I may, or may not, build out RDF, XBRL, and iXBRL for each set but I really don't need to because I am seeing the things I need to see.

The Story of the Three Bears

Remember the Story of the Three Bears? I am seeing a similar story when I compare and contrast XML, XBRL, and RDF.  Let me leave XHTML and iXBRL for later.

This is what I am seeing: 

• XML is general purpose.  You can use XML for many, many different types of information exchange needs. When you use XML though, you generally start from scratch unless you create some sort of framework to work within. I talk about how, for example, NIEM building an XML framework in this blog post.  The framework helps you be more efficient and effective. That is a good thing.
• RDF powerful, can become complex and is general purpose.  You can do anything with RDF also. RDF is for doing something different than XML.  RDF is for expressing semantic meaning which is way more powerful that XML which is a syntax.  RDF is also somewhat of a least common denominator.  If you wanted to get all the information in the world to be able to work together, you would use RDF to do that.  In fact, that is pretty much the goal of the Semantic Web. Like I said, RDF is extremely powerful and once you start getting into making use of that power, it can become complex.  RDF tools are not really usable by the typical business user.
• XBRL seems like a compromise between XML and RDF. XBRL is a general purpose language also, but its "general purpose" is does not mean everything, the focus of XBRL is on business reporting.  So, it is more of a general purpose business reporting tool.  XBRL can become complex like RDF because it is quite powerful. It is not powerful in the same way that RDF is powerful.  Again, you can do anything with RDF.  XBRL is for business reporting, it is optimized for that scope.  Software which works with XBRL at the syntax level is easier to use than RDF software, but in my view it will still be over the heads of the typical business user. But, it is possible for business users to use XBRL tools to build quite sophisticated solutions using XBRL.  It would be hard for me to believe that these same business users can figure out RDF tools.  Personally, I struggle with RDF and RDF tools.

Making XBRL Less General Makes it Easier to Use

Like I said, XBRL is a general purpose tool for business reporting.  Business reporting is a broad category and XBRL has features or many different business reporting use cases.  But each use case will not need to leverage all the power of XBRL in all areas, different domains and use cases will need different pieces of XBRL.  And making XBRL less general makes it easier to use.  This is where application profiles are helpful.

While the average business user would never be able to use an XBRL tool which operates at the XBRL syntax level, applications build for more specific purposes can be very usable by the average business user.  For example, from what I have heard business users tend to struggle with XBRL software for reporting to the US Security and Exchange Commission in XBRL.  Extending the US GAAP Taxonomy can be challenging for business users. Building the XBRL instance can be challenging.  A lot of companies outsource the entire process to third parties, thus loosing the real value that XBRL could provide.  For this reason, people see XBRL as a regulatory mandate, not for what it really is.  I anticipate that this situation will come to an end when software applications are built specifically for US GAAP financial reporting using XBRL.  That is all they do, these will not be general XBRL tools.  But because they are more focused, they will be easier to use.

So, you can get what I see as an order of magnitude increase in usefulness by turning general XBRL into one or more specific XBRL profiles and building specific applications for each profile. This can happen for two reasons. First, some of these domains are quite large.  For example, US GAAP financial reporting is huge.  The SEC filers number about 20,000.  That is plenty large. Non SEC filers who use US GAAP is somewhere between 8 million and 16 million private companies (these are the estimates I have heard).

The second reason is leverage.  XBRL is an XML framework.  For the same reason you would build an XML framework if you are making use of different forms of XML; you will get leverage when you use XBRL as a framework.  XBRL does have well defined boundaries.  Tools can stay inside those boundaries and provide good bases of functionality.  Complexity can be absorbed by applications by really smart business users or technical users who understand a business domain building profiles other less skilled business users can make use of. This is done by the profile constraining the base application.

Not Either/Or

RDF is also an XML framework.  There are may different RDF syntaxes, but there is one in XML.  But the fact of the matter is that the syntax does not even matter.  There are many things that business reporting needs from RDF which XBRL cannot provide and XBRL should never provide.  There are things which XBRL has today that will eventually be built for RDF such as rules.  XBRL has business rules via XBRL Formula.  RDF is known to need this and things like RuleML, the W3C has an initiative to create a rules language.

Semantic "Haves" and "Have nots"

I think the bottom line here is that if you believe that Web 3.0, the Semantic Web, will exist and from what I can see the evidence is mounting that it will and this will be very useful technology; then you will want to be someone who can use this new power.

XML isn't really a solution, it is more part of the problem because XML is really is about syntax, not semantics. You can make XML "semantic" in many cases, that is what RDF is for.  RDF is quite powerful and there will be many very sophisticated things created using RDF for business users.  Most will not be created by business users themselves.

XBRL is a nice compromise.  It enables a business person to leverage these new  semantic technologies in ways they choose.  It is somewhat like the personal computer and the electronic spreadsheet empowered business users, setting them free from the IT department.

It is possible for a business user to use general XBRL. I can, I am a business user.  I know others who can. Most business users will interact with XBRL and harness the power of semantic technologies via application profiles for more specific use cases making things easier and therefore useful. These applications will likely combine XML, XBRL, RDF, and other technologies.

Semantic Web utopia may never be realized, I think it is a vision, something to be strived for.  But the Semantic Web is coming.  In fact, it is already here and ramping up.  Do you want to be a semantic have or semantic have not?

#######################

Second Coming of XML

Integrated reporting is defined on Wikipedia as:

Integrated reporting refers to a holistic and integrated representation of a company’s performance in terms of both financial and non-financial results.

The vision of integrated reporting is described on the http://www.integratedreporting.org/ web site.

One Report: Integrated Reporting for a Sustainable Strategy is a book written by Robert G. Eccles and Michael Krzus which explains in detail what integrated reporting is all about.  Chapter 3 of the book talks about XBRL's role in integrated reporting.

It seems like things such as enhanced business reporting, triple bottom line, sustainability reporting, ESG, and such are all being rolled into the over-arching concept of integrated reporting.

######################

SASB Conceptual Framework

I added an additional data set to the State Fact Book prototype I am creating. That data set, which is Set-08, has population trends for the US states and the District of Columbia between 2000 and 2009.

Here is a walk through of how this was done. Hopefully this will give you an appreciation for some of the things XBRL (and other XML syntaxes) can provide. If you take the time to walk through this, you might be able to see some value which XBRL brings to the table.

I am using data from this US Census web site which provides population estimate information. I am using the "National population dataset".  That data set is explained by this PDF file (File Layout).  This is the actual data file (CSV File).

The first thing to note is that the information which describes the data (i.e. the PDF file) is not reference by or connected to the data itself.  When people say XML is "self describing", part of what that means is that the XML both contains the data and describes the data.  XBRL does this also.  The XBRL instance is the data, the XBRL taxonomy describes the data.

Another think to notice about the data is that it is "flat".  CSV shows rows and columns.  You cannot really model complex relations.  If you wanted to relate this data file to another data file, you can do it, but there is no way to validate that you got the relations correct, unless you build tools to check the relations between two different CSV files.  XML and XBRL can connect the data and the information which describes the data (which is referred to as metadata).

I grabbed the CSV, got it into Microsoft Excel which is very easy, then got the Excel into Microsoft Access, again very easy.  I put the information into Access because Access is vastly easier to use to do some things I need to do.  What, Access easier than Excel?  Yes, I need the relational database functionality of Access.  You can do this in Excel, but again, you have to build your own relations.  Why do that when Access can do it for you better.

I used Access to generate XHTML, XML, and XBRLversions of this data. Now, all these formats are "XML".  They are just different syntaxes of XML.  The each has semantics expressed, but each expresses the semantics in different ways, sometimes explicitly, sometimes implicitly.

One piece of the semantics which is not explicitly expressed in the CSV or XML or HTML is that the numbers are supposed to add up.  Each state plus the District of Columbia adds up to the total US population.  XBRL can express this.  In this case, the population trends XBRL taxonomy information which consists of two things, a definition linkbase and a formula linkbase expresses this information. Those two pieces, combined with the general XBRL taxonomies used by the state fact book information gives me this report when run through an XBRL processor which supports XBRL formula.  This report shows that the information adds up correctly.  You can run the XBRL through any XBRL application and you will get the same results because XBRL, a global standard, specifies the rules of how XBRL works, and different software vendors implement those rules.

Validating that the numbers add up does two things as explained in this blog post.  First, it documents what should add up.  Second, it proves that it does add up.  A lot of people first don't realize how big a deal this is.  They think, "Well, I do validation in my application to check to see if things add up."  You have to build that validation and you cannot exchange it with anyone else, because it is proprietary.  With XBRL the validation rules can be exchanged and they are rules engine based and can be used many times, not just once in your system.

A final point I want to make is that the population trends information, the general information, and the financial information can all easily be hooked together.  Those three data sets use the same base metadata which is expressed in the XBRL taxonomy each uses.  Grab the XBRL from the index page (the blue image which says "XBRL" on it).  Try the following:

• Hook the financial information and population information together.
• Separate the population information by "red", "blue" and "purple" state.
• Create your own data set and connect it to one of the data sets from above.

You can actually do this with XML, XBRL, or RDF.  Each syntax has its pros and cons.  I will be discussing those pros and cons in future blog posts.

Here are some inline XBRL examples.  Some people call inline XBRL "iXBRL". Either way, here are the examples.  I cannot speak to the quality of these examples as I don't have an inline XBRL validator yet.  I did run these through the W3C validator for XHTML.  That validator has issues with the inline XBRL concepts in these samples/examples because it is not aware of the inline XBRL schemas.  Anyway, these can get you started if you are curious about inline XBRL (iXBRL):

• IASCF: A financial statement.  Note that this has an XML extension so it will not render pretty in your browser.  Let's you look at the guts.  But if you download the file, change the extension to ".html", it will render nicely.
• VT Software: Sample regulatory report/financial statement.
• State Factbook: This is just a table of information.  (iXBRL is not only for financials.) Be sure to check out the sample extraction application for iXBRL here.
• XBRL International: Sample US SEC filing.

More information on iXBRL later.

I used to think that there were two models for extension of XBRL taxonomies for reporting using XBRL: static and dynamic.  Now I think there are at least three. Let me summarize the three XBRL taxonomy extension models one might make use of for reporting:

• Static: By static I mean that the extension of your XBRL taxonomy is not allowed at all. This reporting model is what amounts to a form.  Tax forms is one example.  Basically the user fills in all the boxes on the form.  This type of reporting is easy to implement in XBRL as you don't have users making modifications to the XBRL taxonomy so users there is less for them to learn.  Also, because the report is a form software applications are easier to build.
• Dynamic: By dynamic I mean that extension of your XBRL taxonomy is allowed.  This reporting model is more like SEC reporting by public companies.  Users can extend existing relations and concepts or add entirely new relations and concepts.  What users add in terms of an extension needs to be consistent with the XBRL taxonomy they are extending.
• Leaf level extension: I don't quite know what to call this yet, so for now I will call it "leaf level extension". What I mean by that is rather than giving those that report to you the ability to add new relation structures, they can only add new relations and concepts to existing structures.  Extension is allowed but there is less that the business users need to understand about XBRL taxonomies.  Users are not allowed to add new structures, only add things to existing structures.  What can be added can be more easily controlled by software as the existing XBRL taxonomy serves as a guide to adding the new leaf relations and concepts.

I am not making any judgements here about which XBRL extension model one should use in any specific case, this is more about pointing out the spectrum of options which you have. I can see scenarios where say a regulator did not allow extension within their reporting model (i.e. static reporting, a form) but really would like to allow business users to do some extension as it would improve the reporting scheme or system.  Allowing leaf level extension provides some additional flexibility, but not increasing complexity to the degree that complete dynamic reporting would entail.

And it is not that these three models need to be used in isolation.  For example, if you look at say SEC XBRL reporting using the US GAAP taxonomy, there are areas of the XBRL taxonomy which you would want to work like a form (i.e. the user cannot change those areas at all), there are some areas where you want the users to be able to add leafs to existing relations and concepts and finally there are certain occasions where the user will need to add entirely new relations and concepts, providing complete flexibility to the business user.

It is up to the business domain to determine the needs of their reporting scheme.  Just realize that you have options and that each option brings a basket of characteristics to the table.  You have to mix and match what you need with how you implement XBRL taxonomies within your system.