Digital Financial Reporting

When creating a prototype I stumbled across something of interest which helps to show XBRL's ability to detect possible errors within a data set.  I am not saying that this is, or is not, an error.  But it does look like an error. I am trying to determine what is going on and am trying to find someone in the US Census Bureau who can help indicate what is going on.

So here is the deal.  The US Census Bureau makes summary financial information available for the US States. See the 2008 Annual Survey of State Government Finances here. More specifically, see under "Downloadable data" the summary table in Excel.  That is an Excel spreadsheet containing what amounts to an income statement for each US State, and an aggregation of the information for the total of the states in the column "United States".

I was using that data to create a demo and when I ran the XBRL validation against my data, I got some errors.  I will walk you through that in a moment.  But, here is an Excel spreadsheet which shows what could possibly be an error in the data.  If you don't have Excel, this graphic also shows the possible error.  What is going on is the line item "Insurance trust revenue" does not cross cast (i.e. the numbers for the individual states don't add up to the total in the United States column). That same discrepancy exists within Total revenue, of which "Insurance trust revenue" is part.

Now, I am not saying definitively that this is an error.  But, one of two things is going on.  (A) It could be an error or (B) the fact that the number does not add up like all the other columns is not documented within the data set.  It seems logical that others using this data might have the same question as I do given that all the other line items add up and given that it seems logical that everything should add up.

So why was I able to discover this?  Well, for my prototype, I was using that state financial information.  I created an XBRL taxonomy and in that XBRL taxonomy I created business rules which both document how things add up and allow me to verify that everything does in fact add up.  These business rules come in two forms. First, a set of XBRL calculations which show how the income statement adds up.  Here is a rendering which shows this.  Now, this is easier for a computer to read in the actual taxonomy. The result of running the XBRL instance information through the validation generates this report. That report shows first, how things add up and second the fact that the numbers do add up correctly in each of the 50 state income statements and in the total fur the United States as a whole.

The second test I ran is to use the fact that the 50 states do add up to the United States total, basically the relations shown here.  I created an XBRL Formula to express this relation, you can see that here but it looks rather ugly and I have not created a rendering of this. Computers can read business rules expressed in a global standard format and generate something like this, called a formula trace, this on generated by UBmatrix's XBRL processor.

This business rule generates this report which shows the descrepencies in the numbers. Now, you see four errors rather than two because I added two line items to the data set which calculated the net revenues over expenses and another concept showing the net Insurance trust activities.

Here is the bottom line.  I don't know if this is really an error or not, but the more important thing is that XBRL can document whether the numbers are supposed to add up and if the, in fact, do when the data is made available.  This report shows that the numbers foot. This report shows if the numbers crosscast (admittedly, this could be formatted nicer to make it more readable).  These reports are generated in off the shelf software.  The metadata communicating that the information adds up (or not) is made available with the information itself.  Here is the XBRL instance. Plug that into any off-the-shelf XBRL enabled tool and plug the XBRL formula in, and you will get the same result (the software does have to support XBRL Formula of course, many do).  That is right, not only can you validate the information, but the validation is portable between business software applications!

You can still get the data and read it, just like the US Census Bureau provides in in Excel.  This tool can be used to extract information using a very simple Excel macro. No XBRL processor was used, but that would make writing the already easy to write code (I wrote it, I am a CPA not a programmer) even easier.  (Note that there are a number of different formats you can extract the data from, find the tab "Financial - XBRL".)

The IASC foundation released todaythe 2010 version of the XBRL taxonomy for financial reporting under IFRS. The taxonomy includes an IFRS for SMEs (small and medium enterprises) entry point for the taxonomy.  Here are links to:

• 2010 IFRS XBRL Taxonomy Home Page
• Link to physical files
• Link to documentation (which they say is coming soon)

Also, I took the IFRS for SMEs presentation information and imported that into an Excel spreadsheet, ran some macros against the information to format, color, and otherwise made it easier to read.  You can grab that Excel spreadsheet here if you want to have a look at the IFRS for SMEs taxonomy.

This XBRL taxonomy is likely a good sign of things to come in terms of XBRL taxonomies for financial reporting.  I believe that this is the first financial reporting XBRL taxonomy which incorporates decisions made by the Interoperable Taxonomy Architecture group (IASCF, SEC, EDINET).

I spent about 4 hours trying to find some reasonable resources for getting started with OWL (Web Ontology Language).  I figured I would summarize what I did to get all set up and going with OWL.

OK, here are the key resources for getting started with OWL.

