Digital Financial Reporting

Microsoft PowerPivot helps one see the possibilities which something like XBRL enables. PowerPivot is an Excel add in with gives users the flexibility they need but at the same time gives the IT department the control they need. This videohelps you get an understanding of PowerPivot. (Gemini was the initial name for PowerPivot.) This videoshows how and information mashup can be put together.

I have not tried PowerPivot yet, you need Office 2010 to use it. But now I am very motivated to upgrade and try this free Excel add in. Mr. Excel in the second video says this about PowerPivot:

"Greatest thing I have seen coming from Microsoft in 15 years."

Imagine a PowerPivot "database" (not sure what to call it) which combines information internal to your organization and information external to your organization working seamlessly together to help you manage some aspect of your business supply chain. I have heard this called "external analytics".  Your data set is connected to other data sets external to your organization.  Perhaps the SEC XBRL data set as an example of one publicly available standardized set of information.

Not interested in public company financial information?  That is not the point. While the SEC XBRL data set itself might not be useful to you, think of other data sets which could be useful.

There are four overarching trends which work together to make this sort of vision possible:

• The Internet. If we were not all connected together there would be less of a possibility to be able to exchange information because of the expense of doing so. Lots of people exchanged information before the Internet existed, now anyone can exchange information with anyone else for pennies. I am talking about the Internet here, not the Web. If you don't understand the difference, you definitely want to read about how the Web is dead.
• Model based reporting. Business intelligence (BI) applications are growing in popularity. One example of this is how BI applications are changing the last mile of finance. One of the core pieces of BI is use of the multidimensional model which provides flexibility.  You can use the same piece of information in different ways. The important piece here is not BI, it is the flexibility of the multidimensional model. This OLAP Council white paperhelps you understand why the multidimensional model is important.
• Structured, standard data formats. Unstructured information such as a word processing document or HTML file or PDF file makes reusing the information in those files impossible. But structured information can be put into a database and reusing it is quite easy. But you need your database to connect to someone else's databaes. So if one database is going to be connected to another database; what is the standard database format which you are going to use? Well, of course, it is your database format, right?  Well, others with different database formats would likely disagree. There is no standard database format. Nor should there be. But, you have to somehow link systems together and you need some syntax to do that. XML, RDF/OWL, XBRL, CSV, it really makes little difference.  As long as the format is understood, technically anything can be integrated.
• Semantic and process interoperability. In addition to the technical interoperability, you still need semantic interoperability and process interoperabilityto achieve business system to business system integration. An example of this is how I can use my Apple iMac and create a video in iMovie and then upload it to Google's YouTube.com.  Two different applications, two different companies, working together seamlessly.

All this sound mind-numbingly complicated to you?  Don't worry about it.  That is what technical people do, they make stuff like this work. What is important to understand is that fundamental changes are coming to business processes.  One example is financial reporting.

Don't be fooled into thinking that the SEC's little experiment with XBRL is a misguided regulatory mandate which does little more that add unnecessary costs to a process which works fine today. The SEC is being quite progressive, not something one might expect from a government agency. What the SEC is doing is only part of a larger global trend started by little regulators like the Dutch Association of Water Board as early as 2004 and bigger regulators like the Federal Deposit Insurance Corporation (FDIC), and others. These government regulators are only priming the pump.

While I do think PowerPivot has its short comings such as it requires you to have Excel (i.e. it is proprietary to one vendors software) and it cannot be used to create content, only report on content and it seems to be focused on numeric information (i.e. I have not seen it handle textual information); PowerPivot is a very nice piece of software which helps one see the possibilities.

It is getting a little easier to communicate issues relating to XBRL reports. The biggest problem in doing this is that most people don't know how to "read" XBRL.  But as software applications become available being able to understand these sorts of issues will become easier.

