Brainstorming: US GAAP Taxonomy, SEC XBRL Reporting, Business Information Exchange (2010-09-30)

Document which describes the US GAAP Taxonomy Architecture. Summary of the "big picture" plus explanation of important details.

This is part of the foundation of financial reporting as required by the US SEC. Explains how the US GAAP Taxonomy was created and how it should be used.

Two key sections of that document are: 1.4 Physical Model which summarizes the physical model; 4.5 Implementation of Tables which describes what amounts to the logical meta pattern for a [Table].

Draft of the revised US GAAP Taxonomy Architecture.

Comments should be made to the FASB to (a) better describe the information models (roll up, roll forward, hierarchy, etc) and how company extensions should follow those information models.

There are many accounting/reporting issues which need to be resolved, but those cannot be resolved until basic technical things like how to properly extend the US GAAP Taxonomy for company filings.

Breakdown of the US GAAP taxonomy into fundamental patterns which make things easier for business users.

The US GAAP Taxonomy is not random, it has patterns. The number of patterns is not infinite, it is finite. This is a summary of the patterns, called meta patterns. The US GAAP Taxonomy refers to these as Compact Pattern Declarations (CPD)s.

To understand why this is important, see 2009 US GAAP Taxonomy, physical files this blog post.

If this list of meta patterns is not the complete list, then new ones should be added once they are identified. The ones which have been identified are hard to dispute. New ones which should be added need to be justified.

If one looks at these meta patterns, one will notice that they are not unique to US GAAP financial reporting. In fact, they are not even unique to financial reporting but rather apply more broadly to business reporting.

To see how generally applicable these meta patterns are, see this summary which shows how the meta patterns were derived.

Draft of the new 2011 US GAAP Taxonomy.

This is just for reference purposes. There is really little difference between the 2009 and the proposed 2011 US GAAP Taxonomy.

It seems as though the changes between the two versions of the US GAAP Taxonomy should be explained better in terms that a software application can use. For example, XBRL Versioning.

Draft of the new 2011 US GAAP Taxonomy, within a viewer application.

2009 US GAAP Taxonomy, Physical files.

These are the physical files which comprise a taxonomy, in this case the US GAAP Taxonomy. To make use of these files, a software vendor has to write an applcation to read the appropriate pieces of the taxonomy. Each software vendor is doing this coming up with a way to do this independently as there is no standard approach to doing this. Further, there is meta data which does not exist in the taxonomy. There is no standard agreed upon way to add this meta data. Some of this is fundamental stuff like a basic description of each of the files. This causes two things: (a) more work by software vendors to create something usable to business users, (b) harder to use and more expensive software because there is not standard meta data which makes this easier.

Another way to think of this is why can't the process of finding and grabbing the appropriate pieces of the US GAAP Taxonomy be like how iTunes or an iPhone works?

Allows you to preview an SEC XBRL submission prior to actually submitting. For sample files you can submit and information on how to use the previewer see here.

Humans need to be able to see the information communicated in the XBRL files. If they humans (the filers, analysts, others) cannot; then XBRL will never replace the HTML filings. It simply cannot.

Financial reporting standards (GAAP) were not written with XBRL in mind, they are based on a paper-based reporting scheme. There will be an evolution between paper-based reporting and XBRL-based reporting. This could take a few years, or it could take longer if the human readable renderings to not meet the needs of the domain users. Inline XBRL (iXBRL) could be a method of transitioning between the paper-based world and the XBRL-based reporting world.

Provides a view of the US GAAP Taxonomy, Commercial and Indusrial (CI) only. Web pages, rather than a software application.

There are lots of ways to view a taxonomy. A viewer application is one. Web pages like this is another. Each approach has its pros and cons. It seems like the ability to view a company filer's taxonomy on the SEC web site alongside the actual company filing would be a very good thing. The ability to compare company extensions like this application would also be a good thing. The ability to compare a company extension with the US GAAP taxonomy would also be very helpful.

FASB Codification of US GAAP as an online service.

The FASB makes the financial reporting standards available as an online service. More and more links between the XBRL taxonomy and the FASB standards; and from the FASB standards to the US GAAP Taxonomy are becoming available. It is highly likely that other services such as the Wiley GAAP guide and other publishers. Same for other publishers. This information is basically instructions and rules for how to apply US GAAP. These instructions will eventually be incorporated into financial statement creation tools and analysis tools. Why should users need to use multiple non-integrated tools?

You saw the list of the US GAAP Taxonomy files above. This is another list on a basic HTML page.

This list in HTML is maybe easier to read that a file directory. But what if the information about the US GAAP Taxonomy files were communicated in something like RDF?

Here is another protype of the US GAAP Taxonomy files in RDF.

It seems to me that the FASB or someone should make this sort of information (taxonomy meta data) available in a computer readable form. This could be leveraged by all software vendors, could be created well once, reduce implementation costs, make implementations more standard, provide better functionallity for users of the software applications, and provide a standard and expandable "platform" where even more meta data can be added to the US GAAP Taxonomy. This "work flow" and "protocols" make automated processes easier.

This raises the question of at what level do software vendors cooperate and at what level do they compete. Seems to me like standard workflow and protocols in some areas which help expand the software market, allowing more processes to be like what the SEC XBRL finanical reporting process will likely (hopefully) become.

