Digital Financial Reporting

I have created a new website which I am simply calling XBRL Site.  See:  http://www.xbrlsite.com/

On this site I am providing a bunch of XBRL taxonomies and instances which can be used for learning, testing, and demonstrations.  This is a work in progress.  Right now everything is organized on the home page.  That will eventually change.

Several items of specific interest are the following:

• All the taxonomies and instances are being tested by a minimum of two validators of different vendors and I am striving to test these with at least four vendor tools.  I am happy to use more if any vendors want to provide a validator or an automated validation process.  My validators of choice are UBmatrix XPE, CoyoteReporting XRun, DecisionSoft TrueNorth, and Fujitsu's taxonomy and instance validator.  I am using multiple validators to both make sure that the taxonomies and instances I create are of the highest quality and to ferret out any interoperability issues to get new XBRL conformance suite tests created to maximize software interoperability.
• There are a number of RSS feeds on the page.  The RSS feeds can be used to grab taxonomies and instances and feed them to processes.  That is how I am doing validation.  For example, I simply send the URL of one RSS feed to a process that I created using Microsoft Access and about 1 minute later all 80 instance documents and taxonomies from this feed are validated!  Sure beats the old days of doing these one by one.
• There are several "repositories" of instance documents.  These are pretty basic now, but I am going to make these increasingly sophisticated.  The purpose of the repositories are to both provide instances for demos and to test comparability issues from a business perspective.

I do take requests.  If anyone has any ideas or needs something which I think is a good idea, please let me know what it is and I will see what I can do.  If you have or know about any interesting demos, please let me know about them.  If you may want to collaborate on a demo, I am up for that also.

In their 2003 article Business rules validation - the standard the W3C forgot, Paul Warren, Gareth Reakes, and Alberto Massari point out that the W3C forgot something in the XML stack:  semantic validation.

Many business people and technical people tend to miss the importance of business rules or seem to fall back into old ways of thinking about business rules and how to enforce those rules and keep their information accurate.

Part of the reason for this is that may people confuse syntactic and semantic validation.  I know that I did.  In fact, it took me about six months to be able to use the two terms correctly.  I kept confusing the terms, not knowing which was which.

I am not going to go into the difference between syntax and semantics here.  There are plenty of places to dig into this.  The article pointed out above goes into this quite well, but it may not be understandable by a business reader.  But business reader:  it is important to gain an understanding of the differences.

I will point out a few examples of business rules before I get to the real points which I want to make.  Here are some examples of business rules:

• Assets = Liabilities + Equity (i.e. the balance sheet balances)
• The invoice total equals to sum of the invoice line item amounts.
• If you report Property, Plant and Equipment on your balance sheet, you need to provide some specific policies and disclosures relating to that line item.

Business people care deeply about these sorts of things.  Basically, business rules enforce the integrity of information.  They also care about costs and functionallity.

So what points do I want to make?

First, I wanted to reiterate what the article above states which is that XML does not have them.  Can they be created for XML?  Sure they can.  XBRL created business rules (XBRL Formulas).  Many business people and  even technical people don't realize that XML cannot articulate semantic meaning (i.e. business rules), thus the article above and why people tend to not understand the value of XBRL (i.e. it can articulate semantic meaning).  For XML to provide business rules, all that needs to happen is that either the W3C or someone create a process for expressing semantic meaning generally for XML, or each seperate XML implementation creates it on rules.

That is the second point.  Many people just assume that this is part of the deal and go ahead and build the business rules within their application.  What does that cause?  Well, it causes work (i.e. actually implementing that) and it makes it so the business rules cannot be exchanged between two applications.  If this approach is taken, business rules have to be created in two systems:  the system which generates the information and the system which consumes the information.  However, if the rules are expressed using XBRL you get two things.  First, you get much less expensive and more powerful validators.  Second, you can exchange the business rules along with the information which is being exchanged.

The third point relates to this second point.  XBRL Formulas has been discussed since about 2000 in the XBRL community.  There have been some prototype versions of business rules created by members of XBRL International.  The first prototype version was created by KPMG (David vun Kannon and Yufei Wang) for XBRL 1.0.  Many vendors have created their own proprietary versions of business rules, such as my employer UBmatrix whose proprietary business rules validation which is currently being used by the FDIC as we (UBmatrix and the FDIC) wait for the XBRL International specification.

Finally after years and years of work, XBRL Formulas 1.0 is in its second candidate recommendation.  A good size group has struggled to create this global standard specification for creating business rules, such an endeavor is not an easy task.

However, the benefits are substantial:

• There is a global standard way to express business rules.
• There is a global standard way of exchanging such rules.
• The business rules can be created separate from applications.
• One-to-one validation mechanisms are more expensive and generally less functional than rules engines which provide better leverage.
• XBRL validators (i.e. rules engines) are much cheaper and far more functional because there are more users across which the validation engine can be shared thus reducing the cost per user.
• You can validate semantic meaning when you exchange information.
• If XBRL validation does not meet 100% of your needs then sure, create that piece using whatever proprietary mechanism you may need to use.  But, XBRL Formulas provides a lot to leverage.