There are a number of issues relating to doing basic comparisons of SEC XBRL filings. I am fortunate enough to have been dinking around with XBRL for over 12 years now, I can pretty much look at XBRL instances and taxonomies and figure most things out.  During this time I have built a multitude of software applications to help me read XBRL easier and communicate information to others.  I have taken that up a notch, combining about 10 different software tools into one tool which I call my XBRL audit or query or analysis tool.

That XBRL audit/query/analysis tool can generate a report which focuses on networks (i.e. extended links), hypercubes (i.e. [Table]s in SEC XBRL filings) and dimensions (i.e. [Axis] in SEC XBRL filings). 

Here are six different reports which I will use to make a few points. The analysis reports show different characteristics. The  focus here is comparability of the XBRL instance information.  I will look at how networks, hypercubes (i.e. called [Table]s in SEC filings), and dimensions (i.e. called [Axis] in SEC XBRL filings) impact comparability. So here are the reports with a bit of information about each report.

1. Analysis of Apple SEC filing: Actual SEC filing.  Note that all concepts reported are modeled within [Table]s, in the case of this filing, the [Table]s are always the same, "Statement [Table]".
2. Analysis of Heinz SEC filing: Actual SEC filing.  Note that not all concepts reported are modeled withn a [Table], you will see that many networks say "xbrl:No [Table] (None)" in the column headed "[Table] (i.e. Hypercube).
3. Analysis of SEC Model Filing I created: Test SEC filing I created to make some points. Note that every concept is modeled within a [Table] which is similar to the Apple filing, but in my case every [Table] has a unique name which identifies the concepts in the [Table], rather than using "Statement [Table]" for every [Table]/hypercube.
4. Analysis of Comparison Example ABC Company: Prototype GAAP filing created to test comparability.  This was build to be comparable with the XYZ Company and QQQ Company filings below. Note that all three filings use [Table]s (which are called Fact Groups as they follow the straw man implementation of the Business Reporting Logical Model (BRLM).
5. Analysis of Comparison Example XYZ Company: Prototype GAAP filings, built to be comparable with ABC Company above.
6. Analysis of Comparison Example QQQ Company: Prototype GAAP filings, built to be comparable with ABC Company above.

To start off let me say that this is not about my personal view as to what should or should not be comparable, that is not the point.  The point here is this: if you want comparability, there are ways to get it and there are ways to make comparability more difficult to achieve.

You may want to start off doing two things.  First, scan each of the reports which I have linked to noting what you have in each report.  Then, compare the reports looking for similarities and differences between the reports.  If you are really interested in this and want to do some extra credit work, note that each of the analysis reports links to the actual XBRL instance. Take the actual XBRL instances and try to compare them in some XBRL analysis tool.  Try to compare 1, 2, and 3.  Then try and compare 4, 5, and 6.

OK, so to my points (it helps to open all 6 reports above in your browser and bounce between them as you read this):

• All information is "dimensional", don't confuse syntax and semantics.  A lot of people freak out when you talk about XBRL and dimensions. The truth is that all information in XBRL is dimensional. The dimensions are expressed using different syntax options, but the information is dimensional.  If you look at the column headed "[Axis] (i.e. Dimension)", you will always see three dimensions for every "chunk" (sets) of information: xbrl:Concept [Axis], xbrl:Entity [Axis], and xbrl:Period [Axis]. Other [Axis] may be added by taxonomy creators, or not.
• Comparability is impacted by what [Axis] you have and what level the [Axis] was defined.  If different hypercubes have different [Axis], the information will not be seen as comparable by software. There is a higher probability of comparability if an [Axis] is defined at the "GAAP" level than at the company/filer level.
• Comparability is impacted by networks and hypercubes [Table]s. Just as with the [Axis], comparability is impacted by networks and hypercubes; and the level that networks and hypercubes are defined impact comparability.  For example, note the Apple and Heinz filings, seeing that every network was defined by the filer.  Therefore, no networks in either the Apple or Heinz filing are the same.  If you look at the Model SEC filing, note that there are (illegally, the SEC does not allow this) a few US GAAP Taxonomy defined networks.  If Apple and Heinz had both, say, used the US GAAP Taxonomy network for the "balance sheet", then one could get the "balance sheet" for both Apple and Heinz.  If you contrast that to the ABC Company, XYC Company, and QQQ Company reports you will see that all but one network is the same in all three reports. The same deal with hypercubes.  If one uses no hypercubes or uses hypercubes which  are all the same then basically the hypercubes [Table]s are useless.  But, if each hypercube is unique, the hypercubes can be used as a basis of comparison.  In filings 4, 5, and 6 all the hypercubes are unique and one could use the networks OR the hypercubes as the basis for comparison. (Except for the last network (QA, Part 1: Variance Analysis) and hypercube (Variance Analysis, Gross Profit [Fact Group]) which were defined at the company/filer level, and therefore is harder to compare as a computer will not understand them to be the same.
• If networks or hypercubes are not the fundamental basis for comparison, what is?Suppose you want to go grab all the accounting policies for a filing. Or any set of anything really. Try to find those "chunks" (sets)  of information in any one SEC XBRL filing, or even more useful in any two SEC XBRL filings so you can actually do a comparison. It does not appear to be possible at the network level.  [Table]s are not comparable either.  Comparisons of individual concepts is useful, but too detailed and the concepts are best understood within some context (i.e. some set of information, like a balance sheet).

Some people say that you can throw software at the issues shown above and let computers sort all this out. That can happen to a degree.  For example, clearly you can write a program to go find "Assets" and "LiabilitiesAndEquity" and there is a good chance you found the balance sheet.  But maybe not, you may have found a segment breakdown.  Some things are possible using brute force and software, but one will still have to define the sets somehow.

Particularly for less sophistocated users trying to glean information from these filings, it would be better to use networks, hypercubes, and dimensions to define information rather than fight with them.  The first three XBRL instances show the hard way, the last three show an easier way. 

Which approach do you feel is best?

Well, first of; this really is not a dilemma.  It is a misperception, a trap that many people fall into. The bottom line of what I am trying to show with this blog post is this: If you create an accurate data model, then rendering (any rendering format) is not that challenging.  But if you create a poor data model based on presentation, you go down a non-scalable, ever ending slipperly slope.

Let me explain. But first, let me stay that the seemingly never ending argument about whether to use a document centric approach to modeling a taxonomy or a data centric approach to modeling a taxonomy will end when good software exists which shows that if you have an accurate data model than any presentation is possible. Further, once people see what you can get from a computer application in terms of viewing financial information they will ditch their two dimensional paper centric view of the world.

I feel as though I have created example after example to make this point. I have created yet another example specific to SEC XBRL filings and the US GAAP taxonomy.  It shows the issues better, but it is still to hard for people who don't have a skill for reading XBRL syntax well to see. But it is better.  I am using the SEC XBRL renderings to help make the points I want accountants to see.

To make my point, first look at the statement of financial condition, classified, commercial and industrial companies from the US GAAP Taxonomy.  I have provided an HTML rendering of that network here. If you look closely within the equity section which starts at line 419you will see that the facts which show up as line items on the balance sheet are intermingled with the information relating to classes of common stock, preferred stock, and treasury shares which is typically disclosed within the labels of the line items. In particular look at line 450 through 480.  There are other issues, but lets focus on the common stock and preferred stock information.

The first step toward seeing the issue is to remodel the balance sheet correctly.  I did this in my XBRL Trends and Techniques prototype. Specifically, go to my remodeled balance sheet template. You can see my remodeled template for the balance sheet here. In you scroll down to about line 439 you can see that I separated the balance sheet line items and the class of stock information relating to common stock, preferred stock, and treasury shares.  (I also removed the partnership line items from this template because no company is both a partnership and a corporation and most (all) of the SEC filers I am working on are corporations. I also fixed the [Axis].)

The key concepts to look at are these three concepts: Common Stock, Value, Issued (Line 412 and 450); Preferred Stock, Value, Issued (Line 410 and 473); and Treasury Stock, Value (Line 420 and 495).

The reason those three concepts are so important is because they are the intersection between the balance sheet line items and the class of stock breakdowns.  You can see this clearly in the validation results for the business rules for the XBRL instance. The business rules make sure the total amounts for the classes of stock add up to the balance sheet.

This is where the dilemma comes up. Under US GAAP financial reporting, few (and maybe no) companies show the total dollar amount for all classes of common stock or preferred stock on their balance sheets.  They show the amounts for each class of stock as the line items.

Now, that is no big deal to model and make render correctly.  You simply create a concept "Common Stock, Value, Issued, Class A" and "Common Stock, Value, Issued, Class B". Then the balance sheet will add up correctly and the rendering will look as one desires.  But if you do that, then you will have to create duplicate concepts for the "Common Stock, Value, Issued" which breaks out the detailed information for the class which you do have to provide.  So this is really not a dilemma, you can do it.

But the problem is those duplicate concepts.  Duplicate anything causes problems for computers and potential for error.

In the long run, I suspect (hope) that accountants will realize two things.  First, the right way to model this information is based on the characteristics of the information, not how that information is presented.  Second, if the information is modeled correctly, it is very possible to create a rendering engine which has a rather simple algorithm to show not the total concepts for common and preferred stock, but rather the values for each class.  There are only a few components of equity which would ever need adjusting in this way.

The bigger issue is that there are other balance sheet line items which act this way. If some concept is important it needs to be "presented on the face of the financial statements".  But an XBRL instance has no face.  And, XBRL allows you to use a computer applcation to move detailed information and summary information together, drilling down (or up) to move from summary to detail or detail to summary. Basically, "presented on the face of the financial statements" is an obsolete notion in our digital world.

But today, "presented on the face..." is the law.  It has to be dealt with. You can do this by creating an accurate data model which models the reality of the underlying data.  You may need to create some duplicate concepts to do this for now and a few business rules to ensure that the duplicated items are correctly in sync.  But modeling the information only for presentation, disregarding the reality of the information and the reality that computer systems are going to have to read and use this information and provide it to analysts is not an appropriate solution.

There are many areas where you have detailed and summary information in the US GAAP Taxonomy and SEC XBRL filings. Understanding how this works is the first step to properly modeling this information. Good tools which allow accountants to see the impact of their modeling decisions will move us a long way to understanding and solving this issue.

Since about June 2010 I have been fiddling with, testing, tweaking and otherwise experimenting with a set of about 53 XBRL instances and XBRL taxonomies. The purpose of the experimentation was to figure out the best approach to using XBRL. As a result of this experimentation, I have reached a number of conclusions about using XBRL. They are summarized below.

This is the set of 53 XBRL instances organized within an RSS feed. Why the RSS feed? Because it provides both a quick way to access the XBRL instances and the related taxonomies manually and using a software application. You can find documentation for this set of XBRL instances and XBRL taxonomies here on my Learning about XBRL page of my blog. See the section Samples/Examples; you should be able to reconcile the RSS feed documents and the documentation. I will create easier to follow documentation at some point.

Two goals of the experimentation were to test the Business Reporting Logical Model / Financial Reporting Logical Model and figure out the best approach to creating SEC XBRL filings.

Conclusions

This is a summary of the conclusions which I have reached:

• XBRL has a logical semantic model. While that model is not well communicated or explicitly communicated, if you dig deeply enough, it is there. What makes it so confusing to see are the many different XBRL syntax options. If you look at the Fact Group and Measure Relations Info sets provided with the examples, you can see the logical semantic model.
• Inconsistency within an XBRL taxonomy causes confusion. If you create an XBRL taxonomy and the definition linkbase, presentation linkbase, and calculation linkbase are inconsistent; then you cannot expect a software application to correctly interpret the XBRL instance information. Said another way, consistent XBRL taxonomies enable clear XBRL instance information.
• Good semantic models can be reconciled to one another; bad semantic models cannot. Even if software vendors don't implement precisely the same semantic model within their software, if the models are good models you will be able to reconcile the models to one another.
• The Business Reporting Logical Model can be helpful in creating a consistent XBRL taxonomy and XBRL instances; but it is not required.  As I started this journey I had been told that there is a logical semantic model buried within XBRL but did not believe it. Now I do believe it. I thought that you needed to have something like the Business Reporting Logical Model to create a good taxonomy.  But that was a mistake.  It helps, but as long as you end up with a good XBRL taxonomy; you don't necessarily have a documented model. I don't think COREP and FINREP have a documented model, other than a good XBRL logical model.
• Consistent extensions lead to usable XBRL instances. There is no difference between a base XBRL taxonomy and an extension XBRL taxonomy. A taxonomy is a taxonomy. Inconsistency between a base and an extension causes precisely the same problems as inconsistencies within an XBRL taxonomy.
• Throwing away pieces of XBRL is not the solution to the inconsistency issues. I had erroneously thought that the path to XBRL nirvana was to get rid of typed members, tuples, custom segments and scenarios.  That is unnecessary.  Each of the different pieces provides a needed feature. If you understand what the different pieces of XBRL syntax provide and use them correctly and consistently things will work out fine.  That said, most people don't need every feature. The only thing I would get rid of in XBRL is the precision attribute, using only the decimals attribute on an XBRL instance fact.

The bottom line: be consistent and clear when you create an XBRL taxonomy. Work at the logical semantic level, not the syntax level. While agreeing on the logical semantic model makes cross XBRL taxonomy interoperability vastly more efficient; as long as you are consistent and clear in your XBRL taxonomy, then XBRL will work for you within your system.  Something like the Business Reporting Logical Model can help you achieve the needed consistency, it is not required and can be achieved using other means.

The ITA (Interoperable Taxonomy Architecture) project has published a global filing manual for financial statement-type XBRL filings to regulators. You can read more about The Global Filing Manual here.

If you recall from a blog post around May 2009, the ITA is a joint initiative between the US SEC, the Japan FSA, the European Commission and the IASC Foundation XBRL team, and aims to converge the XBRL architectures of three taxonomies: EDINET, IFRS and US GAAP. The announcement states of The Global Filing Manual:

The manual contains a set of rules which provide guidance on the preparation, filing and validation of XBRL filings created using the IFRS Taxonomy, the EDINET (Electronic Disclosure for Investors’ NETwork) Taxonomy or the U.S. GAAP Taxonomy.

I have not been through the 65 page manual yet, and I don't know if the SEC is going to require the manual.  What I speculate is that if you are compliant to the EFM (Edgar Filer Manual), then you will likely be compliant to The Global Filer Manual. If that is the case, then while I would see is global manual as insufficient, it shows an attempt to move toward one global syntax for financial reporting. Key to achieving global financial reporting is how close the US will move toward IFRS (International Financial Reporting Standards).

What is interesting is the trend I see. CFO: 18,000 Tagging Errors in XBRL Filings So Far, XBRL for the Future: XSB Releases Strategic Initiatives calling for abstract models in UML and application profiles, the investment roadmap published by FIX, FPL, FpML, ISITC, SWIFT, XBRL and FISD. The trend: People seem to be getting more and more interested in the quality of XBRL.

I predicted a lot of this in my book XBRL for Dummies. For example, I explain and promote the use of application profiles in my book.

All this will result in XBRL which is easier to use for business people. I also see this as another step closer to achieving a global standard financial statement not for just public companies, but for all companies: public and private.