Digital Financial Reporting

Someone made me aware of something which I thought I would share because I think that it helps people trying to understand XBRL.

The National Information Exchange Model(NIEM) is an information exchange standard.  The motivation for NIEM is articulated as the following in this document which provides an introduction to NIEM: 

The National Information Exchange Model (NIEM) is designed to develop, disseminate, and support enterprise]wide information sharing standards and processes across the whole of the justice, public safety, emergency and disaster management, intelligence, and homeland security enterprise at all levels and across all branches of government.

That introduction document makes the case for common information exchange standards (canonical standards) as opposed to point-to-point information exchange standards.  They have a nice little graphic on page 19 of the document (figure 5) which compares point-to-point information exchanges with canonical standard exchanges which looks virtually identical to a graphic I put into my book Financial Reporting Using XBRL (section 4.2, page 44).  Basically, NIEM makes the same case as XBRL: standards are good.

Something else that NIEM realizes and says is this (page 5, the bold emphasis is mine):

Some sources of data components include data models, databases, data dictionaries, schemas, and exchanges. In NIEM, these objects and constructs are represented using XML Schema for the purpose of consistent definition and transmission of information exchange packages (IEPs). The model, however, is independent of any particular technology and in the future could be depicted in any number of representations (e.g., Resource Definition Framework (RDF) or Web Ontology Language (OWL)), which would produce semantically consistent interoperable information sharing. It is anticipated that future versions may migrate to new and evolving forms.

The model is independent of the technology (i.e. the syntax). Another way of saying this is that semantics is more important than syntax.  If you get the semantics right, you can always convert from one syntax to another.  Because different business systems have different data formats (i.e. syntax), there will always be a need to convert into a variety of syntaxes.  But the information exchange will not be possible if you don't understand the semantics (i.e. meaning) of what you are receiving.

Reading the introduction to NIEM document which is quite well done can help you understand what XBRL enables.

Canonical formats such as NIEM, XBRL, other forms of XML, RDF/OWL, and others will change how we do things and what we can do, opening new possibilities.

If you believe XBRL is here to stay (there is plenty of evidence that will be the case), then it is time for certified public accountants and charted accountants to understand some things about XBRL. Even some attorneys will need to understand some of these details.

These are not details relating to the technology, rather they are details of financial reporting which the technology needs to be able to deal with.  This is not a list of all those details, here I am focusing on information being reported within a financial report which is expressed using XBRL. This may not seem important to you now, but keep in the back of your mind that one day the XBRL will be the source document which drives the financial information which is presented.  Today, most accountants look at XBRL as something additional you do after print your financial report.  That will not last for long, that approach is simply a step in the evolution of XBRL.

If you are expressing information in XBRL, you will want these details to be expressed correctly.  These details relate to expressing information correctly within an XBRL financial report.  The information you express are called facts.  These facts are described by other information which identify the fact and help represent the information you are disclosing.  There are various approaches to checking to see if what you expressed comes across as what you desired to express.

So, what exactly is a fact?  A fact is something you can observe.  For example, here is a fact with some of the information which identifies the fact and helps to express the fact:

Cash and cash equivalents amounting to $1,000,000 for the consolidated group for the end of the third quarter of 2009 which rounded to millions of US dollars reported in the financial statement released on February 18, 2009.

Again, that is only one fact, some of the information which helps identify that fact and other information which helps you to identify that fact.  You will have thousands of facts and there is various information which helps identify those facts and helps you represent those facts.  You have processes to help you be sure you expressed these details correctly.

Here is a fairly comprehensive list of identifying information and which helps you express that fact which you should be considering when you create your financial information in XBRL:

• Concept: Every fact has a concept to which that fact relates.  The concept tells you what the fact is, for example "Cash and Cash Equivalents". Concepts have additional information relating to them such as the definition of the concept, labels, whether it is a debit or a credit, and so forth. There is much more to concepts, but let's stop there for now.
• Report date: Every financial report has a report date, most of the time being the date of the audit opinion attached to the report.
• Fiscal period: Information within a report relates to a fiscal period which you know might not be a calendar period.  Fiscal periods might not correspond to months, for example the retail industry uses a 52/53 week fiscal period in many cases.
• Reporting entity: The reporting entity is the entity reporting the information which may not be the entity which the information is about.  See legal entity which is next.
• Legal entity: The legal entity is the entity to which the information being reported relates.  It may, more may not be, the legal entity.
• Operating segment: The information being reported may be for the consolidated group or parent, or it may be for one of the operating segments of the consolidated group.
• Operations continuing or discontinued: The operating segment for which information is reported might be continuing or it may be a discontinued segment.
• Measurement basis: The information being reported could be reported at historical cost, amortized cost, fair value, or some other measurement basis.
• Restatement: The information could have been restated due to a change in an accounting policy or because of an error in a prior period report.
• Reclassification:  The information of a prior period may have been reclassified to match the classifications in your current financial report.
• Reporting scenario: The information being reported could be actual information, or it might be forecast information, or perhaps even budgeted information.
• Third party verification: The information reported could be covered by a third party audit report or it may not have been audited at all.
• Other descriptive information: All sorts of other details could be important to specific types of detailed information such as the class of long term debt or a specific category of subsequent event.  These details may, or may not, be important to communicate. 
• Value of fact: Information reported could be a number such as "1,000,000" or it could be a piece of text such as "First in-first out", or it might even be an entire paragraph of text describing an accounting policy.
• Rounding: If the information reported is a number, the number could be rounded to the nearest millions of dollars or detailed to the nearest cent.
• Reporting units: Maybe the units are not dollars at all, but rather Euros or some other currency.  Or, the number might not even be monetary but rather the number of employees or the barrels of oil within a reserve.
• Reason information is not reported: Sometimes for a number of reasons the information which is required to be reported is not available and you need to explain why that information could not be reported.
• Relations to other facts or concepts: Facts reported relate to other facts being reported.  For example the line items of a balance sheet add up or "roll up".  A cash flow statement not only adds up (i.e. the net change in cash), but it also communicates a "roll forward" of the beginning balance of cash to the ending balance of cash.  Or, maybe the fact is not a number and therefore not involved in a computation but is rather an accounting policy and you want to organize it with your other accounting policies.

