Written by Gary Purnhagen      Posted on  August 5, 2009

Gary Purnhagen has more than 20 years’ experience in helping firms in diverse industries meet document processing challenges, including SEC disclosure. His past experience has included responding to the SEC’s EDGAR program, use of the Internet and other digital media for information dissemination, and most recently the evolving use of XBRL for financial reporting. He is an independent consultant assisting firms in embracing innovation and responding to the SEC’s XBRL mandate.

In an ideal world, properly formatted XBRL files should render using the various software packages on the market matching the presentation of the HTML or PDF version of the same information. Unfortunately, this is not the case. Today, depending on which rendering software you use, how you code the XBRL file, and to what level of detail you present, you could have discrepancies between the rendered XBRL files and the HTML or PDF.

XBRL proponents (and I count myself as one) will say this is a result of the original intent of XBRL and is a problem that is being addressed by initiatives such as Inline XBRL. All true. The original intent of XBRL was to create a format for computers to understand the content and context of business reporting information. It was hard enough to get the formatting correct for the computers to be able to understand this information and so the focus was not on addressing the rendering issue.

Inline XBRL essentially allows the XBRL file to be wrapped up in HTML, presenting the XBRL tagged information in HTML. The browser, presenting the HTML coding ignores the XBRL coding. The Inline XBRL in practice is still a year or two away.

Let’s pause for a moment and look at the need to render XBRL. At this point in the adoption of this new evolving technology the primary need for rendering XBRL is to allow a company to review the XBRL coding to assure that their XBRL files accurately reflects their financials as reported. Today, the best way of doing this is to render the XBRL financials and ensure that they match up with the HTML or PDF format, which was signed off by management.

The software available for preparing XBRL all can render XBRL coding to some degree, although proper valid XBRL coding at times will not render correctly. These problems can be alleviated at times by arbitrary changes in the order of codes. This requires that the preparers spend time attempting to get around the rendering “bugs” to allow proper rendering for review by the company’s management for assurance purposes.

If this was not enough of a problem, the preparers have to contend with the SEC’s Viewer, which could have its own problems with a correctly formatted XBRL file. So now, the preparers are forced to begin experimenting with the code to get around the rendering problems with the SEC Viewer.

Furthermore, while the SEC’s rules call for the rendering of the XBRL file to agree as closely as possible to the financial statements, there are real limitations to the SEC’s Viewer. For example, it seems that the SEC’s Viewer cannot handle identifying balances as Audited or Unaudited. The solution for many filers has been to ignore this crucial piece of information — in other words, compromise the quality of information in order to improve rendering. Rendering problems also occur when dimensions, which allow for multidimensional presentation of information, are used.

Again, these problems are a reflection on the current state of the emerging technology and will eventually be addressed. However, for the time being, they are causing great concern for the filing community at large. There is no magic bullet for the problem today, although awareness by the filing community of these limitations will help in a rational response to it.
 

Add to Del.icio.us | Digg this

This entry was posted on Wednesday, August 5th, 2009 at 7:50 am and is filed under General, . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.