Digital Financial Reporting

Like I had mentioned in several other blog posts, I have been fiddling around with RDF and OWL to try and understand what RDF and OWL can be used for and how they relate to XBRL.

Well, I have some initial prototypes which I was able to put together:

• Prototype Ontologies: These are some prototype ontologies.  I started off creating one ontology and then quickly realize that there are really a number of ontologies working together here, it was better to break them up, to modularize them. The ontologies "link" to one another, or should.  I don't have all those linkages in place yet.
• Prototype RDF: This is information about the US GAAP Taxonomy expressed in RDF.  Here is an HTML version of what is in the RDF file. What the file does is create something readable by a computer application to help them work with the US GAAP Taxonomy files.  For example, imagine a software interface being built which will help a use of the US GAAP Taxonomy find and pick the files they need to use.  (This is as compared to having to read the documentation and ferret through the files to find them.)

I am learning quite a bit. RDF by itself is kind of like using XML without an XML Schema.  What I mean is that XML can be "well formed" but if you don't follow an XML Schema it is easy to break your application or go outside the bounds of what an application expects.  OWL serves somewhat of a similar purpose for RDF.  It "guides" the directed graphs created by RDF, it seems, helping to articulate what is logical and allowed and what is not.  OWL also seems to provide short cuts for articulating relations.  This may not make sense to people, I admit I am not doing a great job of explaining this right now.  More later.

Another thing I am learning is that several people have expressed XBRL in RDF of have talked about it.  From what I am seeing thought is that all attempts appear to be focused on the XBRL syntax.  Personally, I think this is a misguided approach.  This may be minimally useful for some things, but it seems to fall incredibly short of what OWL and RDF really could provide.  OWL is a great way to express the pieces of the domain of financial reporting, how the pieces interrelate, and in ways you can use that information within a software application.

I get the impression that XBRL people seem to be a little "fearful" of OWL/RDF; and that OWL/RDF people think that XBRL is making a big mistake and that XBRL International should have used OWL and RDF for expressing the XBRL syntax.  I don't really understand either of these views.  OWL and RDF did not even exist in a form where they could really have been used by the creators of XBRL.  The use of RDF was discussed and was considered too immature at the time.

Both RDF/OWL and XBRL are syntaxes. XML and XML Schema are syntaxes also.  What is more important is what you can do with the syntaxes.  This is not an either/or deal.  One should be able to switch between RDF/OWL, XBRL, XML/XML Schema just like on can switch between HTML, PDF, and Word syntaxes.  Those are just syntaxes.

What is more important is the semantic model of the domain.  Express that in whatever syntax.

Now, something else that I am realizing is that in order for RDF/OWL or XML/XML Schema to be truly useful one needs to build, on top of those syntaxes, much of what an XBRL processor provides.  That is where the magic is for business users.  The fact of the matter is that most XBRL processors don't even go far enough; they focus on the XBRL syntax!  We need another layer above the XBRL syntax for XBRL to be truly useful in a business domain, for example the domain of financial reporting.

For example, take a look at SEC XBRL financial filings.  All the applications which I have seen focus on the XBRL syntax level of the problem of creating SEC XBRL filings.  I have not seen one that leverages the domain model or the US GAAP Taxonomy Architecture.

Contrast the SEC XBRL implementation to the FDIC implementation of XBRL.  Not many (I am not aware of any) FDIC filers use XBRL tools to file with the FDIC.  They all use specialized software which is used to create bank call reports which are to be filed with the FDIC.  Why can't specialized software be built for doing SEC XBRL filings?  Why can't that specialized SEC XBRL filing software be as easy to use as FDIC filing software?  Well, frankly, I think specialized SEC filing software can be built.  That is my point.  And that software will be vastly easier to use than generic XBRL software.

Even better would be if software was adaptable to either the FDIC, the SEC, or other implementations of  XBRL.  What if XBRL software was configurable to a number of profiles?  After all, all these have to ultimately generate XBRL.  These application profiles should be built not focusing on the XBRL syntax but rather on the business domain semantics.

More later...back to fiddling around with RDF and OWL.  Come on in, the water is great!

