Digital Financial Reporting

If you are a CPA or otherwise involved in financial reporting or analysis of financial information, you do not want to miss this blog post!

I received an email from someone last week making me aware of an XBRL enabled analytics system which was released last week.  You can find this system here.

Per the about page of the web site:

Open Analytics is a pioneer effort in a public-private partnership between ACRA and WHK Horwath, which aims to provide, to the Singapore business community, an efficient way to access salient financial analysis and benchmark performance data for fundamental financial analysis, investment analysis, credit analysis or other purposes.

From what I can tell, there are approximately 99,000 corporate financial filings which are apparently made to the government of Singapore in the XBRL format.  The information in those corporate XBRL filings is being distributed on this system.  This is what I did to take a look at this system:

1. A video is made available which walks you through what you can see on this system.  The video is well done and only takes about 5 minutes to watch.
2. There are two sample companies where you can go look at the actual working system.  This is really nice!  You can see a link to the samples you can use at the bottom of the main page.  Or, you can just click here.  I recommend the first analysis (OAKWELL ENGINEERING LIMITED).
3. Be sure to walk through the analysis, looking at all the buttons and places you can click.  Also, you can print a report.  Be sure to look at that.

I don't want to take anything away from this system at all, this is one of the cleanest, well organized, easiest to use systems I have ever seen.  But I do want to point out a couple of things.

