Digital Financial Reporting

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.

An interesting FSN article (titled Runbook CEO, Herman Heller, says automation of close processes is set to change the annual audit) talks about how automation of the financial statement close process will change the audit process, making auditing even more of a commodity than it is today. 

Here are some of my favorite statements in the article:

According to Runbook and its devotees the accountancy world is on the threshold of one of the biggest changes in its history. In the next decade, recent developments in information technology will drastically change the role of the accountant during inspection and review of a company's financial statements. Auditing will become even more of a commodity.

And this...

It is this level of automation and dependency that Heller believes will not just revolutionize the process of closing the financial year and quarter, but also the structure of the accountancy industry itself.

And this...

"We believe this new model for period closing will turn the accountancy world on its head. Auditing costs can be reduced drastically; a result that especially the corporate world will appreciate," adds Heller.

And this...

Heller believes that there will be little downside for accountancy firms.  "Society is gradually changing the demands it sets for accountancy firms, in part caused by their role in the recent financial crisis. Public opinion is calling for more safeguards against financial risks. Partial automation of the auditing process will give accountants the opportunity to shift their attention in this direction."

And finally:

In the end it's a matter of adapting or losing for accountancy firms, because there is no way back. CFO's are already welcoming the new auditing model, because it saves them time and money. The Dutch Tax Authority has given its permission to use it and it's a matter of time before the first accountancy firm will adopt this new model integrally. From that moment onward, competing accountancy firms are left without a choice. But when accountancy firms will adjust their procedures accordingly, they too will become winners in this new model.

At the same time the author is pointing out that accounting firms have little to loose, but fear this new model.  Sounds like opportunity for those willing to learn about the new model.