Digital Financial Reporting

It was perhaps ten years ago when in a meeting, someone asked David vun Kannon, one of the primary architects of XBRL, what the potential market for XBRL was.  David answered "Billions and billions."

It seems that there are some people at SAP who may think the same thing. In an article from ITBusinessEdge The Trigger Affect, James Fisher, SAP vice president of marketing for enterprise performance management and finance solutions says:

Once in place, XBRL will provide a foundation for a new generation of collaborative financial management applications that will have a profound effect on business.

He goes on to point out other ways which XBRL will impact financial disclosure management, enterprise performance management and the next generation of business intelligence applications. (Some people refer to this collectively as "the last mile of finance.")

So while to a certain degree XBRL may feel punitive, in reality it is the beginning of a major transformation in financial management that should occupy IT organizations for years to come.

I interpret "should occupy IT organizations for years to come" as meaning billions and billions. I look forward to the next 3 to 5 years which should reveal if these guys are right.

I have long held that 100% of calculation inconsistencies can be avoided. I am changing that position, somewhat reluctantly, given strong evidence that this is a sound theoretical position, yet it is not a sound practical position.

While it is the case that you can make such calculation inconsistencies go away, it is not the case that you can do so and make the set of financial reporting disclosures which one would desire to make from an accounting perspective.

The reason I am reluctant to take this position is because I see many XBRL instances which now sloppily hide behind the fact that calculation inconsistencies CAN exist, now have calculation errors which should NOT exist intermingled with true calculation inconsistencies and those calculationerrors go undetected. This is unfortunate, but I cry uncle and admit that it is unavoidable in many cases.

My new position is that XBRL calculations or XBRL Formulas should exist which prove that everything which should foot or cross cast, does in fact foot and cross cast.  You prove that, then you can safely ignore the calculation validation results which do report calculation inconsistencies.

Regretfully from the perspective of an XBRL instance consumer, this makes things tougher.  My answer is that a good analysis application will show you things which do add up and will somehow mask the confusing calculation inconsistencies which really mean nothing.

Just like [Line Items] have patterns or information models such as [Roll Forward], [Roll Up], and [Hierarchy], the [Member]s of an [Axis] likewise have an information model. I have put together a document which summarizes these moving pieces which you can get here.

Here are some example financial reporting use cases which show different types of dimensional aggregation schemes which will give you an I deal of what I am talking about:

• [Axis] with no aggregation: Subsequent events or property, plant, and equipment policies would be an example of where you would have an [Axis] with no aggregation. Subsequent events are rarely, if ever, added up to arrive at some total amount for subsequent events of an entity.  The same with PPE policies, they are not added up.
• [Axis] with basic aggregation: Nonmonetary transactions are a good example of a basic aggregation. There is no real grouping of nonmonetary transactions, it is simply a flat list.  That list has an amount of for each nonmonetary transaction, and the total for nonmonetary transactions is commonly reported. That total does not tie to any other location in the financial report, it stands alone.
• [Axis] with complex aggregation: Business segment reporting is a good example of potentially complex aggregation. You may have a Parent Holding Company [Domain], which has consolidation eliminations, and multiple business segments.  You may add to this a breakdown of continuing and discontinued segments. This could become even more complex with asset groups, reporting units, and disposal groups.

As the XBRL Dimensions Specification does not address dimensional aggregation, taxonomy creators are on their own to address this.  Fortunately, XBRL Formulas is available to articulate and validate against aggregation schemes.

In order to create these aggregations, a good understanding of what a domain is becomes important.

See the document for more information if you care to understand and eventually master this area.

Thank you to all the XBRL Dimensions heavy weights who contributed to my understanding of this important information.

Someone said something to me today which helped me recall something which I had thought about years ago when I had an opportunity to visit a Fortune 100 company to see how they created their financial statement.

The thing which sparked this thought again was a chiropractor who was going through the process of implementing electronic medical records.  She was telling me that her macros were not working how she wanted them to work when she did initial examinations of a patient. She said she needed to make adjustments to her macros. You may not be familiar with the SOAP (subjective, objective, assessment, plan) method of documentation employed by health care providers, and that specific process is not really relevant here.

What is relevant is this.  First, a chiropractor adjusting her macros. Who would have thought a chiropractor would ever even use macros.  Second, there is a process and that process can be converted from manual medical records to electronic medical records.  Third, that SOAP process can make use of templates.  There are thousands of diagnosis codes and procedures employed to treat medical conditions. These can be distilled down to templates.  I would contend that there is a lot of similarity between electronic medical records and financial statements. There are likewise lots of different types of financial statement disclosures which can be distilled down into templates.  (i.e. neither medical records nor financial statements are totally random)

So imagine breaking down a financial statement into its components.  Here is one instantiation of a financial statement broken down into its components.  That is created from an XBRL processor.  Then, once all the components are correct, running a macro to generate a financial statement in HTML and/or XBRL or any other format for that matter. Creating a financial is adjusting templates, running macros, and repeating this until your financial is complete.  Business rules enforce the integrity within and between components.  All that ugly XBRL stuff is hidden deep within the software, but that is what enables the macros to do their job reliably.

I can imagine pretty easily careating something like this in Excel.  Longer term, I don't see Excel as the platform for creating financial statements. I see something like GoAnimate as an example of how the application might work. The point here is to look at the process totally differently than it is being looked at today. Think model based reporting.

That is what seems to be in store for the last mile of finance, generating those financial reports. The process seems to be taking lots of little pieces and putting the pieces together. Why cut and paste when you can have a macro do the work.

The FASB made an announcement and the SEC has now put on its web sitethe 2011 US GAAP Taxonomy making it allowed for use for SEC XBRL filings.

I submitted a test filing to the SEC previewer yesterday which used the 2011 US GAAP taxonomy which was accepted.

This blog postpoints to a number of resources which are helpful in using this new taxonomy.  In particular check out the reference implementation, the reorganized version of select portions of the 2011 taxonomy, and the SEC XBRL Filing Primer.