Digital Financial Reporting

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.

This is a series of posts where I am providing information relating to figuring out what the best data format to use and why. Basically, when is XML better, when is XBRL better, and when is RDF/OWL better.

I have posted a number of blog entries relating to RDF, OWL, and the Semantic Web which you can find here. I want to summarize what I have figured out with regard to RDF here.

RDF (Resource Description Framework) is one of the cornerstones of the Semantic Web. RDF can be used to document pretty much anything.  The core to RDF seems to be the subject-predicate-object relation which was it seems used by Aristotle. This is what RDF looks like in one form, XML.  I am not going to explain RDF in any more detail, go look at the other blog posts for that.

What I do want to document is the forms of RDF:

• Triples: There are lots of terms for subject-predicate-object relations. Here are some of those notations (syntax): N3, N-Triples, TRiG, TRiX, Turtle, RDF/XML, RDFa.  Each of these probably has their pros and cons.  The point here is that this is for the most part many different ways of doing the same thing.
• RDF XML: So because I want to stick with XML, I will focus on RDF XML as "the" format for RDF for my purposes.  The format really does not matter, what matters is what I talk about below.  Using RDF alone is like using XML without a schema.  You can basically include anything, right or wrong.
• RDFa: RDFa is an approach to embedding metadata into HTML web pages. Something similar to this is eRDF. RDFa and eRDF are similar to iXBRL.
• RDF plus OWL: Web Ontology Language (called OWL) can be thought of as a schema for RDF, loosely similar to how XML Schema constrains XML.  But, OWL is much different in that it is used to constrain semantics, not syntax.  What this means is that RDF by itself seems somewhat useless really.  You have to both make sure you build your RDF relations correctly and you understand those relations.  That is what OWL seems to do. OWL defines a semantic model which both explains the RDF and constrains the RDF.
• RDF and standard OWL ontologies: The next step in the spectrum is what I am calling standard OWL ontologies. It is one thing for someone to post an ontology to the web.  You could have hundreds or thousands of ontologies which express the same thing.  The ontologies could have different logical models and not even interoperate.  As compared to having one agreed to ontology for some specific model.

So, what the heck does all this mean.  Let me try and explain.  I will use a small data set which I have created to explain.  Browse through these different data sets which I found on the web.  I grabbed these data sets, I decided to grab 20 different sets of data. Imagine you had the following data sets:

1. When states entered the union.
2. State violent crime statistics.
3. Miscellaneous population statistics by state.
4. State capitals and largest cities.
5. Population estimates by state. (This is the specific CSV file which will open in Excel.)
6. Financial information by state. (This is the specific Excel file.)
7. State areas.
8. State symbols.
9. State mottoes.
10. State nicknames.
11. Origin of state names.
12. State GDP.
13. State GDP per capita.
14. State population density.
15. State tax revenues.
16. State unemployment rates.
17. Gross state product per capita.
18. State by most educated.
19. State by health index.
20. State by personal income.
21. (Extra) Red, Blue, and Purple states

Suppose you wanted to use the data in one of those data sets, what would you do? Copy and paste into Excel most likely.  What if you wanted to use two of those data sets together. No problem, just copy and paste both sets into Excel and put them together.  When you try and do something like this you run into problems such as the key value (i.e. in this case the state name probably) could be different.  For example, this list uses the state abbreviation, not the state name.  Now, this is not a huge deal if you don't need this information on a timely basis, or if you have small sets of data like the 50 states, etc.

So what if this information was in XML like this data set of state population. It would be pretty easy to write a simple Excel macro to go get the data. But what if each set of data used a different XML syntax?  See this blog post on different XML formats. OK, so not a huge problem, just write multiple import Excel macros, one for each XML file.  Right?  Well, that will get old.

OK, so what if everyone used the SAME XML format?  Say, RDF.  Well, then you could read the RDF by just pointing an application at the file, right?  Not quite.  What if the RDF used different logical models (or ontologies) to describe the data? If that happens, well, then you are back to mapping one file at a time, adjusting the multiple logical models or ontologies into one common model. You can do this, but it is a lot of work.

But what if there were another way?  What if you created one standard logical model, documented in using OWL, and then made every piece of data available in a common format.  Check out this Data-gov Wiki. Look at this web site, or wiki.  More specially, look at this complete data set of RDF.  Per the web site, they have converted about 280 data sets into RDF.

OK, so what is the bottom line here with regard to RDF.  First, the Semantic Web is about making information on the web more readable to computers.  To do that, the best way is to have one data format (semantics and syntax).  Short of that, one can take the many different data formats and map them to one syntax. You have to be sure the semantics (the meaning) of the data is consistent.  Much of the data needs to work together. Most may never be used together, but come like the state information I pointed out, will be used together. XML is a syntax that pretty much most people on the web are moving to, so RDF in XML makes sense.  You need OWL to articulate your ontology, or your model, so people both understand your model and data made available complies with that model.

But my next question is when should XBRL be used and when should RDF/OWL be used?

