Digital Financial Reporting

The benefits of semantic, structured authoringover the unstructured approach to creating financial statements (i.e. packing information into Microsoft Word which understands nothing about financial reporting) seem quite obvious and clear to me. It seems that even if you created your financial statement using this semantic, structured approach leveraging XBRL and never gave XBRL output to anyone, it would still be worth considering a semantic, structured authoring approach.

This may seem like a rather odd statement, but hear me out.

Structured authoring of documents has been around for quite a long time.  I visited the company called Arbortext back in 1998 when SGMLwas the structured text of choice. SGML offered many benefits, but it was hard to use.  A few years later I visited a company called SoftQuad Software in Vancouver, BC (just up the street from me) who had a product called XMetaL.

(A quick history; XMetal was purchased by Corel, then Corel sold it to Blast Radius, and then Blast Radius sold it to JustSystems)

XMetaL was am XML editing tool with an interface which was much like a word processor.  It was a business user tool, rather than an XML tool for developers like most other XML editors. The useful thing which XMetaL did was control what you could enter using a schema.  The bad thing was that the schema was more syntax related than semantics related. XMetaL got into XBRL but I never did see XMetaL allow a business user "interact" with a financial statement the way I thought that the interaction could be like.

There are others taking a structured authoring approach to creating financial statements. SAP, Oracle, and IBM to name three. All of these companies are working to change the "last mile of finance" as are others. Many of these companies started down this path long before XBRL even existed.

There are lots of different terms for structured authoring: model based reporting, digital financial reporting, 21st Century financial reporting.

But let me take a step back and say that there is an even better approach that structured authoring. This approach is called semantic, structured authoring and is defined as:

Semantic, Structured Authoring

"to compose information content semantically structured according to some ontology"

THAT is what I'm talking about.

