Why do we render XBRL?

As many filers are finding out during this filing season, XBRL rendering (making XBRL humanly readable) is not as sophisticated as we want it to be. In fact the most commonly used rendering engines have many problems that filers are experiencing as they review their XBRL exhibits. Let’s explore XBRL rendering using the SEC’s rendering engine as an example of the challenges posed by commonly used rendering tools.

When mapping company financial information (Facts) to the US GAAP Taxonomy (UGT), companies are following, or should follow, a process that includes planning, mapping, reviewing, testing, re-reviewing (as needed), approving and then filing. Notice that a part of that process includes viewing XBRL result`s. Inevitably, some form of rendering is the way we currently review amounts being tagged, the XBRL tags selected, the definitions and attributes of those tags and the interrelationships between the amounts reported (like calculation relationships and amounts in SEC filings that agree…or should agree).

We tend to think of financial reporting data in a visual way – in a way we can view it. That’s the old way of thinking about financial reporting. In the future people will be able to grab entire financial reports or individual amounts reported in a disaggregated way (i.e. if they want only EBITDA and Earnings per share, they need only grab the XBRL tags for those amounts for the periods they are interested in). Because XBRL tags the amounts being reported with contextual metadata, the individual amounts have meaning separate and apart from any financial report or software application. In other words, you may still want to think about data in terms of viewable renderings, but investors and other users of financial data are not obligated to do so.