Digital Financial Reporting

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?

I started my career the summer that my office of Price Waterhouse, as the international public accountancy firm was called back in 1982, received its first IBM personal computer. Quite a lot has changed since then.  We used these huge paper spreadsheets for audits which provided me with lots of motivation to learn first Visicalc (the first electronic spreadsheet I had seen) and then Lotus 1-2-3. The benefits of electronic spreadsheets were pretty clear to me and I used them, other accountants took years to make the shift. So it goes.

If you are looking at the SEC XBRL filings that you have to create as a nusiance that the government regulators has thrust upon you, you are missing a trend which has been picking up steam.

Between 1982 and about 1998 what I did for work amounted to applying technologies to the financial reporting process to make those processes easier.  My technologies were Excel, Access, the Internet when that became available and in 1998 a thing called XML.  My understanding of XML led to XBRL. The SEC and others thought this was a good idea, the SEC mandated it, and now people bolt on another step to their processes to generate the XBRL so they can give it to the SEC.

My techniques worked in the 1980s and 1990s, but today there are more robust solutions and the problems and their solutions have been given names:

• Business Intelligence
• Performance Management
• B2B Automation
• Business Process Automation
• Enterprise Information Management
• Enterprise Search
• Customer Facing Buiness Intelligence

There are lots of other terms, that is only some of them.  These terms can be hard to get your head around, but Information Builders, a vendor of such solutions, has provided a nice summary of 2 minute videos which explains both the problems and their solutions to the problems.

Information Builders is a partner of the company I work with, UBmatrix. We have other partners, three other stand outs are Oracle, IBM, and SAP.

My point here is that the bolt on processes used today are a short-term solution in the evolution to the longer term solution to not only SEC XBRL filings, but to financial reporting and business reporting in general.  If you are a CPA, this is a great opportunity to figure out what financial reporting is going to look like five to ten years from now.  And I am not talking about just public companies reporting to the SEC, I am talking about financial reporting in general.

Watch the videos I mentioned above. Consider the pain points the videos show. Think about whether you have any of these pain points.  I specualte that you probably do.  Everyone does pretty much.

See SEC XBRL filings as something you may want to consider paying attention to whether you are an SEC filer or not.  There is much to be learned from those SEC XBRL filings should one look.

One of the most misunderstood aspects of the US GAAP Taxonomy and in SEC XBRL Filings is the [Table]. This blog post is a step toward de-mystifying the [Table] and showing that it is the solution to making the US GAAP Taxonomy and SEC XBRL Filings easier, not the cause of complexity. One major cause of complexity of SEC XBRL filings is the inconsistent use of [Table]s. This inconsistency is caused by a lack of understanding of the multidimensional model by most business users. Further, the multidimensional model is used by business intelligence systems (BI) and performance management systems (PM) which are becoming increasingly popular. BI and PM are part of a larger trend toward model-based business reporting. It is increasingly important that business professionals understand the multidimensional model if only to help software vendors appropriately hide that model from business users in their software applications.

Here are two resources which can be used to further study this topic.  This PDF provides more details for the information summarized by this blog post.  This basic example of an SEC XBRL filingcan be used by those who have the intellectual curiosity to dig into the details and further explore this material.

As Ralph Kimball states, the principle attraction of the multidimensional model is its simplicity:

The central attraction of the dimensional model of a business is its simplicity.... that simplicity is the fundamental key that allows users to understand databases, and allows software to navigate databases efficiently

So if the attraction of the multidimensional model is so simple, then why is the [Table] of the US GAAP Taxonomy and SEC XBRL filings so complicated? The US GAAP Taxonomy Architecture, section 4.5, states how a [Table] is implemented. That is not very helpful to business users creating SEC XBRL filing.  It is not intended to be helpful to those business users, it is intended to be helpful to software vendors building software which is used by business users.

Here is why [Table]s are so complicated and how to get rid of the complexity:

• Inconsistent use of [Table]s: The first question one might ask is, "When should I use a [Table] and when should I not use a [Table]."  The US GAAP Taxonomy sometimes uses [Table]s and other times does not.  Yet everything is in essense a [Table], be the [Table] explicitly constructed as a [Table] or be the [Table] implied.  Every piece of information articulated in an SEC XBRL filing has at least two dimensions: the entity identifier and the period. A [Table] does nothing more than add one or more additional dimensions. If everything in the US GAAP Taxonomy where either modeled explicitly as a [Table] or if the taxonomy was better organized so that people could realize that all the things which are not modeled as [Table]s really are [Table]s anyway, then the [Table] would disappear into the background within software applications. Focusing on the XBRL Dimensions syntax is noise and distracts one from seeing the real opportunity to make things easier for business users.
• Software not leveraging the US GAAP Taxonomy's consistency: Current software applications for SEC XBRL filings don't leverage the consistency of the US GAAP taxonomy and expose [Table]s to business users at the XBRL syntax level, rather than hiding XBRL.  This is do, in part, to the US GAAP Taxonomies inconsistent use of [Table]s. Another reason for this is that structure of the US GAAP Taxonomy and documentation does not help see the consistency. If you don't understand the leverage, wait until you see software that does leverage the consistency.  Then you will get it.
• Few large general [Table]s rather than many specific [Table]s: Many of the [Table]s in the US GAAP Taxonomy are huge.  Take the Derivative [Table] as an example. Many specific use [Table]s would be easier to use than the fewer general and larger [Table]s.
• Mixing presentation characteristics and business semantics: The best example of this is the Statement of Changes in Equity.
• Improper [Axis]: The Statement of Changes in Equity is likewise a good example of improper [Axis] used on [Table]s.  The balance sheet is another.  This blog post discusses the balance sheet [Axis].  (Or simply look at this image and this imagewhich shows what [Axis] SEC filers are actually putting on their balance sheets.) The balance sheet in the US GAAP Taxonomy says, by having a Class of Common Stock [Axis] , that every balance sheet line item is associates with a class of common stock which is simply not the case.
• Confusion caused by default dimensions: What default dimensions actually does is confused by two things.  First, the mix of concepts being used in [Table]s and not in [Table]s. This is not only a very bad idea but there are known bugs in XBRL which can surface as a result of this.  The clearest example of why this is a problem is the fact the XBRL Formulas has two explicit models: dimensional and non dimensional.  What is the US GAAP Taxonomy? It mixes the two.  Second, there was a lot of pressure to make the use of XBRL Dimensions and the definition linkbase optional to "make things easier for business users".  This thinking is misguided. This Excel spreadsheet shows the dimensions information for this Basic Example of an SEC XBRL filing. Compare the Excel spreadsheet to the XBRL instance. The Fact Table shows the same thing.
• General confusion, misinterpretation, and erroneous "projection" as to how [Table]s actualy work: It may be the case that one wishes that [Table]s worked in a certain way. Or, one may believe or project into [Table]s how they might work. It is really not that hard to understand how they actually do work: testing.  For example, this Comprehensive Example and this Comparison Exampleshow quite clearly how XBRL actually works. If different software applications reacted to XBRL [Table]s in different ways, we have bigger problems.  But, that is not the case.  The examples respond the same in the four different software applications I tested the examples against. XBRL is consistent.  Users, who generally don't bother to test, reach conclusions as to how XBRL works without the benefit of actually testing. How does one solve that problem? Test.

You can already see that SEC XBRL filers are solving the problems of [Table]s. As you can see on this blog post back in March 2010, one filing agent is putting everything in the taxonomy into [Table]s. This viewer toolhelps you see that the company extensions are modeling everything as a [Table] and consistently with the US GAAP Taxonomy architecture.  I disagree with the use of the "Statement [Table]" as the actual hypercube for every [Table]; I personally believe that each hypercube should be unique and have a unique name. But, the approach of making everything a [Table] with one hypercube is better than mixing the dimensional and non dimensional models.

This can be hard to explain at this point, one has to dig into the details to see that what I am seeing is true.  But this will become easier and easier to see as more and more software vendors do what the software vendor on the link above did.  Once that happens, and it will, things will become easier for business users and understanding the [Table] will be significantly easier.

The XBRL International Standards Board (XSB) published a document summarizing six strategic initiatives which they say will help prepare XBRL for the future. I agree. This is a summary of those six strategic initiatives.