• The book Programming the Semantic Web (O'Reilly) is a good starter book for non-programmers.  This basically paints the big picture.
• The tool Protege, is an OWL editor mentioned in that book.  This web page is a good get started guide.  It has links to download the free application, a quick overview, etc.
• This 10 minute walk through helps you get going and points to two plug-ins you will likely want.
• This is a 100 page PDF on how to use Protege.

Even if you don't want to be an XBRL taxonomy master, OWL is a good thing to understand. It will really help you grasp where the world is going.

Announcing the State Fact Book prototype!  The State Fact Book is the next step toward answering questions I am asking myself on this blog post.  The best way to figure out when to use XML, XBRL, RDF, HTML, XHTML, iXBRL, RDFa, or other such formats is to use each and compare them.  So, that is what I will do.

Stay tuned for more information!

This blog post summarizes several other blog posts.  It may seem rather stream of consciousness and be along the lines of brainstorming, if it does that is because that is what this blog post is.  I am summarizing this information to help myself understand it and learn to better communicate it to other business users. It is hard to say how many years of thinking have gone into this.  But I have to answer this question over and over and I wanted to understand the real answer for myself. The questions are which is 'better': 

• Is XBRL is 'better' than XML, 
• Is RDF/OWL is 'better' than XBRL
• What considerations go into deciding which syntax (XML, XBRL, and RDF/OWL are all syntaxes) is 'best'

The first thing one needs to do is define the problem you are trying to solve.  In general, the problem which seems to need solving is getting business information out of one system, be it internal to your organization or external to your organization, and then automating the process of using that business information within another business system.

Helpful background information

Here is some information which provides helpful background in understanding the moving pieces of this issue. This may seem like a lot of stuff to know, and it is.  But if you want to understand the moving pieces and make the right choice, you do need to understand the moving pieces or have someone help you who does.  This is not about providing you with a two minute sound bite, this is about providing you with the information you need to truly understand the issues you need to consider.

• Structured information, not unstructured information: Two points here.   First, I am talking about structured information.  Second, the world is moving toward structured information because computers cannot parse unstructured information reliably enough and it costs too much.  This video, How XBRL Works, helps you understand the difference between the two.
• Structured for meaning, not structured for presentation: I am talking about information structured for meaning, not information structured for presentation.  Again, the How XBRL Works video helps you understand the difference.
• Global standard, not point solutions: If information is structured you can always convert it into some other structure using some mapping process.  If everyone used their own structure, everyone would have to map to everyone else's structure.
• Use XML:  There are many different data formats.  The world is standardizing on XML.
• Many different forms of XML: There are many different forms of XML.
• Many different forms of XBRL: There are many different forms of XBRL.
• Many different forms of RDF: There are many different forms of RDF.

XBRL builds upon XML

In a previous blog post I explained how XBRL builds on top of XML.  Let me summarize these points here, you can go to that blog post to drill into this information further.  This is also explained in my book XBRL for Dummies (page 33)

XBRL's "Sweet Spot"

XBRL has a 'sweet spot'.  This sweet spot is discussed in my book XBRL for Dummies (page 172) in detail, I summarize the points for you here. 

• Flexibility within rigid systems
• Reconfigurable information
• Rules engine-based validation
• Clear communication and sharing of rich business-level semantics
• Metadata-driven configuration, no IT involvement required
• Zero tolerance for errors
• Achieving agreement with exterior parties

XBRL, RDF/OWL, and the Semantic Web

When people talk about the Semantic Web, terms such as RDF and OWL come up as the information formats of the Semantic Web. If RDF/OWL are the formats of the Semantic Web, then it seems obvious that all information should be expressed in RDF/OWL.  Right?  Do away with all other information formats, move everything to RDF/OWL and life will be good.  That is the only way where you can write "queries" on the information on the Web, if the information is in the same format.

RDF/OWL has benefits beyond what XBRL can provide.  These benefits seem to be:

• OWL has way more power to express semantic meaning than XBRL.  That is what OWL is for, expressing semantic meaning within an ontology.  XBRL is more in the "taxonomy" expression business than the "ontology" expression business. (To understand the difference between a dictionary, a classification system, a taxonomy, and an ontology, see this blog post.)
• RDF/OWL are the W3C information formats for the Semantic Web.
• RDF/OWL can express anything, XBRL is more focused on business information. 

Bottom line: XML, XBRL, RDF/OWL; Which is 'Best'?

From what I can tell, the answer to the question of whether to use XML, XBRL, or RDF/OWL is that it depends on what you are using it for.  What is crystal clear is that XML, XBRL, and RDF/OWL are syntaxes.  What is important to business users is semantics, not syntax.  What ever syntax you choose, you should be able to convert it to any other syntax, be that an external exchange format or an internal storage format such as your relational database.  The semantics (meaning) must be the same in any business system or the information exchange simply will not work.

There are lots of obvious places where clearly XML is the way to go. It seems XML is perfect for specifying large, fixed documents such as DocBook, expressing Excel spreadsheets, XHTML, and such.  XML is also perfect for fixed transactions which rarely change.  What seems to be key here is "fixed".

For "ad hoc" projects, tightly controlled systems which are closed, XML will probably work fine.  When you start talking about enterprise class systems, lots of users, the need to scale, things which need to be rock solid, you need to have some sort of framework.  XML frameworks can be created. NIEM is such a framework (National Information Exchange Model).  The NIEM Introduction provides a very good explanation of why frameworks are important.  Basically, frameworks provide discipline and leverage.

XBRL is a framework.  It provides discipline and leverage.  A primary benefit of XBRL is XBRL Formula, the ability to model business rules in a global standard format.  Being able to express those business rules means that you can validate the semantics (not just the syntax) of information in a global standard  way and exchange those business rules with others. XML cannot do this, it probably never will be able to.  RDF/OWL cannot do this now, but the W3C seems to be working on this.

RDF/OWL offers a powerful tool to express complex semantics in a global standard way, far beyond the capabilities of  XBRL.  RDF/OWL will be the least common denominator of the Web, the way to get different syntaxes to be able to work together.

It seems as though the answer to the question about which is better is that it depends on the system you are implementing really.  What is clear is that clear semantics are critical.  RDF/OWL can help in this regard.  If you cannot clearly express your information model in RDF/OWL, then your information model is broken.  If you can express your model in RDF/OWL, the least common denominator of the Semantic Web and a very powerful tool for expressing semantics, then it will not matter what syntax you use because you will be able to convert to any syntax and the RDF/OWL will document exactly how to do that.

A lot of these details are discussed in my book XBRL for Dummies. The book lays many of these things out so business readers can get their heads around them and understand the right questions to be asking the technical people who have to help them use XML, XBRL and RDF/OWL within their business systems.  The area of RDF/OWL is rather weak in the book, but the key concepts are there.  Watch my blog for more information should you need such information.