A paper written by Hongwe Zhu and Harris Wu of Old Dominion University, Quality of XBRL US GAAP Taxonomy: Empirical Evaluation using SEC Filings, looks at the quality of the US GAAP Taxonomy.  The following is an abstract of that paper:

The primary purpose of a data standard is to improve the comparability of data created by multiple standard users. Given the high cost of developing and implementing data standards, it is desirable to be able to assess the quality of data standards. We develop metrics for measuring completeness and relevancy of a data standard. These metrics are evaluated empirically using the US GAAP taxonomy in XBRL and SEC filings produced using the taxonomy by approximately 500 companies. The results show that the metrics are useful and effective. Our analysis also reveals quality issues of the GAAP taxonomy and provides useful feedback to the taxonomy users. The SEC has mandated that all publicly listed companies must submit their filings using XBRL beginning mid 2009 to late 2014 according to a phased-in schedule. Thus our findings are timely and have practical implications that will ultimately help improve the quality of financial data.

While the paper just scratches the surface (note that the authors refer to this as their initial work), it does offer helpful insight into using the US GAAP Taxonomy to create SEC XBRL Filings and using those filings.

Here is a summary of some of the more helpful and interesting findings of this analysis.  I have added my commentary to this information using italics:

1. The authors point out that from a syntactical perspecive, all the XBRL documents (XBRL instances and the filer XBRL taxonomy extensions) prepared by SEC XBRL filers are interoperable because they use the same syntax (i.e. XBRL). However from a semantic perspective (business meaning), the XBRL documents can be difficult to compare when different companies use different data elements in their document.  (I would point out that an XBRL taxonomy contains two things: elements (better referred to as concepts really) and relations.  Differences in not only concepts can cause comparability difficulties, but also differences in the relations.)
2. The authors point out that from the perspective of the users of this information, the metadata (i.e. the taxonomy concepts and like I said above their relations to other concepts) are also data.
3. The US GAAP Taxonomy has 10,537 "active concepts".  (There are also 2,653 abstract concepts which can never be used to report information and 346 deprecated concepts which should not be used by SEC filers.)
4. Many companies are reporting using the deprecated concepts.  The authors point out that 195 out of 481 filers used deprecated concepts.  They point out a list of the deprecated concepts.  (It seems to me that the SEC should provide a submission test to not allow these deprecated concepts to be used.  The US GAAP Taxonomy clearly identifies these concepts.  Or, perhaps the US GAAP Taxonomy should simply remove these concepts rather than providing them and marking them deprecated.  Either of these would solve this problem.)
5. All SEC XBRL filings combined, a total of 2,558 US GAAP Taxonomy concepts were used and a total of 10,168 custom concepts were introduced by filers.
6. The average filing contained approximately 125 concepts of which 109 were from the US GAAP Taxonomy and 16 were added by filers.
7. A list of the top 50 most used US GAAP Taxonomy concepts is listed.  (I have two points relating to that list.  First, I am very currious why "Assets" is used 1229 times and "LiabilitiesAndStockholdersEquity" was used 1217 times.  Seems to me they should be the same.  Maybe this is because some of the filers are partnerships or something.  Second, it seems to me that the frequency of the items on that list is a good indicator of comparability between filings.)
8. A list of the top 50 custom concepts added by SEC XBRL filers is provided.  Of that list of 50, the authors point out that 15 concepts have identical names as concepts which exist in the US GAAP Taxonomy. Of that list of 50, an additional 13 concepts added are very similar to US GAAP Taxonomy concepts.  (I would point out that these lists are a nice little validation check which could help SEC XBRL filers not use duplicate concepts.  These checks would be quite easy for a software application to implement and seems helpful to filers.)
9. A comment was made by the authors, "The data shows that the lengthier-named elements are certainly less frequently used." (I would point out from my experience in creating the US GAAP Taxonomy that the lengthier concepts are in the disclosures and the SEC XBRL filers are not doing detailed tagging of the disclosures, therefore the lengthy concepts clearly would not be used at this point.  The author also notes that only 2,653 of the existing 10,537 concepts were used.  Wait until detailed tagging kicks in, the number of concepts used would grow.)

All in all this research provides useful information, but like the authors point out...there is a lot of opportunity for more research.  Just like the SEC XBRL filers, the researchers will figure out the really interesting things to research when they have more experience with the taxonomy.

Also, I would point out that the researchers who did this analysis have an IT background, not an accounting or financial reporting background.  So while this information is helpful, personally I think more accounting people need to be involved in this type of research.  I have several blog posts which raise interesting accounting and financial reporting which need to be answered such as this post about taxonomy architectures, this post relating to the top 10 errors in SEC XBRL filings that I have run across, or this post where I evaluate the criteria for investor friendliness of SEC XBRL filings.

If you believe XBRL is here to stay (there is plenty of evidence that will be the case), then it is time for certified public accountants and charted accountants to understand some things about XBRL. Even some attorneys will need to understand some of these details.

These are not details relating to the technology, rather they are details of financial reporting which the technology needs to be able to deal with.  This is not a list of all those details, here I am focusing on information being reported within a financial report which is expressed using XBRL. This may not seem important to you now, but keep in the back of your mind that one day the XBRL will be the source document which drives the financial information which is presented.  Today, most accountants look at XBRL as something additional you do after print your financial report.  That will not last for long, that approach is simply a step in the evolution of XBRL.

