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 Inter and other digital media for information dissemination, and most recently the evolving use of XBRL for financial reporting. He is an independent nsultant 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 de the XBRL file, and to what level of detail you present, you uld have discrepancies between the rendered XBRL files and the HTML or PDF.

XBRL proponents (and I unt 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 mputers to understand the ntent and ntext of business reporting information. It was hard enough to get the formatting rrect for the mputers 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 ding ignores the XBRL ding. 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 mpany to review the XBRL ding to assure that their XBRL files aurately 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 ding to some degree, although proper valid XBRL ding at times will not render rrectly. These problems can be alleviated at times by arbitrary changes in the order of des. This requires that the preparers spend time attempting to get around the rendering “bugs” to allow proper rendering for review by the mpany’s management for assurance purposes.

If this was not enough of a problem, the preparers have to ntend with the SEC’s Viewer, which uld have its own problems with a rrectly formatted XBRL file. So now, the preparers are forced to begin experimenting with the de 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, mpromise the quality of information in order to improve rendering. Rendering problems also our 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 ncern for the filing mmunity at large. There is no magic bullet for the problem today, although awareness by the filing mmunity of these limitations will help in a rational response to it.