Don't Be Late for the XBRL Train

Understanding XBRL and its Business Impact

NOTE: This article originally appeared in the February 2008 issue of Flawless Compliance, under the "Center Stage " section. The link to the actual issue is at the bottom of this article.

XBRL, our center stage topic this month, is primed to become the most important formatting standard that the compliance industry has ever seen. SEC Chairman Christopher Cox recently reaffirmed his alignment with XBRL by stating, “In 2008, following years of evaluation and experience through the SEC's voluntary XBRL pilot program, the Commission will consider a rule for the use of interactive data by U.S. reporting companies that will parallel efforts already underway in other countries.”

So, in anticipation of an SEC ruling making XBRL a mandatory component of financial statement submission, let's take a look under the hood and see how it will shortly impact issuers.

But first, what exactly is XBRL?

XBRL stands for eXtensible Business Reporting Language. It's a standard based on XML ( eXtensible Markup Language ), which you might already be familiar with. Information Technology has been using XML quite extensively over the last few years, to foster efficient and accurate data communication between systems, like web services in a Services Oriented Architecture ( SOA ). XML is itself a standard way of representing data.

There's no binary black box like compiled code; everything is done in plain text. You can open up any XML document and read it, although it may be confusing to understand unless you understand the standard. XML is like HTML in a lot of ways, only more strict ( i.e. case sensitive, and much more picky about start and end tags). Contrary to what some people might think, the HTML standard is not based on XML and would not pass strict XML formatting rules. There is however an XHTML standard which is an XML compliant standard that performs the same purpose as HTML. As time goes on, the web development community is embracing the XHTML standard more and more, over the less precise HTML format.

Having a strict formatting standard makes XML a great candidate for communicating data between systems, however the format must be extended before it can be used for any practical purposes. In the XHTML example, XML is extended for representing and displaying web pages. With XBRL, XML is extended for the purpose of representing financial statements. Once your financial statement is encoded in XBRL format, its actual data elements ( not just numbers and text ) can confidently be transmitted to any other system, including EDGAR, without the fear of losing its meaning and accuracy. For instance, with your XBRL statement, EDGAR can determine what your gross revenue is for a period, without the need for complicated parsing routines that are prone to error. This is a natural and significant improvement for EDGAR, which has its roots in simple text transmissions ( ASCII ), and is now relying on HTML to accept financial data from issuers.

Okay, how do you know XBRL will work for you?

First of all XBRL is not new. For about 10 years now, the effort has been pioneered, promoted and proven by XBRL International, a non-profit organization of approximately 550 companies and agencies worldwide. Over the years, they have had plenty of time to improve the standard, making sure it works for a variety of situations, including the accurate tagging of data in financial statements.

Secondly, XBRL application for SEC filing has been piloted for some time now. In 2005, the SEC established a Voluntary Filing Program to test the XBRL filing process with the EDGAR database. To date, approximately 55 companies have been involved in over 240 submissions of XBRL data on EDGAR.

Finally, it is being used today by organizations all around the world. There are several case studies available at the XBRL International website to review, including the Bank of Spain where more than 400 banks are filing on a monthly basis, and the Bank of Japan where financial services companies have been filing since 2006.

So, how will XBRL improve your situation? What's the ROI?

In a nutshell, XBRL is more time efficient and accurate, reducing your total cost of compliance. According to the Journal of Accountancy's June 2007 issue, United Technologies reduced their 10-Q preparation process cycle time from 845 hours to 700 hours, marking a 17% improvement.

The total investment in time was 80 hours, to learn the new software and tag the 10-Q data. The cost of the software was nominal ( under $1000 ), so with a possible total investment of $6,600 ( I'm estimating $70 / hr in labor ), I estimate they are saving $10,150 per quarter, or $40,600 per year. In reality, United Technologies opted to spend a total of $40,000 on the effort, which included the software, the 80 hour implementation time and learning curve, and an external audit of their scenario by a big four auditing firm. Of course the external audit was entirely optional, but even with the added expense, their 5 year annualized ROI% of 81.5% ( estimated based on assumptions ) for the effort is quite respectable.

Of course, this is just one example. After reviewing the United Technologies case study, my feeling is that their process cycle time could be reduced even more, in fact significantly. I could probably get their 10-Q preparation process cycle time to under 100 hours with proper automation. In fact, I would set a target of 45 hours, which would represent a savings of $56,000 per quarter, or $224,000 per year. In 5 years time, that's a savings of over $1 Million. That's huge!

Great, so what's next?

If you would like to find out more about XBRL, visit the XBRL International website. There is a wealth of information there, including more technical details, case studies, updates and more.

If you would like to get started with an XBRL effort, feel free to give me call to discuss.