If you are expressing information in XBRL, you will want these details to be expressed correctly.  These details relate to expressing information correctly within an XBRL financial report.  The information you express are called facts.  These facts are described by other information which identify the fact and help represent the information you are disclosing.  There are various approaches to checking to see if what you expressed comes across as what you desired to express.

So, what exactly is a fact?  A fact is something you can observe.  For example, here is a fact with some of the information which identifies the fact and helps to express the fact:

Cash and cash equivalents amounting to $1,000,000 for the consolidated group for the end of the third quarter of 2009 which rounded to millions of US dollars reported in the financial statement released on February 18, 2009.

Again, that is only one fact, some of the information which helps identify that fact and other information which helps you to identify that fact.  You will have thousands of facts and there is various information which helps identify those facts and helps you represent those facts.  You have processes to help you be sure you expressed these details correctly.

Here is a fairly comprehensive list of identifying information and which helps you express that fact which you should be considering when you create your financial information in XBRL:

• Concept: Every fact has a concept to which that fact relates.  The concept tells you what the fact is, for example "Cash and Cash Equivalents". Concepts have additional information relating to them such as the definition of the concept, labels, whether it is a debit or a credit, and so forth. There is much more to concepts, but let's stop there for now.
• Report date: Every financial report has a report date, most of the time being the date of the audit opinion attached to the report.
• Fiscal period: Information within a report relates to a fiscal period which you know might not be a calendar period.  Fiscal periods might not correspond to months, for example the retail industry uses a 52/53 week fiscal period in many cases.
• Reporting entity: The reporting entity is the entity reporting the information which may not be the entity which the information is about.  See legal entity which is next.
• Legal entity: The legal entity is the entity to which the information being reported relates.  It may, more may not be, the legal entity.
• Operating segment: The information being reported may be for the consolidated group or parent, or it may be for one of the operating segments of the consolidated group.
• Operations continuing or discontinued: The operating segment for which information is reported might be continuing or it may be a discontinued segment.
• Measurement basis: The information being reported could be reported at historical cost, amortized cost, fair value, or some other measurement basis.
• Restatement: The information could have been restated due to a change in an accounting policy or because of an error in a prior period report.
• Reclassification:  The information of a prior period may have been reclassified to match the classifications in your current financial report.
• Reporting scenario: The information being reported could be actual information, or it might be forecast information, or perhaps even budgeted information.
• Third party verification: The information reported could be covered by a third party audit report or it may not have been audited at all.
• Other descriptive information: All sorts of other details could be important to specific types of detailed information such as the class of long term debt or a specific category of subsequent event.  These details may, or may not, be important to communicate. 
• Value of fact: Information reported could be a number such as "1,000,000" or it could be a piece of text such as "First in-first out", or it might even be an entire paragraph of text describing an accounting policy.
• Rounding: If the information reported is a number, the number could be rounded to the nearest millions of dollars or detailed to the nearest cent.
• Reporting units: Maybe the units are not dollars at all, but rather Euros or some other currency.  Or, the number might not even be monetary but rather the number of employees or the barrels of oil within a reserve.
• Reason information is not reported: Sometimes for a number of reasons the information which is required to be reported is not available and you need to explain why that information could not be reported.
• Relations to other facts or concepts: Facts reported relate to other facts being reported.  For example the line items of a balance sheet add up or "roll up".  A cash flow statement not only adds up (i.e. the net change in cash), but it also communicates a "roll forward" of the beginning balance of cash to the ending balance of cash.  Or, maybe the fact is not a number and therefore not involved in a computation but is rather an accounting policy and you want to organize it with your other accounting policies.

Another question to ask yourself is how the analyst using this information interpreting the information?  Is the analyst going to have to imply any meaning because when you reported the information you were not being explicit.  Is that analyst going to correctly imply the right meaning?

Sometimes XBRL taxonomies don't help you understand how to report certain identifying information or information which helps you properly represent the information you need to report in XBRL.  If the XBRL taxonomy does not, you will still need to do something to be sure the meaning you are trying to articulate will be interpreted properly by users of the information.

The bottom line is to ask users of the information if they are having any issues making sense of your XBRL based financial reports.  But the CPAs/CAs who create this information, those who review this information, internal auditors who work with this information, third party auditors dealing with this information, attorneys who help prepare and work with this information, and others need to be conscious of what they are saying in their XBRL based financial reports.  Software can help you, but you are the one who is ultimately responsible for the quality of your XBRL based financial reports.

If you go to the SAP Investors Relations page (see the third line) you will see that they published their financials for 2009 in XBRL before being required to do so by the SEC.  What is even more interesting is they created their filing using their product, SAP BusinessObjects XBRL Publishing by UBmatrix.

(Recall that a few days ago I had mentioned that Oracle announced two new products for creating XBRL.)

In addition to the XBRL, SAP is also making available HTML versions of their financials on their web site which seem to have been rendered using the SEC open source XBRL rendering software.

Nice!