Digital Financial Reporting

A number of important and detailed email exchanges on the xbrl-dev mailing list yielded some very important understanding relating to the nuances of [Table]s, [Axis], and [Member]s.

While the discussion was somewhat technical (and if you need those technical details or want to see supporting material you can get that here) I have distilled the discussion down to its essence and in terms understandable by business users.

First off, if you do go look at the details (see above), be aware that the terminology is slightly different. You can see these differences reconciled on this examination of the multidimensional model. The short version of the reconciliation is that [Hypercube] and [Table] mean the same thing as does [Dimension] and [Axis].

Isomorphic/Polymorphic

The terms isomorphic and polymorphic seem hard to understand and when I first saw them I did not grasp the terms. In reality, they are quite easy:

• Isomorphic. Has one meaning.
• Polymorphic. Has more than one meaning.

It is not that either is bad or good; what is more important is that if something is isomorphic in the real world, it should be modeled isomorphic in your XBRL modeling and if something is polymorphic it likewise should be modeled as such.

[Table]s (hypercubes) model some grouping of information.  A [Table] groups together a set of [Axis] and a set of [Line Items]. If a [Table] groups together different sets of [Axis] and [Line Items], then generally the [Table]s should have different names. There are at least four technical reasons for this:

• There are no advantage to polymorphic [Table]s.
• If you use isomorphic [Table]s (i.e. each is unique) then the labels can uniquely describe the [Table] and the documentation can likewise uniquely describe the [Table].
• If you use isomorphic [Table]s (i.e. each is unique) then you can refer to the [Table] using only the name of the [Table].  If you don't, then you also need the network name to find the [Table] you are looking for.
• If [Table]s are unique, then you can put more than one [Table] into a network, if they are not unique, you cannot.

An example from the US GAAP Taxonomy will make this point clear. In the US GAAP Taxonomy, the [Table] "Statement [Table]" is used for the balance sheet, the cash flow statement, the income statement, and the statement of changes in equity. Alternatively, rather than us "Statement [Table]" for each, "Balance Sheet [Table]", "Cash Flow Statement [Table]", "Income Statement [Table]" and "Statement of Changes in Equity [Table]" could have been used. I would go a step further and say using the unique [Table]s is preferable due to the three bullet points above.

Also, the US GAAP Taxonomy is actually inconsistent.  If "Statement [Table]" was used to define statements, then why wasn't "Policies [Table]" defined and used for all policies and "Disclosures [Table]" defined and used for all disclosures?

For [Axis], imagine that you had these three [Axis] (which the 2009 US GAAP Taxonomy did have):

• Reserve Quantities by Geographic Area [Axis]
• Productive Wells by Geographic Area [Axis]
• Statement, Geographical [Axis]

A geographic area is a geographic area, be that [Axis] used for reserve quantities, productive wells, or in general.  The 2011 US GAAP Taxonomy only has one geographical area [Axis], the first two were dropped. Another adjustment will likely be made in the next version of the taxonomy, using the more general term "Geographical Area [Axis]" or "Geographic Area [Axis]".

The bottom line again is that if something is isomorphic, it should be modeled as isomorphic; if it is polymorphic, model it as polymorphic.

Dimension Default

Many people think that the dimension default is there to "default" something and make the users life easier.  That is not the case at all.  The term "default" is really a misnomer, an unfortunate choice in terms.  What the dimension default does is make it so that [Table]s can intersect.  The dimension default defines the intersection between two [Table]s.  Sometimes you don't need a dimension default.  Other times you absolutely need it.  But if you do or do not use it, it is physically "there" in the set of [Axis] of a [Table], whether it physically exists in the context of fact or not.

If you look at an XBRL instance (see the examples above) in an XBRL viewer application such as the Firefox XBRL Viewer add on, you will see that the dimension default is there.

For example, if you have "Inventory" on your balance sheet and you provide the inventory details of "Raw Materials", "Work in Progress" and "Finished Goods" with that same total "Inventory" within your disclosures; you will have two [Table]s: the balance sheet which provides the summary information for inventory and the disclosure of components which provides the details.  Yet the concept "Inventory" exists only once in your reported facts.  That concept is the intersection between the two [Table]s.  The set of [Axis] is different on the balance sheet and in the breakdown of components.

Implied/Explicit

Another area of confusion is implied [Axis].  SEC filing rules say that everything in an SEC XBRL financial filing relates to the legal entity "consolidated entity" unless otherwise stated.  So, if you don't put the [Axis] "Legal Entity [Axis]" somewhere, that [Axis] still exists because the SEC filing manual says that it exists.  Whereas, you could also physically add the [Axis] "Legal Entity [Axis]".

Now, if you view your SEC XBRL financial filing using applications which understand SEC filings, that application may or may not physically show that [Axis].  If you view it with "off the shelf" XBRL software which is not specialize in SEC XBRL filings, it is certainly not going to understand that you mean the "Legal Entity [Axis]" to be there, it is implied.  This might be slightly annoying of you are looking at only one filing.  But if you are comparing filings and one implied the [Axis] and another explicitly put it there, this can become problematic.  Keeping track of what was implied and what is explicit can become a challenge.

The solution? Always try and be explicit.

[Domain] is really a [Member]

The US GAAP Taxonomy uses the term [Domain] (I have to admit I contributed to this situation, incorrectly). There are three problems here.  First, there is no physical report element "[Domain]". The definition of a "domain" is a set of members.  Second, the US GAAP Taxonomy only ever models one set of members when a domain really can be partitioned into more than one domain. A partition is defined as:

A partition is collectively exhaustive and mutually exclusive set of members within a domain. Partitions do not overlap. Give a set X, a partition is a division of X into non-overlapping and non-empty "parts" or "blocks" or "cells" that cover all of X. More formally, these "cells" are both collectively exhaustive and mutually exclusive with respect to the set being partitioned.

Third, a partition of a domain may, or may not, add up. Whether a domain partition adds up or not is unclear from the US GAAP Taxonomy.

The IFRS taxonomy already dropped the use of the [Domain], then only use [Member] within an [Axis]. The US GAAP Taxonomy actually did the same and dropped the term [Domain], but ended up putting it back because they figured it would cause more confusion that it would solve at this point.  They have not solved the multiple domain partition issue, which does need to be solved as there are a number of occasions where creating multiple domain partitions will help clarify the intentions of the US GAAP taxonomy.

Axis Aggregation Model

An [Axis] (dimensions) has an aggregation model.  An axis aggregation model is the relationship between the members of a domain within an axis.
 
There are a number of forms an aggregation model might take including:

• Partial sets or domains whose members describe non-numeric concepts can never aggregate.
• Complete flat sets of describe characteristic of numeric concepts which can aggregate.
• Complete hierarchical sets are nested complete flat sets.
• Complex sets are other more complicated axis aggregation models.

Axis aggregation models are expressed using business rules.

Investing in understanding how to model SEC XBRL financial filings can be an investment, but the investment will pay dividends. Digital financial reporting is likely here to stay!