1. Create an abstract model. An abstract model provides a conceptual framework for understanding XBRL and gives developers a strong foundation for implementing XBRL solutions.
2. Produce training materials. High-quality training materials lend support to developers and those new to XBRL.
3. Define standard API signatures. API signatures assist developers with their implementation of XBRL solutions.
4. Reorganise existing specification. A reorganisation of the XBRL specification will make the specification easier to understand.
5. Enhance data comparability. Data comparability widens the applicability of XBRL data across project and international boundaries.
6. Develop application profiles. Application profiles reduce the scope of XBRL implementations by breaking up the XBRL specification into components.

This document and the strategic initiatives are a great piece of work by the XBRL International Standards Board. It is my view that the initiatives summarized in this document are critical for XBRL. Several of the strategic initiatives are absolutely necessary for XBRL to move to the next level in its evolution.

The two key pieces are number 1 (Create an abstract model) and 6 (Develop application profiles). This will lead to number 5 (Enhance data comparability).

Since I learned about the notion of an application profile and logical model from my work on the team which created the US GAAP Taxonomy Architectureand the result of that work which was a paper Rene van Egmond and I put together in 2008, XBRLS: How a Simpler XBRL Can Make a Better XBRL, I have been pushing the idea of using a logical model above XBRL's syntax and application profiles to make using XBRL easier for business users.

Work with the XBRL Taxonomy Arhitecture Working Group resulted in a draft Business Reporting Logical Model and Financial Reporting Logical Model.  I created a straw man implementation of those two models. I have further expanded on that straw man implementation creating a set of meta patterns, business use cases, comprehensive examples, and comparison examples to help prove those two  logical models and better understand these ideas.  You can find summaries of this information here.

Taking this to the next level, I have applied these models to SEC XBRL filings and the US GAAP Taxonomy.  You can find summaries of this information here: Meta patterns, basic example, basic comparison.

Both of those sets of resources are helpful in understanding the business benefits of an abstract logical model and an application profile.

While I am not a software architect, I don't know exactly how to document an application profile.  I do understand a little better how a logical model can be expressed using UML (Unified Modeling Language) or RDF/OWL. I do understand from my detailed work with XBRL over the past 11 or so years that application profiles and logical models which will hide the XBRL syntax which will cause fundamental changes to how business reporting applications which generate XBRL will be created. These changes will result in an order of magnitude improvement is usability of this software for business users.

So kudos to the XBRL International Standards Board for taking this important step. This step moves us significantly closer to the possibility broad use of XBRL by business professionals. I would point out that it was the XBRL International Standards Board, not the XBRL International Best Practices Board which issued this strategic initiative. What that means to me is that these logical models and application profiles will have more teeth to them: standards, not best practices.  Time will tell for sure how all this will play out, but I see the strategic initiatives as a big step in the right direction.

Here are collections of XBRL samples and examples which I have put together. Each set has different characteristics and utility:

• Hello World example: Very, very basic example of XBRL.
• Business reporting meta patterns: Five very small examples.
• US GAAP taxonomy, SEC XBRL filing meta patterns: Several small examples specific to SEC XBRL filings and the US GAAP taxonomy.
• US GAAP taxonomy, SEC XBRL filings basic example: A little bit bigger example, great for business users testing software to see how well the software works.
• Basic comparison, SEC XBRL filings: What amounts to three basic examples, great for testing analysis software and understanding what makes information comparable and what gets in the way of comparability.
• Business Reporting Use Cases: A set of about 30 specific business use cases showing how to model the specific information in XBRL. Has pretty good documentation for each of the use cases. This is great for business users trying to represent specific business use cases in XBRL accurately.
• Comprehensive example: Combines the 30 specific business use cases into one larger report allowing for testing the interaction between the specific business use cases. This is a very sophisticated example, but simple enough, reducing the amount of noise you have to endure to get to meaningful information about how to get XBRL to really work to meet your needs.
• Comparison example: This is three comprehensive examples which can be used to test the analytical capabilities of software.
• Creating an architecture: This has boatloads of information about one architecture or profile of XBRL and is helpful as (a) an architecture you can use or (b) an architecture you can leverage to create your own architecture.
• Other samples and examples: This is a collection accumulated over 10 years of creating XBRL taxonomies.  This example is great if you want to see the trends and ideas which help one figure out why we are where we are today.

For more information see the Learning about XBRL page.