Digital Financial Reporting

The transition/changes XBRL is enabling is explained by the book The Innovator's Dilemma, by Clayton Christensen, I believe. Entrenched established companies and attacking entrant companies would both gain from reading this book.

Why? The Wall Street Journal reports that Kodak is filing for bankruptcy.  Borders has filed for bankruptcy. Newspapersare dying off. iTunes and the iPod have changed the music industry.

This same type of disruption is occurring in the domain of financial reporting. If you are involved in financial reporting in any way you may believe you are exempt and that the changes will not impact you. But read the book, it just might change your view.

The global consultancy firm Gartner classifies XBRL as a transformational technology.  Gartner defines transformational as something that "enables new ways of doing business across industries that will result in major shifts in industry dynamics."

The Innovators Dilemma classified technologies into two buckets:

• Sustaining technologies which foster improved product performance
• Disruptive technologies which result in worse product performance in the short term, but then over the long term they bring to a market a very different value proposition than had been available previously

What Gartner says about "enables new ways of doing business" and what Chritensen calls "a very different value proposition" seem to be the same characteristic to me.

No one really knows exactly how all this change will pan out, who the winners will be, who the losers will be, what innovations entrants into the market will come up with, or the other dynamics which will push on the domain of financial reporting. You could make some good guesses.  Financial printers seem to be in a rather precarious position, that is rather clear. How accountants will be affected is less clear. Accounting software vendors, also harder to say.  Financial reporting workflow and processes in general, there are many clues emerging from the US SEC's bold experiment with XBRL.

Don't be fooled into believing that digital financial reporting will not take off in other areas of financial reporting, beyond public company reporting to the US SEC. There are many, many other existing innitiatives by regulators around the globe.  I have heard a figure from XBRL International that 70% of the capital markets report using XBRL.  I have also heard that there is work going on toward creating a not for profit reporting taxonomy and a state and local government reporting taxonomy in the US.

Who would have ever predicted that Kodak would have to file for bankruptcy? The evidence seems to be very strong that digital financial reporting may just become a reality.

How do you think things might change for financial reporting?

Not sure how I missed this, but I was just made aware of this MIT project.  The blog post describes the MIT prototype as:

Rong is working on a software prototype for translating financial reports from the XBRL format into the OWL language, the idea being to preserve and enhance the implicit semantics in XBRL and enable the logic model of financial reports, according to a soon-to-be-published paper co-authored by Rong.

Personally, I am skeptical but certainly open to being proven wrong.  Why am I skeptical?  Well, read this blog post and be sure to read the PDF pointed to on this post.

The bottom line is this: it is impossible to take something which has not modeled correctly from a semantic perspective, convert the syntax, and magically have the proper semantics.  Now, if the semantics of the SEC XBRL financial filings were correct you could convert all that information into whatever syntax you want including OWL/RDF.

Further, while AI (artificial intelligence) might be helpful in de-tanging the semantic mess of SEC XBRL financial filings, if the semantics are correct, why would you need AI to make the information useful?

Now, I admit that I could be totally missing the point here.  I do agree that someone will be able to use all that SEC XBRL information to compete with Bloomberg, Thomson Reuters, CompuStat, Hoovers and all those other data aggregators who are manually collecting information.  So sure, someone may make money converting the current manual process into some sophisticated process which uses AI and other technologies to over come the poorly modeled SEC XBRL financial filings.  Then, some different company can make money selling the data to others.

But I see two problems with that: (a) is that what the SEC meant when they said investors can more easily use the information?  (b) similar types of processes need to be created for each implementation of XBRL?

Seems to me that the best thing to do is to not fight the symptoms of the problem but rather to fix the problem.  Model the information more appropriately and THEN use all that nifty RDF/OWL and AI stuff to expand what you can do with the well modeled information.

What do you think?

I am currious to see what the folks at MIT come up with. And frankly, I do hope that they prove me wrong.

I am working to summarize the workflow, process, and techniques which I use to "examine" or "interrogate" or "scrutinize" an SEC XBRL financial filing.  (I am consciously trying to avoid the words audit, compilation and review as they have special meaning to accountants.)

