Digital Financial Reporting

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.

CFO Today in Finance in an article, 18,000 Tagging Errors in XBRL Filings So Far, errors in SEC XBRL filings are pointed out. But that is better than expected, say the SEC and XBRL US, the article points out.

The article is talking only about errors reported by the XBRL US consistency suite.  There is a list of the types of errors included in the list of 18,000 within the article.  It is worth having a look at the list.

No suprise here.  In fact, there are other types of errors which I am seeing in the SEC XBRL filings.  See prior blog entries for those.

I suspect that the SEC will eventually tighten the reins.  No idea when.

I created a prototype or a concept model of something which has been thrown around for years by CPAs in the XBRL community.  I call it XBRL Trends and Techniques. As you look at this, remember that this is a prototype; use your imagination as you consider what this might offer SEC XBRL filers.

The idea comes from a very popular publication of the AICPA: Accounting Trends and Techniques. That web page says that version is its 63rd year of publication. The publication is basically a survey of about 600 companies create their financial statements.  The survey looks at what is disclosed, how it is disclosed, terminology, etc.

My XBRL Trends and Techniques is a similar idea, only it uses XBRL instead of paper or PDF or DVD.

Imagine what amounts to a searchable database of templates which one could use to create their SEC XBRL filing.  It would work like this.

• Step 1: The templates are created (I will get back to this key step in a moment). OK, so some accountant who understands both financial reporting and XBRL puts together high quality XBRL instances, XBRL taxonomies, business rules (XBRL Formulas), and all the other things one needs.
• Step 2: All the templates are organized into an RSS feed.  Here is my prototype RSS feed. I would likely expand the fields in that feed, modeling it after the iTunes format which is becoming a well accepted standard which is well documented and supported. So, this page is just for looks really. The template library is intended to be read by computer applications, such as SEC XBRL filing software.
• Step 3: SEC XBRL filing software reads this RSS feed. It uses the "Title", "Description", "Keywords" within the software application to help the user find what they need. This supplements the complete US GAAP Taxonomy, it does not replace it.
• Step 4: The SEC filer starts with the template(s) of their liking to create their SEC XBRL filing. They could start with a complete model financial statement, or they could pull together pieces.  They could already have a filing and just need another piece from one or two templates for a new disclosure they need to make.
• Step 5: They complete their SEC XBRL filing.

This is somewhat of a no-brainer idea. Accountants can even make money creating templates for complex areas of financial reporting and sell them.  Heck, there could be a marketplace created to connect those who know how to create templates with those who need them.

I said I would get back to how templates are created.  Remember how I said Accounting Trends and Techniques did a survey of 600 financial statements? Why do they limit the survey to 600?  Well, this is because the survey is done by hand and all the pieces are put together by hand.

You know what the best database of these templates is?  Actual SEC XBRL filings. The templates are good because someone has actually used them. This is how financials are created today, using existing SEC filings to see how someone else approached a disclosure scenario.  Both accountants and attorneys who participate in creating filings do this, but they use the HTML versions or even worse, paper.

A great application which has been discussed for years is an interface into the SEC XBRL database of filings, organized by industry, type of disclosure, filing characteristics, etc.  When filers start seeing this sort of functionality within SEC XBRL filing creation software, then they will start to "get" what XBRL is really all about and see some of what is in it for them.

Consider smaller SEC filers, private companies, auditors or accountants who are creating a financial within an industry they do not have a lot of experience with, etc.  These templates can come from anywhere on the Internet.  This is the way iTunes works.  iTunes is an aggregator.  It pulls all the pieces together into a very useful database of music, video, and other media.  Anyone can create an RSS and submit something which will show up in iTunes.  I have done this.  Why can't the same thing be done for XBRL templates for taxonomies, business rules, etc?  After all, it is all in a standard format, XBRL!

Do you have any ideas for how XBRL can be used in the process of creating financial statements?