Digital Financial Reporting

I mentioned Google Fusion Tables in a previous post.  Google has been improving these fusion tables.  Here is a Google Fusion Table imbedded into this blog post: 

Try scrolling through the information in the table.

Imagine financial and other business reports being created in this manner.  You piece together components as needed to report what you want to report.  So the disclosures are more like "sets" or databases of information.  How you view that information depends on what information you want to user and how you want to use it.  Not only can humans read the information, but software applications can likewise read to or subscribe to information.

In my last blog post I updated my definition for a fact.  The definitions of three other terms were improved per feedback received.  To provide a bit of context, these terms relate to the notion of creating a verifiably true and fair representation of financial information within the Guide to Verification of an SEC XBRL Financial Report, but apply to other documentation as well.

As stated within the Guide to Verification of an SEC XBRL Financial Report, a financial report can be said to be valid if it possesses certain traits which can be defined in general terms and for clarity are listed below to bring them into the reader's mind:

• Completeness: Having all necessary or normal parts, components, elements, or steps; entire.
• Correctness: Free from error; in accordance with fact or truth; right, proper, accurate, just, true, exact, precise.
• Consistency: Compatible or in agreement with itself or with some group; coherent, uniform, steady. Holding true in a group, compatible, not contradictory.
• Accuracy: Correctness in all details; conformity or correspondence to fact or given quality, condition; precise, exact; deviating only slightly or within acceptable limits from a standard.

While these four notions which relate to the "trueness" and "fairness" must exist for every fact reported by a financial report, they also need to exist when considering the financial report in its entirety.

Two other notions help bring the notion of trueness and fairness of information at the fact and at the report level into focus.  These are the improved definitions of these two terms:

• Fidelity: Fidelity relates to the loyal adherence to fact or detail; exactness. The representation of the facts and circumstances represented within a financial report properly reflect, without distortion, reality.  High fidelity is when the reproduction (a financial report) with little distortion, provides a result very similar to the original (reality of company and environment in which company operates).
• Integrity: Integrity is holistic fidelity. Integrity relates to the fidelity of the report in its entirety, of all parts of a financial report, from all points of view.  Integrity is holistic accuracy, accurate as a whole. Integrity is the quality or condition of being whole or undivided; completeness, entireness, unbroken state, uncorrupt. Integrity means that not only is each component of a financial report is correct but all the pieces of the financial report fit together correctly, all things considered.

In much of my documentation I also used integrity to mean something else.  I have untangled this terminology and introduced another term, intersection.

To understand integrity correctly, it is important to understand the notion of an "intersection".  An intersection is defined as:

• Intersection: An intersection is a physical connection between two pieces of a financial report.  Generally an intersection is some report element such as a [Table], an [Axis], a [Member] or a Concept.  Intersections can be further explained by business rules.

An example will help you understand the notion of an intersection.  Consider the concept "inventories".  Inventories might appear as a line item on the balance sheet.  Total inventories might be detailed or a breakdown provided within the disclosures.  While the label "Inventories" might appear on the balance sheet and perhaps "Total inventories" in the disclosures, that is actually on reported fact presented in two places within a financial report.  That fact has the characteristic of both relating to the same concept.  All other characteristics are likewise the same.  In essence the fact intersects the balance sheet with the detailed breakdown of inventories, it defines an intersection.

Looking at this from another perspective helps see the importance of intersections.  What if this information was modled incorrectly and rather being expressed as one single fact shared by to components of a financial report; and rather two different concepts were used and two different facts provided within a financial report.  In this case, the intersection between the two components would be masked.  As a result, errors could be introduced within the financial report and the error would likewise be masked.  For example, if two facts are modeled and the balance sheet fact was one number and the detailed breakdown of total inventories was some different number then the balance sheet and the detailed breakdown would not agree.

Part of integrity is that there are no such modeling mistakes and therefore no mathematical errors which could possibly be masked by a modeling mistake.

Some software leverages these sorts of intersections, other software does not.  I pointed out some time ago that intersections were leveraged within the Firefox add-on for XBRL.  At that time I used the term hypercube jumping to describe this.  The XBRL Cloud Viewer leverages these sorts of intersections. CoreFilings Magnify does.  Other software likely does also.

The mistake I made with the term integrity was that I was using it to mean both the definition of integrity above and the notion of an intersection.  The improvement is that I recognize that these are two different notions so they need to different terms, even though the two notions are related to a degree.

I stumbled upon something which I find rather important.  It may sound subtle, but I believe the distinction is important.

Someone provided feedback related to the definition of a fact.  They felt that I did not have the definition quite right.  So, I looked into this.  I knew that the XBRL Abstract Model 2.0 had to define a fact, so I thought I would have a look at their definition to see if there was any thing there which I could leverage (...er...ah...steal).

The XBRL Abstract Model 2.0 uses the term "DataPoint" rather than "fact".  It also uses other different terms such as "aspect".  See here for a reconciliation of this terminology.  This is their definition of DataPoint:

The DataPoint metaclass defines a reportable item of business information contextualized by a set of aspects that identify or describe the item (this is an XBRL primary item fact), and a corresponding data point value (the reported item of business information).

The key word here is contextualized.  This dictionary defines contextualized as:

to place (a word, event, etc.) into a particular or appropriate context for the purpose of interpretation or analysis

"For the purpose of interpretation of analysis."  THAT is exactly how one should look at defining information, so that the information can be property interpreted!

And so, this is my revised definition for a fact as used in my digital financial reporting model:

A fact defines a single, observable, reportable piece of information contained within a financial report, or fact value, contextualized for clear interpretation or analysis by one or more characteristics.  Numeric fact values must also provide the additional traits "units" and "rounding" to enable appropriate interpretation of the numeric fact value.  Facts may have zero or many parenthetical explanations which provide additional descriptive information related to the fact.

(If you don't understand the term characteristics, please see here for specific examples and the Financial Report Semantics and Dynamics Theory for more information.)

Why is this important?  That is exactly what creators of financial reports should be thinking when they create those reports: how the information within the report will be interpreted.  This is why any important characteristics must be articulated along with values and also why it is better to explicitly state what you are saying rather than leave it up to users of the information to imply meaning because they may imply the wrong meaning.

Another term for this is disambiguate which is defined here as:

to establish a single semantic or grammatical interpretation for

Ambiguity, the enemy of automated reuse, is

"doubtfulness or uncertainty as regards interpretation" or "vagueness or uncertainty of meaning".

Unambiguous is:

admitting of no doubt or misunderstanding; having only one meaning or interpretation and leading to only one conclusion

Please don't make the mistake of confusing the need for and the freedom to exercise professional judgment in the creation of a financial report.  That is not the point or the issue here.  Accountants alone determine what should be communicated within a financial report.  What information to report is not the issue here.

What is at issue here is if accountants do say something, what they said should be interpreted the same by all computer software applications or their users.  What I am talking about here is the objective facts, the information level.  The information should have the same meaning to all users of the information.

How reported facts are used, whether reported facts are used at all, the implications or ramifications of that meaning the facts hold, and such is up to the user of those facts, the users of the reported information.  That is a different level of interpretation, more on the level of knowledge.

The point here is that all users of any financial report information set should fundamentally interpret the fundamental facts, the core building blocks, base meaning of the reported information, in the same way:  Assets as of December 31, 2012, for the consolidated entity is $100,000.  Facts such as this are objective, not open to interpretation, the fact itself has one meaning.  Is having $100,000 in such assets good or bad?  That is a different question, certainly open to interpretation.

This distinction is important to understand.

In a message posted to XBRL-Public, the IFRS Foundation announced the release of business rules for the IFRS taxonomy. The business rules are made available using XBRL Formula.  This is the text of their post should you not be a member of the XBRL-Public list:

The IFRS Formula Linkbase 2012 is now available to download. The current version of the formula linkbase is an updated version of the formula prototype which was released in October 2011. The 2012 formulae are designed to work with the IFRS Taxonomy 2012. The majority of the improvements between the current version and the prototype are related to the content.

The formula linkbase can be used with software packages supporting the XBRL formula specification 1.0 and allows for additional validations of the reported facts. The IFRS Formula Linkbase 2012 is developed in a generic manner, which means it can be used directly on the filings created, on the basis of the IFRS Taxonomy (instance documents) or the company specific extensions to the IFRS Taxonomy (filer extension taxonomy and instance document). The guidance documentation for formula linkbase is available to download with the current release.

Technical changes between the current version and the prototype include:

· Positive and negative formula validation has been placed in separate files.
· Redundant members in the filter for the Dimension aggregation formulae are now removed.
· Precondition expressions in the validation have been simplified (Earnings per share formulae).

For futher information and to download tthe files, please visit
http://www.ifrs.org/tools/IFRS+Taxonomy+Formula+Linkbase+2012.htm

There was a discussion on XBRL-Public and CORBA was brought up.  I wanted to summarize information about CORBA so that I could get back to that information.  Here is that summary.

Sees that CORBA is maintained by OMG.

CORBA, or Common Object Request Broker Architecture, is defined by this tutorial as follows:

The Common Object Request Broker Architecture (CORBA) is a standard framework allowing software objects to communicate with one another, no matter where they are located or who has designed them. The Object Request Broker (ORB) is the "middleware" which performs the communication. Objects may reside on the same computer, or different computers connected by a network.

This is the CORBA Basics page published by OMG.

CORBA is similar to Microsoft's DCOM (Distributed Component Object Model).  It seems that ActiveX or most people are probably more familiar with OLE (Object Linking and Embedding) or OLE Automation or COM (Component Object Model).

The following web pageprovides a bunch of good information on CORBA and DCOM.