Human and computer readable ontologies (RDF/OWL) relating to US GAAP and financial reporting.

The computer readable information in the US GAAP Taxonomy is the tip of the meta data iceberg. More and more meta data will be created, readable by computers, and therefore leveragable within software applications to make this easier, and even more fundamentally possible, within software applications. The RDF/OWL ontologies are some examples and prototypes. You can use RDF/OWL to do basic things like provide computer readable information and documentation about the US GAAP Taxonomy files, or you can do more advanced things like create an ontology of key financial ratios.

Elements of Financial Statements. See the diagram on page 25, which shows a graphic representation of the fundamental elements of a financial statement.

FASB CON 6 provides definitions and discussions relating to the fundamental building blocks of financial reporting elements and transactions. In particular, see the diagram on page 25 which is discussed next.

Diagram of the breakdown of the types of transactions from FASB CON 6, classes of transactions.

This diagram from FASB CON 6 shows the a breakdown of the different types of transactions in financial reporting. What if an RDF/OWL ontology was created for these (see above, I did that). What if there was a mapping between the US GAAP Taxonomy and that RDF/OWL breakdown of the transaction types. That would enable software applications to read the US GAAP Taxonomy and search, sort, slice, and dice the taxonomy components in interesting and useful ways. This is only one example of what is possible.

Mind map of the physical model of XBRL syntax.

Prototype UML model of financial reporting PDF.

Prototype 1 Mind Map of financial reporting syntax and semantics HTML.

Prototype 2 Mind Map of financial reporting syntax and semantics HTML.

Working with the XBRL syntax is impossible for the average business user. A logical model can hide the XBRL syntax behind a more easy to grasp logical model of business semantics. How a business user interacts with an electronic spreadsheet such as Microsoft Excel is an example of two things: (a) how well a logical model can hide the underlying syntax, (b) the usability and level of mass adoption which can be achieved by creating a good logical model. Mass adoption of XBRL cannot be achieved without a logical model of the business semantics which hides the underlying XBRL technology. This is not to say that something like SEC XBRL financial reporting cannot be made easier to use without mass adoption; it can. But, in order to go to the level of mass adoption, using XBRL in many other domains, things which make XBRL easier to use are helpful.

Basic Example, SEC XBRL Filing. Shows the information model or meta patterns within the US GAAP Taxonomy

This is a basic example of an SEC XBRL filing which makes use of the Business Reporting Logical Model and leverages the information model patterns (meta patterns) which exist in the US GAAP Taxonomy. Imagine a software application which can interact with an information model at the level of the information model, rather that at the XBRL syntax level.

Examples of the information models or compact pattern declarations (CPD) or meta patterns within the US GAAP Taxonomy.

These are the basic meta patterns which are used by the basic example above. These meta patterns exist in the US GAAP Taxonomy. If you look you can see them. These information models can be more clearly exposed and more consistently used in the base US GAAP Taxomomy. But, there is nothing in the SEC XBRL reporting rules which says that company extensions cannot more consistently leverage them or software vendors who create software for those creating such company filings cannot leverage them to make using the software easier. While it would be better for the SEC or FASB or someone to provide better guidance on how to do this, which would create more consistent (i.e. standard) implemenations; such SEC or FASB guidance is not required.

The broader use case of business reporting.

While it would be a very good thing for SEC XBRL filing to be easier, and it can and will be because of the ideas above; the goal of achieving a broader goal of business system to business system information exchange with no IT department involvement is a better goal in my view. Information exchange between business systems is not realy that difficult; an IT person can do it with one hand tied behind their back. Many business systems interoperate with other business systems today, now. But what is not possible today is one business system constructing an automated exchange process with another business system on their on, without the time and expense of bringing in that IT department. That is a better goal, mass adoption of XBRL and other technologies which make this possible.

What does it take to make mass adpotion possible? Is mass adoption possible? Well, in my view the benefits are so huge to the business user that it is certainly worth trying. The health care industry is trying and has summarized what is necessary for success in this video. We need to get the big BI (business intelligence) systems and ERP systems on board, we need to get the smaller accounting software vendors on board, etc. We need to cooperate at the appropriate levels to enable this to happen, and then compete at the approprate levels to win customers. Locking customers into proprietary solutions to this business information exchange problem is not the right way to proceed, as I see it.

It seems as though the financial reporting domain is well on its way toward success. The jury is still out for the broader business reporting use case. Time will tell.

Don't think Web, think Internet. As this Wired article points out, The Web is Dead; Long Live the Internet. Proprietary systems which interact with one another, providing value, as easy to use as a iPhone or iTunes, based on standards, providing business benefit.

Basic Comparison, SEC XBRL Filing. Provides three SEC XBRL filing type XBRL instances and XBRL taxonomies and allows for a basic comparison to be performed across filings.

This example allows for comparability issues to be seen. A close examination of the Measure Relations and the Fact Groups (Fact Tables) provides interesting insights.

Provides three SEC XBRL filing (copies of the reference implementation) type XBRL instances and XBRL taxonomies and allows for a comparison to be performed across filings.

This example allows for comparability issues to be seen.