A number of things are coming to my attention.

First, there are two fundamental orientationswhich you can use to examine an SEC XBRL financial filing:

• XBRL technical syntax orientation. This orientation considers if the filing is following the XBRL technical syntax rules and, if I am not mistaken, 100% of these rules can be validated using automated validation processes. The US GAAP Taxonomy Architecture and the SEC Edgar Filing Manual (EFM) further constrain the XBRL technical syntax.  As such, any XBRL tool which works with SEC XBRL filings has to create additional rules for those additional constraints.
• Financial reporting semantics orientation. This orientation considers the financial reporting semantics (or meaning) expressed in US GAAP.  For example, "assets = liabilities + equity". Or, "assets foot".  Or, "the income statement foots."  For more information on financial reporting semantics, see this blog post.

Second, there are a number of different perspectivesyou can take when working with at an SEC XBRL financial filing.  Another way to say this is that the best way to eat an elephant is a bite at a time:

• Fact perspective.  You can work with one of the individual facts within the report.  For example, you can be sure the characteristics of the fact are correct, that the value of the fact is correct, and so forth.
• Component perspective. You can work with a component of the report.  A component is a set of facts which go together.  For example, a balance sheet is a component, the document information is a component, or a disclosure is a component.  From the component perspective, you can be sure that each of the facts in the component are correct and that the facts in the set properly relate to other facts in the set.
• Holistic perspective.  You can work with the entire report or all of the components.  For example, making sure that the components fit together correctly.

What you look at, how you look at it, and what you focus on is different based on which perspective you are using.

Third, you will need to work with different SEC XBRL financial filings, comparing them:

• Different versions of a filing.  You will need to compare different versions of the same filing to manage changes between the versions.
• Different periods.  You will need to compare the filings of different periods to be sure all the desired changes have been made and that undesired changes did not occur.
• Compare with peers.  You will want to compare your filing with the filing of a peer or peers to compare and contrast differences in order to be sure you are taking the right approach to creating your SEC XBRL financial filing.

Finally, you can categorize the different report elements which make up an SEC XBRL financial filing into categories.  Basically, people who a term such as "tag" or "element" are being vague.  The different types of report elements within an SEC XBRL financial filing are:

• [Table]
• [Axis]
• [Member]  (sometimes the term [Domain] is used to indicate a special type of [Member] but that practice will be dropped.
• [Line Items] which contain concepts
• [Abstract]
• Concept
• Fact

For more information on these different report elements see here. Further, realize that relations between report elements are not random, there is some reasoning behind those relations, see here for more information about the relations between report elements.  And finally, the different report elements have different attributes or properties.  Knowledge of these different attributes/properties can make looking at the SEC XBRL financial filing more effective and efficient.

Personally, I find that the technique of using these different orientations, perspectives, and categories of the report elements which make up an SEC XBRL financial filing changes how you approach an SEC XBRL financial filing for the better.  Doing so helps you do all the work which you need to so you can be confident that you end up with a quality result; but you don't waste time and therefore waste money.

What has your experience been?

Tableau, which considers itself an alternative to traditional business intelligence software, put together a set of 10 business intelligence trends. (Watch the Tableau demo by clicking on the "see it in action" button.)

Here is a summary of Tableau's trends:

1. Big data gets even bigger
2. Self-reliance is the new self-service
3. The "Consumerization of Enterprise Software" accelerates
4. Mobile BI goes mainstream
5. Some companies start to get comfortable with social BI
6. Companies explore the BI cloud
7. Most jobs will require analytical skills ...leading to talent shortages
8. BI projects flourish under aligned IT & business
9. Interactive data visualization becomes a requirement
10. Hadoop gathers momentum - unstructured data isn't going anywhere

Now clearly Tableau is not going to publish a list which is not in it's best interest.  It likely published that list to help sell its products.  But, it is not a bad list.

BrightPoint Consulting published a nice little summary, The Future of BI: Are Dashboards Pointing the Way? which walks you through the things the BI community seem to be thinking about and also provides background on how BI got to where it is today.

I still don't totally get the connection between BI and XBRL. Some BI software vendors such as IBM, SAP, and Oracle seem to see a connection.  Others don't.  I believe that there is a connection but I don't have the clarity I would like as to the connection.

What I have learned by trying to make XBRL work within BI applications is some of the limitations of BI which I have summarized in my Modeling Business Information Using XBRL document (see section 4 Understanding the Multidimensional Model).  Here is a summary:

• There is no one global standard BI system or one standard multidimensional model used by BI systems.
• BI systems generally use OLAP.  And as such they have the strengths and limitations of OLAP.  As such, BI systems tend to work best with numbers and tend to force you to aggregate numbers.
• BI systems tend to be read only, you can use information from a BI system but you cannot put information into a BI system.
• BI systems focus on numbers and work with numbers extremely well; however they work less well with textual type information or narratives.
• BI systems don't tend to allow you to import schemas or other metadata which is used to work with the information, the tools tend to provide you mechanisms within the tools to create this metadata.
• BI systems tend to focus on information which is internal to an organization, it deals less well with information created external to the organization which it must use.
• BI systems tend to deal well with structured information and less well with unstructured information.

It seems to me that XBRL can help BI overcome many of those limitations. This could be a case of the innovator's dilemma.  Maybe companies such as Tableau who see themselves as an alternative to traditional business intelligence will displace the incumbents.

Do you have any ideas about the connection between XBRL and BI?  Perhaps you can help myself and others figure out where all this will end up.

I have two goals for 2012, both of which relate to improving the quality of SEC XBRL financial filings:

• Goal 1: Help accountants, in particular CPAs, become more consciously competent when evaluating the appropriateness of or otherwise interrogating/ scrutinizing an SEC XBRL financial filing.
• Goal 2: Help get some good software built which enables accountants to better achieve the first goal.

These two goals are definitely connected and from what I have seen and heard.  Further, as I see it CPAs are exposing them to a significant professional risk currently. Perhaps CPAs and other accountants don't realize this yet because they are still typically way ahead of their customers when it comes to properly grasping what a correct SEC XBRL financial filing looks like.  While the rather slack rules which the SEC have for filers currently comes from, I believe, a desire by the SEC to get filers to accept the SEC's XBRL mandate; I would expect, and I have even heard from others, that the SEC does not have unlimited patience.  Rules will get tougher.  I think that prediction would be hard to dispute. This will increase the professional risk exposure of CPAs even more.

Errors in SEC XBRL financial filings are not hard to see, you only need two things: (a) years of experience and (b) relentlessness and patience in configuring a process which generally combines numerous software applications.  I know this first hand because I have been working to figure this stuff out for many, many years and I have successfully configured a process which I can justify.  No stone is left unturned and every step which exists in the process has an easy to explain reason for its inclusion in the process.  And honestly I cannot say with 100% certainly that I covered everything.  But what I can say is that I put a great deal of time trying figuring out this process and the process is base on many, many years of building XBRL, building XBRL taxonomies, creating XBRL financial filings, etc. So frankly, I would be quite confident in showing the due diligence which are the basis and reasoning for the process and techniques which I personally use.

As such, I believe that I can stand behind the process and techniques which I employ.  But what I also find that I can usually ask three or four questions of any other accountant who has created an SEC XBRL financial filng and nine times out of ten show that their process has significant holes.

Most times the accountants are not aware of these holes in their process.  Other times they are aware of the holes and it is on their list to fix their process.

I only bring these deficiencies up in order to help rectify the situation.  In the short term, regretfully correcting this situation will require more training for accountants involved in the process of creating or scrutinizing an SEC XBRL financial filing.  In the longer term, software will be adjusted so that it is more useful.

But, in order to get better software, accountants and CPAs need to be conscious that there is a problem so that they can understand the problem and then put pressure on software vendors to get them the software that they need.

I am in no way blaming accountants, software vendors, the SEC, XBRL US, XBRL International, or anyone else for that matter.  I believe that this is simply a part of the maturing process.  Pretending that accountants understand what they are doing if they do not may seem expeditious, but I believe that approach to be counter productive.

Stay tuned for more information on the characteristics of a quality SEC XBRL financial filing and the process and techniques which I use to scrutinize such filings.