The paper Semantic Authoring and Learning Thereofby Kôiti Hasida talks about semantic structured authoring in more detail. It points out how this approach can be more productive and improve quality using things such as (most of which I don't really understand):

• discourse connectives
• reusable patterns of discourse structures
• lexicographical and lexical knowledge
• frequent combinations of argument types of discourse relations
• ontologies containing concepts appearing in graphs
• credibility and importance of parts of graphs
• who may be interested in parts of graphs

It seems like semantic structured authoring is a marriage between ideas of structured authoring and ideas of the semantic web. Add to this business intelligence, then you see financial reporting done in a totally new way.

The way I see it is that taking a model-based approach to constructing financial statements will be as different as using a paper spreadsheet as contrast to building an electronic spreadsheet. The best visualization I can provide is a video of the Quantrix Modeler (the first video on this page, 6 minutes that will change your view of the world).

Imagine a digital financial report viewer which works like how you interface with songs on iTunes. I prototyped this in iTunes and you can watch the video here.  (Here are a couple of other options if that does not work for you: Flash video, Screencast.com. Also, you can watch the imbedded version below, but part of it is cut off.)

Imagine:

• The "flipper" thing what allows you to flip between songs as flipping between the different sections of a financial report.
• Being able to change the view from an actual image, an image with a list of the pieces, or just the list which you can sort.
• Being able to filter for different pieces of the report
• Being able to organize your different reports like you organize a play list in iTunes.
• And clearly all this stuff would work not only on our PC, but also on your iPad.
• You double click on an image and up pops something which looks and works like a pivot table which allows you to reconfigure the information.
• You can compare financial reports as easy as dropping any number of reports on top of one another
• Your interface to the SEC EDGAR system was like your interface to the iTunes store

All this is very possible.  The more consistent, explicit, and well modeled the US GAAP Taxonomy and SEC XBRL financial filings, the easier this is.  Heck, if you can do this for the Beattles music, why can't it be done for Boeing financials?

I have a new mantra: "The only thing better than meta data is more meta data."

As I mentioned in another post, the book Everything is Miscellaneous explains "the third order of order":

• First order of order. Putting books on shelves is an example the first order of order.
• Second order of order. Creating a list of books on the shelves you have is an example of second order of order. This can be done on paper or it can be done in a database.
• Third order of order. Adding even more information to information is an example of third order of order. Using the book example, classifying books by genre, best sellers, featured books, bargain books, books which one of your friends has read; basically there are countless ways to organize something.

Third order removes the limitations which people seem to assume exist when it comes to organizing information. Weinberger (the author of Everything is Miscellaneous) says this about the third order of order:

In fact, the third-order practices that make a company's existing assets more profitable, increase customer loyalty, and seriously reduce costs are the Trojan horse of the information age. As we all get used to them, third-order practices undermine some of our most deeply ingrained ways of thinking about the world and our knowledge of it.

Basically, I believe that meta data has strategic implications.

Financial reporting has boatloads and boatloads of meta data, far more meta data than is included in the US GAAP Taxonomy.  I have prototyped some of this key meta data here on a wiki I have put together for digital financial reporting.  I have been accumulating this meta data over the years and have built many, many other prototypes to try and figure out how things like RDF/OWL fit into XBRL and into financial reporting.

It seems to me that the FASB and IASB could prove that their conceptual frameworkby articulating it using RDF/OWL, UML or some other modeling language.  Certainly some of that could and should be done using XBRL.  Also, because financial reporting is becoming so complex, using a modeling language can help improve communications.

Shoot! That is all the time I have for now, gotta go create some more meta data.

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!

Anyone familiar with XBRL realizes how impotent the XBRL calculation linkbase is. Business rules articulated using XBRL calculation only allows for "roll up" type relations to be expressed.  But the US GAAP Taxonomy has many other types of business rules besides roll ups:

• Roll forwards: computations across the Period [Axis], beginning balance + changes = ending balance
• Dimensional aggregations: computations across some dimension such as the business segments or geographic areas.
• Adjustments: computations across the Report Date [Axis]; origionally stated balance + adjustments = restated balance
• Variance: computations across the Reporting Scenario [Axis]; actual - budgeted = variance
• Complex computations: computations such as earnings per share

And there are other business rules which a more powerful business rules engine could automatically validate.  In fact, much of a disclosure checklist can be validated using a powerful business rules engine.

What if there was a global standard approach to expressing business rules.  Should that standard be used by the US GAAP Taxonomy?

Well, the fact is that there is a global standard: XBRL Formula.

The 2008, 2009, and 2011 versions of the US GAAP Taxonomy did not include XBRL Formula.  Part of the rational for not using XBRL Formula was that XBRL Formula was still new.

A discussion on the XBRL-DEV mailing list yielded this list of business rules processors available in the market:

Commercial XBRL processors which include XBRL Formula capabilities:

• Edgar Online/UBmatrix: http://ubmatrix.edgar-online.com/products/processing_engine.htm#  (http://ubmatrix.edgar-online.com/products/formulas2008/index.htm)
• Fujitsu: http://www.fujitsu.com/global/services/software/interstage/solutions/xbrl/ 
• Invoke: http://www.invoke.fr/en/gabarit_03.asp?Page=produits/xbrlsuite.asp 
• Reporting Standards: http://www.reportingstandard.com/en/XBRL_API.html and http://www.hernandez-ros.com/webfp/  
• Semansys: http://www.semansys.com/sdnn/Aboutus/tabid/168/Default.aspx

Open source XBRL processors which include XBRL Formula capabilities:

• Arelle: http://arelle.org/ 

Proprietary business rule formats:

• CoreFiling: http://www.corefiling.com/products/sphinx/ 
• PFXBRL:  http://pfxbrl.blogspot.com/ 

Others (not clear on what exactly is provided):

• GPM Systemy: http://gpm-systemy.com/en/
• XBRL Test Platform: http://cosx.co.cc
• ShangHai Newlido, China: XBRL Validation Platform (No link available)

It is impossible to create a correct SEC XBRL financial filing without automated validation of business rules such as that provided by XBRL Formula.  You can try to validate all these details manually, but that does not work very well at all.

The FDIC implemented business rules in 2005using a proprietary approach because XBRL Formula did not exist.  They understood that validation of business rules.  The quality of data submitted to the SEC would no doubt improve if business rules were used by SEC filers.  Not having XBRL Formula in the US GAAP Taxonomy does not prevent filers from creating their own set of business rules.  But, by having these rules within the US GAAP Taxonomy and accepted by the SEC, not only would the accuracy/quality of the data improve but the consistency across SEC filers would improve as well.

I think it is time for XBRL Formulas to be used by the US GAAP Taxonomy.  What do you think?