I make it my business to understand how certain things work. What I have discovered is that if you understand how something works, then you have a better understanding of what you can do with it and what it will not work for.  Back when the Web was growing in popularity (early and mid 90's), I took a year off from work to study the Web because I thought it was important and I did not have the time to make the investment that I felt I wanted to make while having a day job.  That investment paid huge dividends for me in my career as a CPA.

Web 3.0, referred to as the Semantic Web, is a similar deal. There is a difference this time; I don't have to take a year off.  I actually get paid to understand these sorts of things now.  What I want to understand is exactly how XBRL fits into the Semantic Web.

Probably for five or more years I have been trying to truly grasp what is meant by "the Semantic Web" and how the Semantic Web will impact CPAs, internal and external financial reporting, and business in general.  Plus I wanted to know how XBRL will fit into the Semantic Web.  I cannot say that I am totally clear on the impact that the Semantic Web will have on business, but I am getting an idea.  What is becoming clear is how and why the Semantic Web will work and XBRL's role.

Resources to Understand the Semantic Web

I have read a number of books on the Semantic Web.  Two books in particular stand out, providing the most useful information.  These two books are:

• Semantic Web for Dummies: This book provides a concise summary of key information in terms that a business reader can really relate to.  It really focuses on the issue of exchanging business information between business systems.
• Programming the Semantic Web: Don't be scared off by the word 'programming' in this book.  The book has an excellent big picture summary of the problems the Semantic Web is trying to solve and how it will actually solve those problems.  It talks a lot about data modeling and has an excellent section titled A Contract for Meaning which is itself worth the price of the book.  You can skip the programming related sections in the book.

A Contract for Meaning

Business users should be able to relate to the notion of a business contract.  What does a contract provide?  It documents understanding between parties for a certain business transaction.  Having no contract at all can lead to misunderstandings and misinterpretations.  Not always.  A well written contract has fewer misunderstandings and misinterpretations, let's call those "issues".  Those issues cost you time and money.  If you don't agree, then you have to get expensive lawyers involved to sort things out.  Not good, for anyone except the lawyers.

Misunderstandings and misinterpretations (i.e. issues) can come up with business information transactions also.  Except that when the issues occur you don't call the lawyers, you call the IT department to solve the issue or more often you may just throw a person at the problem, that is called rekeying.  Both the IT department and those people that do the rekeying cost time and money.

How do you know if you got the business information exchange contract correct?  The system works.  That is the ultimate test.  You get consistent actions based on a set of data, the results you get are expected.  People take this for granted, in fact I think that people SHOULD take this for granted, at least the business users should.  But what makes it work?

What makes this work is that contract for meaning.  How do you write that contract?  Who writes the contract?  One of the things that I learned about in business is that if you are doing an important contract then you want your lawyer to write the document.  That way, you have better control of what goes into that business contract, the subtleties.  When you are creating an information exchange contract, would these better be written by business people or IT people?  If the IT people create that information exchange contract, how do you know that they got it right?  Business people need to be able to understand this stuff.

XBRL Taxonomies: A Contract for Meaning

One form of writing an information exchange contract is an XBRL taxonomy.  How many business people actually understand XBRL taxonomies?  I mean really understand them, not look at them and glean a little information.  Are you sure the XBRL taxonomy works the way you want it to work?  How can you tell if it does?

XBRL and the Semantic Web

There are a lot of forms in which information is stored: relational databases, multidimensional databases, columnar databases like spreadsheets, hierarchical databases, graph databases, object databases, and so forth.  Each type of database has its pros and cons, none is perfect, certain types are better in certain situations.

XML is a serialization or representation of information.  XBRL, an XML language, is likewise a representation of information.  XML is a web technology for exchanging information on the Web.  It is not the only one, there are others.

Web of Information

Let's say you want to query information but the information is in two (or more) different types of databases in two different businesses or government agencies.  That is what the Semantic Web is about, hooking all that information together.  The Semantic Web is about having some least common denominator that lets the databases work together to answer your questions.

How is that done?  That is what RDF (Resource Description Framework) does. RDF uses a technique which was also used by Aristotle during his lifetime in 384 BC to 322 BC where information is broken down into fundamental building blocks of "subject-predicate-object" relations.  Aristotle's logic was used in philosophy, long before computers even existed. These relations are expressed in the form of very flexible graphs.  (Note that XBRL networks are also graphs.)

Basically these subject-predicate-object graphs can be used to express any information.  They are quite flexible.  An ontology provides a precise meaning of the relations which can or must exist within these graphs, it is a way of controlling the graphs.  These models are expressed using OWL (Web Ontology Language).  Ontologies express formal rules.  This is the contract, a contract for meaning.  The purpose is to make it so different software performing specific actions get the same result.  Fundamentally what this means is that if you have the right ontology then things work as expected, if you don't have the right ontology then things don't work.  It is really as simple as that.

An XBRL Taxonomy is an Ontology

They are called taxonomies in XBRL, but they can really be a list, classification, taxonomy, or ontology depending what meaning you put in them. (To understand the difference see this blog post.)  Frankly, the syntax (XBRL, OWL, whatever) is not really relevant.  What is relevant is the meaning that is expressed and whether that meaning can be consistently interpreted by software applications.  An XBRL taxonomy and the related XBRL instance could be expressed using RDF and OWL and the business meaning of either syntax should be exactly the same.

Why this is Important to Business People

Remember what I said about the information contract earlier?  The part about the IT department getting involved and the rekeying.  That means time and money, something that business people can relate to. OWL, RDF, graphs, and subject-predicate-object relations may be harder to relate to. 

Building the right information models and understanding those models and how they work is important to business people.  Partly because it helps you get the right information model.  Another reason is because understanding how these sorts of things work and why they work can mean that you can use these tools strategically and/or tactically to make things better, faster, and cheaper.

XBRL is only one data format which will be part of the Semantic Web, note the capital letters, that is like the Web, the public network.  You will also have your internal semantic web or webs. Your internal webs will likely interact with the external public Semantic Web.

Everyone is a ".com"

I never really understood when people referred to a company as a ".com".  I think that people realize that every organization is a ".com" and needs to leverage the power of the Web, whether you are public, private, government, not for profit, or some other type of company.  It can mean losing sales if your company shows up on page 5 of a Google search, as compared to page 1.  Using semantic information can provide advantages over those what do not, be that information in XBRL or some other format.

If you thought that XBRL was only a regulatory mandate from the SEC or some other regulator, think again.  Just as people eventually recognized that everyone was a ".com", they will likewise recognize that fitting into the Semantic Web has its advantages.  The book Pull: The Power of the Semantic Web to Transform Your Business helps explain this.  You can find more information here.

XBRL is part of this, in fact some refer to XBRL as one of the most successful Semantic Web metadata formats.

It is my personal view that the Statement of Changes in Equity in the US GAAP Taxonomy is very odd and will not work properly for the reasons I will list in a moment.  The information in this blog post is to help accountants understand this section of the US GAAP Taxonomy better, help you understand other sections of the taxonomy better because of a better understanding of the statement of changes in equity, and to empower accountants to provide better input so that a better statement of changes in equity can be modeled in the US GAAP taxonomy.

First off, let me give you a few links to help you to go and look at the statement of changes in equity. I am using the commercial and industrial companies (CI) version of network 148600 - Statement of Shareholders' Equity and Other Comprehensive Income.   Here is a link to the taxonomy viewer provided by the US GAAP Taxonomy.  This is the same information presented in a slightly different way, a flat list that you can view rather than a hierarchy which you need to open. There are other statements of changes in equity in the US GAAP Taxonomy.  The ideas in this analysis apply to every one of those.

I am looking at this statement from the perspective of an accountant.  I do understand the XBRL better than most accountants, I realize that.  This is the point of the statement that this is odd.  If more accountants undersood these things, I specualte that they would agree with me.  Here is my list of reasons why the statement of changes in equity is very odd:

1. Nothing else in the US GAAP Taxonomy is modeled in this manner.  There is nothing else in the US GAAP Taxonomy that is modeled in the manner that the statement of changes in equity is modeled.  Sure, the word [Roll Forward] is in some of the concepts, but it looks like no other [Roll Forward].  This makes the statement of changes in equity harder to understand.  Basically the approach used is to have a bunch of [Line Items] and the funky axis "Statement, Equity Components [Axis]" (which you can see here or here) and the intersection of the line item and the axis is the "cell" into which the fact value would go.  Semantically, this is NOT how a statement of changes in equity works.
2. The statement of changes in equity is a collection of [Roll Forward]s.  This goes with the first statement in that there are a lot of things in the US GAAP Taxonomy which are similar to the statement of changes in equity; all the other [Roll Forward]s.  That is what the statement of changes in equity is, changes from a balance on one date to the balance on another date.  That is what every [Roll Forward] articulates.  Why does this statement not follow that pattern?
3. You get lots of strange contexts which makes validating computations significantly more difficult.  The resulting "cells" of information have different XBRL Dimensions information within the context.  This causes two things to happen.  First, you cannot use XBRL calculations to validate a simple calculation which can be validated in normal [Roll Forwards] (the changes piece) and XBRL Formulas to validate the changes in the balance are likewise more challenging to construct.
4. You have no idea which combination of [Line Items] and [Axis] are allowed.  It is not the case that every [Line Item] can be within any or every equity component.  Because of the way this is modeled, additional rules have to be created to tell you which [Axis] is allowed on which [Line Items].  This is unnecessary with other [Roll Forward]s, the [Roll Forward] provides you with the list of useable concepts.  (Again, this is why this statement should be modeled as a [Roll Forward].
5. Concepts used in this statement don't "fit" into other areas of the XBRL instance.  The statement of changes in equity contains lots of things which are used in other areas of an XBRL instance.  For example, Net Income (Loss) from the income statement; dividends paid which are disclosed on the cash flow statement, those sorts of things.  And there are a lot of them.  All these pieces can fit nicely together if a taxonomy is modeled correctly.  The strange axis "Statement, Equity Components [Axis]" used on this statement makes that impossible.  You will see this when you try and model your XBRL instance.
6. Not everything has a class of stock, so why the [Axis].  People don't seem to grasp the fact that the [Axis] of a [Table] apply to all [Line Items] in a [Table].  The class of stock [Axis] (which you can see here or here), modeled in this statement, means that EVERY line item has a class of stock.  Semantically, this is simply not the case from an accounting perspective.

There are some other issues that I have with the statement of changes in equity such as that it cannot handle restatements caused by prior period adjustments due to changes in accounting policies or corrections of an error.  But I will save this for another day.  I want to focus on the fundamental modeling of the statement, not additional things which need to be added to the model.

Part of the reason that the statement is modeled the way it is in my view is because there is a miscommunication between the technical people and the domain people when it comes to this statement.  Many accountants give the misperception that there is an infinite number of things that can go into the statement of changes in equity and this is simply not the case.  Further, it is not the case that the [Line Items] can go under various equity components in an arbitrary manner.  Where things go is not arbitrary at all and filers have little control of where to put things, US GAAP tells them where things go.  And so should the model of the statement of changes in equity.

Another part of the reason certain modeling decisions are made, and incorrectly in my view, is that accountants are obsessed by how things are presented and they don't fully understand the connection between presentation and the modeling of the taxonomy.  Key points missed are that the best thing for presentation is to do things consistently and logically, focusing on semantics, not XBRL syntax.  But as this understanding becomes better as a result of seeing working SEC XBRL filings and filings that don't work so well, practices will drift to the proper effective result.  The sooner and the more accountants understand how XBRL works, the faster we will get there.

Some clues as to how things do work in XBRL can be seen in some things that I had laying around from several years ago (about 2005 time frame) which were used to test the IFRS GP taxonomy.  I could not decide if providing these would be more helpful to people or confusing.  If you focus on the right things you can get the true points.  At the risk of confusing people, I will make these things available.  The point here is to see another model of a statement of changes in equity, how it works, and contrast that to how the US GAAP Taxonomy statement of changes in equity works.  This has nothing to do with comparing IFRS and US GAAP.  This is about how to model information and the results which you derive from modeling things in specific ways.  So, I make this available in that light.  Please don't read the wrong things into what is being shown.  Further, realize that the 2005 IFRS GP was done in 2005.  I learned a lot from that taxonomy.  It is not an example of how a taxonomy should be created today in my view.  That said, there are certain aspects that are created correctly.  That is what I want to focus on.

So first off, here is the end result of my testing:  This PDF.  The PDF may seem a little odd, but the point was to PROVE that the IFRS taxonomy was constructed correctly. What the PDF shows is what is called a [Roll Forward] (IFRS calls it a movement analysis) for EVERY equity line item.  EVERY type of change is shown.

This is the XBRL instancefrom which the PDF is created.  Again, this is test data.  But, the same idea applies whether you are creating a test financial expressed in XBRL or a real one:  do ALL the computations add up?  How do you know that they add up?

Well, we used the XBRL calculations and XBRL Formulas to test the computations.  There are three types of computations:

• The columns add up to what is shown in the right most column which is "Equity, Total".  XBRL calculations are used to express those computations.
• The total changes adds up, that is the second row from the bottom, "Total Changes for Period" in the PDF.  Each column needs to add up.  (Even though this number may not be shown on the actual statement of changes in equity).
• The roll forward (or movement needs to add up.  For each column, the first row which is "Balance at December 31, 2003" + the second to the last column "Total Changes for Period" = the last row which is "Balance at December 31, 2004".  XBRL calculations cannot perform this test.

Here are the two validation reports which test EVERY ONE of these computations:  XBRL Calculations and the XBRL Formulasvalidation results.  The calculations validation comes from the XBRL calculations expressed with the IFRS GP taxonomy, see this calculation linkbase.  The XBRL Formulas come from a formula linkbase I created.  Originally back in 2005 when I was testing this I used a proprietary version of XBRL Formulas which UBmatrix created.  I updated those formulas to the XBRL Formula 2008 specification, which you can see here.  These calculations and formula validation results can be a little hard to read because they are not organized as an accountant would want to see them.  But, all the information is there.  Again, the point is that EVERY computation is validated.  I KNOW that everything adds up.

Another important point on the PDF is that if you look at the numbers, they have the correct "polarity" (whether they are shown as positive or negative).  What I mean is this.  Look at the fifth column from the right which is "Treasury Shares".  Notice how the number in the first column is -1,100.  Now, some accountants would say that should be shown as positive, not a negative.  No worries.  Simply change the style sheet which renders this information.  You can see the style sheet here.  If you know how to read the XSLT you can see that it is very easy to flip the number from a positive to a negative by changing this XSLT:

<xsl:value-of select="format-number(/xbrli:xbrl/ifrs-gp:TreasuryShares[@contextRef='I-2003'] * -1,'#,##0','base')" />

All you would do is change the -1 to a 1 and the value from the XBRL instance would be shown as positive, rather than negative.  People obsessed with wanting to show this as either positive or negative are missing the point that people should be able to show this HOWEVER THEY WANT TO.  XBRL provides what is needed in order to achieve this flexibility.

Conclusions

Here are my conclusions.  Take a look at the evidence above and consider all the other things which my might feel appropriate to consiser and reach your on conclusion.  But my own personal conclusion is this:

1. The statements of changes in equity are [Roll Forward]s and they should be modeled as such.  This would make understanding how to create a statement of equity in XBRL a whole lot easier.
2. Accountants are going to want to validate their computations to be sure the fact values expressed in the XBRL instance properly foot and cross-cast.  All of them, even the reconciliation of the beginning and ending balances.
3. The taxonomy should express the proper financial reporting and accounting semantics.  Not everything in a statement of equity has a "class of stock", so that [Axis] is NOT appropriate in the statement of equity.  It would be very approprate for certain pieces of the statement of equity, but not for the entire statement of equity.  This means that rather than modeling one big herky [Roll Forward], the it would be more appropriate to model each [Roll Forward] separately.
4. The side benefit of number 3 is that you know which concepts you should use in which columns of the statement of equity.
5. The IFRS GP taxonomy of 2005 proves that this can work.  You can see for yourself in the links above.  You can also see how this works and can see that it is, in fact, nothing more than a [Roll Forward].
6. Modeling the taxonomy and rendering the information in the XBRL instance are two different things. A taxonomy with a consistent information model, the base and any extension, is easy to render.

As more and more SEC XBRL filings get made with the statement of changes in equity more and more filers will have to grapple with this statement.

If someone sees a better way to model the statement of changes in equity I would love to know about it.  But you need to provide a well thought out prototype so you can think through all these pieces, rather than providing "vapor XBRL instances and taxonomies" which may not work like you think they would work.  Run what I am showing through the ringer.  Heck, if you have something better let's us that approach.  All I personally care about is that this works for financial reporting.

Perhaps it is not clear exactly what financial reporting will look like in the future, but there are some things that provide some clues and glimpses that I have come across.

IFRS

First, IFRS (International Financial Reporting Standards) will play a major role.  I personally did not even know IFRS existed prior to working with XBRL.  Frankly, I really had no need to know about it, I did financial reporting for smaller organizations which only operated in the United States.  I learned about IFRS when working on XBRL.  IFRS makes a lot of sense.  I look at IFRS as something somewhat similar to the metric system.  There really is no good reason for the entire world not to use the metric system.  There are a lot of bad reasons.  There is perhaps a lack of will to push and make a change to the metric system.  I remember when the US "converted to the metric system".  Did not quite happen all at once. But you can see that gradually changes are occurring.  You can see products being labeled using the old standard measuring system plus metric measurements.  Look down at your odometer.  I bet it shows both miles and kilometers.  The US will eventually move to the metric system.  May take 25 or 100 years, but it will get there.

The same with IFRS.  The US will use IFRS eventually.  And I am not talking about multinational public companies.  I am talking everyone.  Even the smaller companies I worked for.  Think about it.  Public companies will likely convert to IFRS soon, pushed by the SEC.  There is no way one set of financial reporting standards would be used for private companies and another for public companies.  That does not make a lot of sense.

One set of robust financial reporting standards used globally makes a lot of sense to me.  People talk about cultural differences as a reason this will not happen.  Cultural differences did not seem to have an impact on the universal product code, MP3, HTTP, HDTV, Blueray, or other standards.

Anyway, personally believe that IFRS is a great idea and that it will be used globally by anyone who wants to play in the global markes sooner than one may think.  The AICPA has already begun making financial and accounting reources such as IFRS Accounting Trends and Techniques available.

Less Obsession with Presentation

It has been my observation that most accountants are obsessed with how information looks on a printed page.  I think this will change.  The FASB and IASB are already looking into this.  The FASB published this discussion paper: Preliminary Views on Financial Statement Presentation. Take a look at pages 123 through 126. 

Here is a link to one statement from that discussion paper: Reconciliation of Statement of Financial Position. In my view, this is precisely how what information which should be disclosed should be articulated.  Many years ago I was taught by an audit manager how to prepare audit schedules used to create or check a cash flow statement using a very similar approach to this.  That was 30 years ago.  There will be other organizations of this information, but that reconciliation organizes the fundamental information which should be into a very clear form which makes the disclosures crystal clear.  I speculate analysts and investors will love this.

On page 125 and 126 of the discussion paper is another incredibly useful schedule: Statement of Comprehensive Income Matrix.  Take a look at that.  If you look at those and all you see is an ugly presentation and something that looks complex you are missing the point.  The point is the clarity that the format requires.  These reconciliations force clarity.  THAT is the point.

XBRL

You can already see the XBRL flowing into the SEC.  You can go to the SEC web site from that "dashboard" and have a look at the financial information in the HTML/SGML formats or in the rendered XBRL format.  You can also go and look at the XBRL format if you are so bold.

While the XBRL part helps provides a peek into what the format of the future financial filings might look like, or at least one version of them which is readable by a computer, there is really a lot of effort going into making the XBRL look exactly like the pretty dead tree (i.e. the paper) format which has been used for hundreds of years.

People will eventually realize that these historical practices, not all of them but many of them, are more of a liability than an asset.  The SEC coined the term interactive data.  Paper is not interactive.  The presentation formats of the past hinder this interactivity, not help it.

I have had a couple of posts on my blog which show prototypes of what this interactive financial statement might look like.  See this blog post where I talk about and even show a prototype of an interactive data viewer.  Here is that prototype.  Most people probably won't get this yet, but some will.

Financial Information is Not Enough

I think the people who are pushing things like the triple bottom line and enhanced business reporting are moving in the right direction.  The Global Reporting Initiative pushes these sorts of things.  Another term used is sustainability reporting.  There are many other terms like corporate social responsibility reporting and environmental, social and governance practices reporting.  The list is long.

The bottom line here is more relevant information.  Companies who focus on quarterly earnings are misguided in my view.  However, they tend to respond to investors who analyze based on quarterly earnings.  This is a cycle which needs to be broken.

Pulling The Pieces Together

Imagine financial reporting where:

• The financial reporting meta data used globally is IFRS and other global standard meta data.
• The reporting format is XBRL.  In fact, maybe it is not even XBRL.  I frankly have no bias here other than it needs to be structured and computer readable like XBRL, not unstructured or structured for presentation like PDF, HTML, the current SGML, etc.  It has to be readable by a computer, that is all.
• Computers do all sorts of helpful things for the preparers of such statements such as making sure the numbers all add up and that the required disclosures are there much like a manual disclosure checklist is used today.  The quality goes up because computers are doing the checking and the costs go down because it takes less effort.  Computers cannot check everything clearly, only what they can check.  Accountants will still have lots to do, just in other areas.
• The report is interactive.  It is a "flow" of hypercubes.  This flow can be organized into a printed report, which can look like these reports look today.  But they can also be organized in other ways because of the structured format of the information.
• More relevant information will be reported.
• Reporting will be more often.  Quarterly made sense when reporting was manual with no electronic calculators, no electronic spreadsheets, no Web.  We are still doing quarterly reporting why? How about real time reporting and real time auditing?
• Financial reporting standards will are written to enable this new world of electronic reporting not get in the way of it.  Paper has its limits.  Why constrain this new era with these old limitations?  This simply makes no sense.  Notions such as "presented on the face of the financial statements" make sense with paper, but make less sense using electronic medium.

Could financial reporting have some of these characteristics?  I think so.  Who knows.  Maybe someone has an even better vision of what might be possible.  What you can be sure of is that things will change.  You can already see many of these changes today.

I have received a number of questions about the [Table] in the US GAAP Taxonomy.  What I want to do with this blog post is point out some big picture things which help you get a better understanding of what exactly a [Table] is, how to use them, and answer a the questions which I have received.

As can be seen by this analysis the [Table] is not well understood by SEC XBRL filers.  The inconsistency of the SEC XBRL filings are a good indication of this lack of understanding.

But understanding and using the [Table] does not need to be complicated or hard to understand.  You can make this vastly easier.  When business users realize this, they will start to point software developers down the right path.  I have not seen one software application which has used any creativity to make creating [Table]s intuitive for business users.

Further, the ideas which can make [Table]s easier to use and understand can also be applied to [Roll Forward] and other information modeling patterns within the US GAAP Taxonomy. I published a document called US GAAP Taxonomy - Tips, Tricks, and Traps in 2008. These sections of that document are very helpful in understanding [Table]s:

• Section 2.2: Organization of the Taxonomy
• Section 2.3: Understanding the Modeling Patterns Used Within the UGT
• Section 2.4: Understanding the Tables and Dimensions
• Section 2.5: Understanding Networks and Relations
• Section 2.6: Modeling Options, Syntax and Consistency

The information is slightly dated, but the general concepts are still very much applicable.  Eventually I will do a better job of organizing and explaining this information, but there are only so many hours in the day. 

Further, if you really want a good understanding of the US GAAP Taxonomy, read through the information in Section 3: General Information (applicable to all networks) and Sections 4 through 60.  These will be particularly helpful when you get into detailed tagging of the disclosures.

The Big Picture

Here is the big picture.  The [Table] is really a hypercube.  The US GAAP Taxonomy uses the term [Table] because the creators thought the term is easier for business users to relate to.  However, what that term tends to do is cause confusion between the presentation of information and the modeling of information, which is unfortunate.  Another term used to describe hypercube is simply cube or data cube.  You may be familiar with this term from business intelligence (BI) software or corporate performance management (CPM) software.

To be precisely correct, the term you really want to understand is hypercube and here is why this is important to understand.  Bear with me, you will realize that if you don't understand this you will never fully and properly understand the US GAAP Taxonomy.

• Scalar: A scalar is data which has no dimensions.  For example, the value for pi (which is 3.14) has no dimensions.
• Table or matrix: A table (think a spreadsheet or a relational database table) or matrix has two dimensions.  A table is basically a two dimensional hypercube.  Think rows and columns, you basically have an "X" axis and a "Y" axis.
• Cube: A cube has three dimensions.  Think a third dimension, you have an "X" axis, a "Y" axis and a "Z" axis.  Remember math class when they talked about that Z axis, turning a two dimensional graph into a three dimensional graph?
• Hypercube: A hypercube has any number of dimensions, or "n" dimensions.  Hypercubes are harder to express visually.  To do this you have to lock a dimension like you do in an Excel pivot table or repeat headings like is done in printed reports.  The term for this is slicer or looking at a "slice" of information.

If you are still reading, good job!  This blog post is for you.  A lot of people probably have already given up trying to understand this.  But you want to keep going because this information is critical for you, it will exist in your future.

A hypercube is a notion of the multidimensional model.  The multidimensional model is a flexible way of organizing information.  The multidimensional model is gaining more and more popularity because of its utility in making information flexible.  BI and CPM software use the multidimensional model because of this flexibility.  You may be more familiar with the term "relational model".  The relational model is used by relational databases.  The relational model is great for transaction processing but it tends to be too restrictive for analysis.  That is why the multidimensional model is used for analysis.

What does all this have to do with the US GAAP Taxonomy and the [Table]?  A [Table] is really an XBRL Dimensions hypercube.  It is expressed in the presentation relations in a certain way.  That [Table] is also expressed in the definition relations in a specific way.  The way hypercubes are expressed within the definition relations is dictated by the XBRL Dimensions specification and it MUST be the same for EVERY XBRL taxonomy.

The way a [Table] is expressed in the presentation relations in the US GAAP Taxonomy is dictated by the US GAAP Taxonomy architecture.  It is consistent.  That consistency allows for a computer application to auto-generate the definition relations based on the presentation relations.  That is how the definition relations were created by the US GAAP Taxonomy, they were auto-generated.

How do you create your definition relations?  Probably by hand.  Why is that?  Because your software vendor does not realize and leverage this fact.  But they could.

Here is another thing relating to [Table]s.  Per the US GAAP Taxonomy Architecture (see section 4.5, page 38 of this PDF), a [Table]:

• MUST have at least on [Axis] but can have any number of axes
• MUST have exactly one set of [Line Items]

So, why does your software allow you to put something other than an [Axis] or a [Line Items] concept as a child of a [Table] in your software application???

There are many other rules relating to [Table]s, [Axis]s, [Domain]s, [Member]s, [Line Items]s, and so forth.  There are other information modeling patterns such as a [Roll Forward] which have other rules.  Software can, and likely eventually will, leverage these relations.  Doing so will make it easier for business users to understand and use [Table]s and other such relations.

Issues with [Table]s

The first problem with [Table]s is that if you DON'T build your [Table]s consistently (i.e. you do this) you CAN'T use this leverage.

But there are other issues which you may, or may not, be thinking about.  But the issues do exist:

• [Table] express business semantics: A [Table] expresses business semantics, or is supposed to.  For example, this [Table] says the following:  A balance sheet has two [Axis], a "Scenario" and a "Class of Stock".  Those two [Axis] apply to every concept within [Line Items] of that [Table].  Opps! The concept "Cash and Cash Equivalents" has a class of stock [Axis].  Yes, that is what the [Table] says.  More on this in a moment.
• [Table]s are connected to other [Table]s: For example, summary information is connected to detailed information such as this line item from the balance sheet which also exists within the disclosures.  This is a business semantics, not a technical idea.  The disclosures provides details of the summary item which appears on the balance sheet.  Yet, in the example shown, the concept inventory is shown in a [Table] on the balance sheet, but it is not in a [Table] in the disclosures. This brings us to another issue, which we will cover next. But, in many cases different concepts are used to express exactly the same business concept used within the summary information and as the total of the detailed information and no real connection understandable by a computer exists.
• Some things are [Table]s, other things are not:  Basically a multidimensional model is mixed with a non-dimensional model, not a good idea.  In the case of inventory above the same concept is used in both the summary balance sheet and in the detailed disclosures and the connection is clear.  One reason this is bad is that XBRL Formula works either with a dimensional model or with a non-dimensional model.  Mixing the two causes serious issues.  To work around this to a degree XBRL Dimensions "default dimensions" was used to hack a connection and to try and get this to work correctly.  Another way of looking at this is what if everything were a [Table]?  One could be explicit about [Axis] (rather than implicit) and there would be now issues relating to mixing a dimensional model and a non-dimensional model.
• Sometimes dimensions are an [Axis] other times dimensions are items: Here on the balance sheet, Property, Plant and Equipment is an item, as is Land and the other classes of PP&E.  But here in the disclosures, Land and other classes of PPE are members of an [Axis].  Why the difference?

This is only a taste of some of the issues relating to [Table]s.  These will become more clear as detailed tagging of the disclosures begins to take place.

So now we circle back to the beginning of our discussion of hypercubes (i.e. [Table]s).  An understanding of the multidimensional model, an understanding of how XBRL Dimensions works, an understanding if data modeling, and an understanding of the financial reporting concepts being modeled are necessary to model the US GAAP Taxonomy correctly.  Likewise, an understanding is also necessary to build SEC XBRL filer extension taxonomies correctly.

In some areas the US GAAP Taxonomy is well modeled and a good example of how [Table]s should be constructed.  In other areas, [Table]s are not modeled well.  There are many reasons for this that I will not get into.  Three big contributors to the issues of the US GAAP Taxonomy are:

• An inapproprate obsession on presentation of information rather than modeling the data correctly.  What does not seem to be relized is that if the data model is correct the presentation is easy to model.  But if the data model is incorrect, one may be able to present the information correctly but you cannot model the data correctly.
• Mixing a dimensional model and non-dimensional information.  This leads to having to be implicit about certain information such as belonging to the consolidate entity.  It also leads to misuse of default dimensions in the US GAAP Taxonomy and to issues making XBRL Formula work correctly (because XBRL Formula supports either the dimensional or non-dimensional taxonomies, not a mixture of the two)
• Insufficient understanding of how hypercubes work and of the multidimensional model by the majority of business users modeling the US GAAP Taxonomy.

All of these issues can be addressed and corrected.  The first step to doing this is for more business users who understand the domain of financial reporting and what the semantics of the US GAAP Taxonomy SHOULD be saying to see what it is currently saying.  This will be seen within the SEC XBRL filings.  The next step is adjusting the taxonomy to say what the domain users really want it to say.

These [Table]s, hypercubes, the multidimensional model and such may be challenging to understand and it may take an investment in time.  I know that this was very challenging to me and it took a while to grasp and I am not saying that I grasp everything perfectly; I still have a lot to learn.  However, you have to admit that there are pretty good questions and observations.

The payback for business people understanding this is easier to use software.  Once business users realize that is going on here, they will be far better equiped to tell software developers what they need from software applications.

The really good news is that the US GAAP Taxonomy is not as complicated as string theory where their are somewhere between 11 and 14 dimensions one needs to wrap their heads around.