I will conclude this post by saying thank you to all those who have struggled long and hard to get XBRL Formulas where it is.  Your efforts are very much appreciated.  And thank you to XBRL International members who sometimes did not agree how to best create this global specification, but somehow managed to work through differences, eventually agree on something, and get business rules into the hands of us business users.  Cheers!

OK, try and wrap your head around this.  I cannot seem to get all this totally at the moment, but I am pretty sure this notion is an important.

How are you made aware of financial information today?  Say a company issues a financial statement or a press release making people aware of some sort of information.  What, a press release is posted on their web site or through a wire service or something?  Either you have to go to the web site or a search engine has to find the information and then make you aware of it with some sort of an alert.

Seems that this works backwards from how it could work.  Think about how a blog works.  Why can't notification of financial reports work in that manner, like a blog?  Or a pod cast?

Let's call this FinCasting?  (I just made up the term). 

The SEC provided an RSS feed to XBRL documents filed under the XBRL Voluantary Filing Program several years ago.  I don't know that this is that feed, but here is a current RSS feed the SEC provides to XBRL documents:  http://www.sec.gov/Archives/edgar/xbrlrss.xml

Now, the SEC also modified their system to provide information feeds about filings received.  It looks like the SEC is using ATOM feeds for each filer, providing a means to subscribe to a company's filings, being notified every time a new filing is received for a company you subscribe to.  Here is such a feed to Microsoft filings.  There are other feeds you can subscribe to, based on a conversation with someone from the SEC just to check to be sure that this works how it seems to work.  For example, you can subscribe to a list of recent filings or you could subscribe to a list of particular types of filings, such as only 10-Ks.

The reason all this came up for me is that I was reading this book about Podcasting yesterday and I realized that I had been missing a big point about how I was looking at RSS feeds.  I was looking at them as a mechanism to physically link to a collection of one or more XBRL instance documents.  I missed the "notification" piece.

I talked to someone else about this, just to help me understand what I was seeing, and they sent me some useful links and I added some others:

• Web feeds per Wikipedia "is a data format used for providing users with frequently updated content."  Not sure what "frequently" means.
• RSS per Wikipedia is a web feed format.  This appears to be the most popular format.
• ATOM per Wikipedia is another feed format.  It is supposed to be better than RSS.
• Notification, again per Wikipedia,  seems to be a way web services can talk to each other and share information.  This seems to have a role in this.
• IBM discusses web services notificationand describes them as "WS-Notification is a family of related white papers and specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern."
• Feedhause.com (http://www.feedhaus.com) is a feed aggregator.  This is an interesting idea, seems to put feeds together and create other "super feeds" as best I can figure.
• Mashups seems to have a role in this also, per Wikipediaboiles down to "drawn from pre-existing sources, to create a new derivative work".

What if you could hook an Excel model of some sort (i.e. financial model) to an RSS or ATOM or some other feed which would notify you proactively (i.e. push it to you; you don't have to rely on search engines finding that the information exists) and your model updates based on this new information which has been pushed to you.

More specific example, say an analysis program monitored certain rations, watching them until there was some sort of exception and then a human could get involved to investigate further.  Oh, even simpler, what if a price list was made available in XBRL and changes to the prices list could be automatically communicated to those who need to know about such changes.

"FinCasting" or "XBRL InformationCasting" or "data casting"; basically rather than a web page you can read or a podcast you can listen to, a data or information set which you use within your analysis models.  Man, imagine the possibilities.

The SEC has a lot of data.  Imagine being able to create a mash up that does something like, oh I don't know all the different types of data the SEC has, maybe someone can help us up with a comment and provide an example of what might be possible.

If this seems a bit of a ramble, well, that is because it is.  Not to clear on all this at the present time. 

Geoff Zakaib, the Director of Energy, Utilities & Mining Advisory Services for PricewaterhouseCoopers pointed out to me that the US Securities and Exchange Commission will likely be using XBRL as part of their modernization of oil and gas disclosures.

The final ruling can be found on the SEC web site, see pages 94 and 95.  Section VIII. Application of Interactive Data Format to Oil and Gas Disclosures states in part:

"In the Proposing Release, we sought comment on the desirability of rules that would permit, or require, oil and gas companies to present the tabular disclosures in Subpart 1200 in interactive data format in addition to the currently required format. Most commenters addressing the topic supported the use of XBRL for oil and gas disclosures. They believed using interactive data would be very helpful to investors and analysts."

Making this information available to investors and analysts in this manner is great, but consider how economists might be able to use this type of information.  Imagine economists being able to do a rather simple query and tie their models directly to the information disclosed in the financial statements of every oil and gas company.  Heck, why limit it to just oil and gas companies?

Today, gathering this information can be an excruciating process involving humans rekeying quite a lot of information.  Tomorrow, because the reduced effort of gathering the information, more detailed information can be gathered and used in economic and other models.  Also, because the time involved in gathering the information is less due to the automation of the process, the information will be available sooner.

Financial disclosures of public companies and nonfinancial oil and gas disclosures is a great start and it is great that the SEC is starting this process.  But imagine other places these same techniques for collecting and using this information could be useful.

If people have other ideas where XBRL might be useful in collecting and redistributing information, please leave a comment.