Another question to ask yourself is how the analyst using this information interpreting the information?  Is the analyst going to have to imply any meaning because when you reported the information you were not being explicit.  Is that analyst going to correctly imply the right meaning?

Sometimes XBRL taxonomies don't help you understand how to report certain identifying information or information which helps you properly represent the information you need to report in XBRL.  If the XBRL taxonomy does not, you will still need to do something to be sure the meaning you are trying to articulate will be interpreted properly by users of the information.

The bottom line is to ask users of the information if they are having any issues making sense of your XBRL based financial reports.  But the CPAs/CAs who create this information, those who review this information, internal auditors who work with this information, third party auditors dealing with this information, attorneys who help prepare and work with this information, and others need to be conscious of what they are saying in their XBRL based financial reports.  Software can help you, but you are the one who is ultimately responsible for the quality of your XBRL based financial reports.

When I first saw this I did not know what to think: sharing your transactions online! Here is one example of someone sharing their transactions online.

Sharing your transactions online. What, and someone is going to actually spend their time reading your transactions?  I have to admit, at first I did not understand Twitter either.  But now having used Twitter, having fiddled around with the API (application programming interface), I can see the sorts of things you can use it for.

So let's think about sharing your transactions online a little.

My first question is how the heck are they doing this.  It seems that the way this works, Blippy creates relationships with vendors like iTunes, Amazon.com, eBay, and other seemingly enlightened vendors; they read your transactions from them and repackage the transactions together.  So the transactions are grouped not by vendor, but by who the transactions relate to.

Now that is useful information to other vendors who want to sell you stuff.  I wonder if Blippy sells this information to others who want to sell you things.  It is sort of like providing information to create a profile of who you are based on the transactions you undertake.

I am not saying that sharing transaction information like this is good or bad; it is just like pretty much anything else, it can be used for good things or it can be used for bad things.

You do realize that you are being watched already.  When you go to a store and buy something a ton of information is captured: what you bought, what time you bought it, what other stuff you bought, where the stuff you bought was located in the store, etc.  All that is made possible by that little UPC (universal product code).  They also have your credit card number which they may not store in their system but they do know which credit card number or check number purchased something and they assign an internal ID to that.

About 15 years ago I took a class at Microsoft on Excel.  I found it strange that three quarters of the class was from Proctor and Gamble.  I started asking some questions and what they were doing was learning about Excel so they can use it to slice and dice all the data they were capturing as a result of the UPC information.  I thought that was interesting.

Personally, I have no problem with people knowing what I buy and in fact I would like Google and others trying to market things to me to do it more like a "smart bomb" with laser focus and less like the saturation bombing approach (i.e. volumes of junk mail relating to things I have no interest in).  I am sure this can get out of hand, but what the heck; I'm game.

OK, so let's look at this from a financial reporting perspective.  Why do we need financial statements when a company could just provide all their transactions and you could create your own financial statement, interpreting transactions how you want them interpreted and not how a company decided to spin their information.  Now, I am not saying every transaction, more summaries.  There is certainly information that a company has that should never be made public.

You can already look at a financial statement as a transaction, particularly if it is provided in XBRL.  You can read the financial information of one period, compare it with another.  The financial information is really a set of information.  Clearly humans need a nice presentation wrapper to look at the information, but providing the information itself with only one wrapper limits your ability to apply other presentation wrappers.  Separating the data and the presentation wrapper make it much easier to apply a different presentation wrapper.

Even if a company did not want to make all this data available to the public, this would still be a very useful process to use internally to piece together the financial report which comes from many different pieces within an organization.  The transactions or summaries such as the accounting schedules used to create the financial statements.  Also the auditor's (internal or external) schedules used to have a look at the transactions or summaries.  All these things are pieced together in something that is called a "closing book".  It used to be that these were collections of hundreds of spreadsheets and word processing documents.  They could be a Blippy-type service which consolidates them from your different business systems used to run your business.  There are different security levels: one for internal users, one for external users, another for internal auditors, another for external auditors.  Everyone is looking at the same information set with different security levels.  How efficient would that be!

Why should financial reporting not work this way?  What, we want those multiple sets of books, one used internally and the other (wink, wink) that we provide to the shareholders?  I don't think so.  Sure, you can reorganize the transactions for book and for tax purposes; but the information set is the same...the transactions which have occurred.  Security levels manage who has access to what, not Excel spreadsheets or Word documents.  The information from the user perspective looks pretty much the same, it is the back end which is radically different.