The first is that the data which feeds this system is more of a static "form".  Because the data is form-like, doing these comparisons is really straight forward.  This is because the data submitted by each filer is the same and easily compared.  By contrast a system such as the US SEC is more "dynamic".  For data submitted to that type of system, this type of system is more challenging to create.  One of two things needs to happen in order to make a system like the SEC database of public companies work like this system.  The data coming into the system needs to be made more comparable and consistent.  Alternatively, you could throw a lot of programming at the inconsistent data and try and make it more consistent by programmatically resolving inconsistencies such as the inconsistent revenue concepts used (or other concepts).  A compromise between the "form" and more "free form" information coming into the US SEC is a compromise between the two.  Have the higher level information be more rigidly specified (things like "assets", "liabilities", "equity", "cash flows from operating activities", "cash flows from financing activities", "cash flows from investing activities", "debt", "cash and cash equivalents"; basically whatever can be agreed on would make using that level of information easier. Then, the more detailed information could still be more dynamic.  You cannot make this totally free form or it will not be useable in systems like this at all.  You don't want to make the SEC data a "form" as that reduces the quality and usefulness of the filings.  Some compromise between the two would provide the both ease of use and usefulness.  Arriving at that compromise is the challenge.

A second point is the visualizations.  I am totally into charts and graphs, and man; these new types of visualizations are REALLY nice!  Realize that it is not XBRL created those nice visualizations. But what XBRL does do is provide more information to put into those visualizations without having to rekey the information.  And, as more and more information is made available in the XBRL format, more and more information will be available to put into these fantastic visualizations at low marginal cost.  As a side note, here is a TED presentation (about 20 minutes, amusing, definitely worth watching) which shows these bubble charts in action.

A final point is that while the information being available in these nice visualizations and other formats is really nice, why can't I see any XBRL so I can pull out whatever data I want to pull out and format that data however I want to format it, not limited by these nice interfaces which are quite useful but restrict flexibility.  I don't know if some sort of API or XBRL files are being made available, but I cannot see it.  It certainly would not be hard to make such an API or XBRL interface available.  Not sure why this system did not make this available, I will certainly inquire about this.

The bottom line here is that this system is an example of the type of functionally which can be made available.  This type of functionally will be the benchmark others will have to achieve.  The marginal cost of reusing information is peanuts because of low cost infrastructure, such as the Web, available to literally everyone.  For more dynamic systems such as the US SEC public company financial information, these types of results are harder to achieve, but still very, very possible to achieve.  All that is needed is a good vision and a desire to achieve that vision.  All the technology is there to use.  Me, and I believe others, will still want those XML tags so we have the flexibility to do whatever we desire with the information.  Think linked data!

I had a very interesting experience which I thought I would share. Doing this was enlightening. It is not directly related to XBRL, but it does have many parallels to issues XBRL is grappling with.

Several years ago I created a little video called How XBRL works.  That was for another experiment, to fiddle around with YouTube and to try and embed a YouTube video into a blog page which I did here. (If you want to understand how XBRL works, I would encourage you to check this video out.)

My new experiment was to try and see if I could get a podcast, audio and video, to show up in iTunes. You can see the successful results of that experiment by going to the iTunes store and searching on "XBRL" and you will see my XBRL Channel and two podcasts.  (Or, if you have iTunes, you can click here.)

Turns out, this is a pretty easy thing to do.  Here are the steps:

1. You have to understand the iTunes RSS specification.  You can find that here.
2. You have to create your content in the appropriate format (i.e. MP3 for audio, MPEG4 for video, etc)
3. You have to create an RSS feed.  This is the RSS feed that I created.
4. You have to tell iTunes about your RSS feed. You can do that from this web page.  See the section "How do I submit my podcast?"  The link in that section takes you to the correct place in iTunes.

What does all of this have to do with XBRL you ask?  Well, because iTunes has created a specification for certain tags which it looks for within an RSS feed (go view the source of my simple RSS feed), it can reliably use that information within iTunes.  This creates an operating environment which is easy for users.

Further, because I follow the iTunes specification, all I have to do is put my RSS feed out on the Web somewhere, put the content on the Web, and my content can end up on your iPod or iPhone!  I don't have to build any infrastructure, no special hardware, no special anything...all I have to do is follow the standards and other specifications.  It really is both simple and powerful.  This also contributes to ease of use by leveraging the Apple iTunes environment.  I am not restricted to using only the Apple iTunes environment, I can still distribute my videos on YouTube.

One day,  this is how XBRL software will work.  Or rather, I should say that this is how business reporting and analysis software will work, leveraging XBRL's capabilities within that software.

Now, the iTunes specification is proprietary.  But, that does not mean that you can only use that RSS feed in iTunes.  The iTunes tags are becoming an ad hoc standard for RSS feeds.  Not everyone (like iTunes competitors) uses them, but it does create the possibility of cross software interoperability.

The US SEC has an RSS feed.  That RSS feed is proprietary to the US SEC.  The SEC had to create some of their own RSS elements because there was no standard that they could pick up and use.  Maybe the SEC RSS feed tags will become an ad hoc standard.  This could happen.  Or, someone like XBRL International can take a look at how the SEC and other regulators are making people aware of XBRL instances and XBRL taxonomies so that software vendors can more easily get the functionality that business users need inside their software.  For example, here are the US GAAP Taxonomy files.  Meta data about "entry points" and "references" and other things can be put into computer readable form (rather than human readable documentation) and software vendors can provide the ability to use the taxonomy without every having to look at the files.

I think that XBRL International should create a standard set of RSS feed elements and attributes which all systems which make use of XBRL could leverage.  Short of that, perhaps software vendors will standardize on what the SEC provides.  One day XBRL users will be has happy as iPhone users!

What is your opinion?

This is a test of Google Forms and Google Spreadsheets.  The following is a Google Form which is embedded in this blog post.  You can enter data into this form.  After you submit the data, it goes into a Google Spreadsheet.  Every time someone submits something, another line goes into the Google Spreadsheet.  (Note that below you can go look at the spreadsheet.)

This is a link to the Google Spreadsheet:

To view the spreadsheet after you entered your results, click here.

Notice that your data is in the spreadsheet as well as data from others.  This is pretty simple (a flat file basically, not a relational database) but still quite useful.  Note that you can create different submission controls to manage data integrity to a degree.  Be nice if the Google Spreadsheet would also be made available in XBRL so that you could automate the process of reading the spreadsheet data.  Right now, you have to open the spreadsheet and look at the information to use it.

I use the term application profile from time to time.  Do you understand what an application profile is or how application profiles provide benefits to business users?  This blog post answers those two questions.

Section 1.4 (page 4 of 44) of the US GAAP Taxonomy Architecture explains what an application profile is from the perspective of the US GAAP Taxonomy:

Application profile - These voluntary restrictions followed by version 1.0 architecture form an "application profile" for the use of XBRL features within the taxonomy. It is strongly recommended that extensions to version 1.0 stay within this application profile. Systems using version 1.0 may, at their option, set rules which force extension taxonomies to stay within this application profile.

The US SEC follows these restrictions.  For example, the US GAAP Taxonomy Architecture says that: (a) all XBRL Dimensions information must be put into the context segment element (XBRL allows them to go into either the segment OR the scenario element), (b) typed members cannot be used (XBRL allows these), (c) no tuples are allowed (XBRL allows tuples).

These restrictions of XBRL (i.e. use segments, no typed members, no tuples) are set by the US GAAP Taxonomy Architecture and followed by the US SEC.  There are more restrictions that the US SEC places on XBRL.  For example, the SEC specifies that the context entity scheme used must be the SEC CIK number scheme and that the value of the entity identifier must be a valid CIK number.

Never does the SEC or the US GAAP Taxonomy ADD anything to XBRL, they always remove from what is allowed.  If they added things to an XBRL instance or an XBRL taxonomy, they would be violating the XBRL global standard specification.  Now, they can and do add things outside the XBRL.  For example, the RSS feed which is used to make people aware of SEC XBRL filings goes beyond XBRL.  In this way, the SEC is adding things to their system.

Now, XBRL software is not expected to use this RSS feed.  So, the RSS feed, although adding to the entire SEC system, does not break XBRL.  What we are talking about here are restrictions on XBRL, always using less than what is allowed by XBRL; thus restricting how a user can use XBRL.

Why would anyone require such restrictions?  Well, there are a couple of reasons.  One is that XBRL is a general purpose language, it has to meet the needs of business reporting as a broader use case than financial reporting which is implemented by the SEC.  XBRL provides a number of different ways of achieving something. To make it so users of XBRL within a system pick the say way and are therefore interoperable, restrictions of the approach to achieving something are necessary.

Another reason an application profile's restrictions can be helpful is in making things easier for business users. For example, in the US GAAP Taxonomy, within a [Table], it is guaranteed that you have only two types of child concepts to a [Table] concept: an [Axis] or [Line Items]. Go look at the taxonomy and see for yourself.  Taxonomy creation applications can leverage this consistency and make many things easier for users who have to edit or extend a taxonomy.

Now, a tool which supports a specific application profile may be easier to use because it leverages that profile, but there is a down side.  The down side is that the software which supports one application profile might not support some other application profile.  However, a general XBRL taxonomy editor would support any application profile which stays within the XBRL global specification.  Should like you would never want to create such software, one which supports one application profile of XBRL but does not support another application profile of XBRL.  That is the trade off.  But, considering that business users find editing XBRL taxonomies challenging and considering the size of the SEC XBRL use case, it is highly likely that software application specific to the SEC XBRL implementation will eventually appear.

Another thing worth pointing out is that the US GAAP Taxonomy is not the only application profile of XBRL.  For example, the FINREP taxonomy has its own architecture (i.e. it has its own profile). And COREP also has its own application profile.  Other taxonomies have their own application profiles also.

The fact of the matter is that EVERY XBRL taxonomy has its own application profile!  Some are documented like the US GAAP and FINREP, and others are less documented or not documented at all.  In fact, even taxonomies which do very similar things such as financial reporting have different architectures.  For example the US GAAP Taxonomy, the IFRS taxonomy and the EDINET taxonomy have different architectures.  The International Taxonomy Architecture group is comparing these architectures and working to come up with one common architecture which all three groups can use.

It is quite expensive to create an application profile, more expensive than people first realize.  You need to document the architecture such as the US GAAP Taxonomy and the FINREP documented their architectures, you have to write tests to be sure XBRL software creating XBRL taxonomies and XBRL instances stay within the application profile.  For  example, here are the test cases the SEC had to build. There are hundreds of tests.

Is it possible for the US GAAP Taxonomy, IFRS, and EDINET to all use the same application profile.  Well, actually that may not be necessary as the world is moving toward one set of financial reporting standards, IFRS.  That may or may not actually occur.  Type will tell.  It may or may not be the case that these three rather large use cases can agree on one application profile.  Time will tell.

What if you did not have to create your own application profile; what if you could just pick up someone else's and use theirs.  For example, why couldn't someone simply use the US GAAP Taxonomy architecture and the test case implementations and other infrastructure in their application profile of XBRL.  Frankly, i think that is exactly what people will do.  Software vendors are investing a tremendous amount of money in building the software infrastructure to support the SEC XBRL filers.  That software will meet a rather robust use case.  I believe that the US GAAP Taxonomy Architecture has a good chance at becoming an ad hoc standard for other business reporting use cases.  Time will tell.

What do you think wil unfold?

Here is another blog entry which explains why business users will like application profiles.

Really want to know even more?  Here is a link to a Google search for the term "application profile" on my web site.