Skip to content

XBRL Rendering: An Appropriate View

August 20, 2010

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.

Why Do We Render XBRL?

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.

XBRL Viewers are Not Created Equally

Many tools are publicly available to render XBRL data. When it comes to SEC filings, filers and users of the SEC’s website use the SEC’s Interactive Data (XBRL) viewer. The Interactive Data software is still a young technology. The SEC currently has long-term plan to improve its Interactive Data system, which is designed to first supplement then eventually replace the EDGAR filing system. The system will improve over time, but it’s not where we want it to be today.

The general philosophy used in the SEC’s rendering engine is to infer layout from the contents of the instance document first, then adjust the rendering based on the presentation linkbase, then determine how facts with different roles should impact the rendering. Here are some of the SEC’s basic rendering strategies (August 2010):

  • Facts are arranged into columns with descending periods from left to right without regard to anything in the taxonomy
  • Facts are shown in the same column if their end date and instant are the same, again without regard to anything in the taxonomy
  • Facts are then shifted one column to the left if there is a “period start” preferred label, but only if the role definition contains the phrase “cash” followed by “flow”
  • Rows are grouped together into alphanumerically ordered groups, according to the contents of the segment elements (and scenario elements, although scenario elements are rejected by EDGAR)
  • If the role definition contains the word “shareholder” “equity”, “partner” or “capital” then the periods become rows and the Equity Class axis are the columns.

There are also other known traits of the SEC’s XBRL viewer. These are the most common rendering problems filers encounter.

  • Bold formatting is applied to Abstract elements only. Abstract elements are textual tags with no related values that are typically used as headers
  • Facts of different types cannot be rendered on the same row. There are several different types of XBRL tags in use today
  • Nil-valued facts cannot be rendered (a dash cannot be rendered – only an actual value like $0 or 55% can be rendered). Nil valued facts consist of XBRL tags with null or blank values
  • Underlines are placed below XBRL tags that play a total role. We want underlines to be above totals or perhaps above and below totals, but they only render below totals
  • The year of the reporting period in the Document & Entity Information (DEI) renders as 2,010 instead of 2010
  • When the rendering engine sees any duration elements and instant elements in the same period, both types render in a column with a heading like “for the … ended”
  • Financial information tagged with the same taxonomy element (like in the derivatives footnote, the investments footnote and the fair value footnote) may render in all three places. This type of rendering problem is known as “flow through”.

The SEC’s rendering engine is free to use (and even download), but many investors and users of SEC reports will choose to use more sophisticated analysis and rendering tools. The tools on the filer side and on the investor side are many and have varying levels of sophistication. In addition, all XBRL tools will improve over time. As you consider the weaknesses in the current SEC viewer you need to remember these things.

  • Those who utilize your XBRL filings may never render the data
  • Some users will view only select (disaggregated) XBRL data
  • Those who choose to view a rendering may use a tool other than the SEC viewer
  • If investors want to view your filing they will likely rely on the user-friendly HTML or PDF versions
  • Investors who want to analyze companies will choose to download your XBRL data into a database to automate analysis
  • The SEC rendering is NOT a part of your XBRL filing

What is in Your XBRL Filing?

A user-friendly way to understand the concept of what is being reported is to think of the filing as consisting of your facts and values (the Instance file), the company specific taxonomy with all of its various attributes (the Extension Taxonomy) and the relationships between the two (the “Tags”). Technically speaking, your SEC filing consists of six electronic files. Each of these files has a specific role in defining your data. Here are the filenames and their roles.

XBRL Filename (1) File Type Purpose of file
xxx-yyyymmdd.xml: Instance file Contains the actual facts and values in your filing. Each fact in the instance document is related to an element in your company’s Extension Taxonomy.
xxx-yyyymmdd.xsd:  Schema file Defines the actual concepts of an XBRL based markup language. It gives their names, their data types, whether you can report about them. I like to think of the Schema file like a traffic cap for the other XBRL files.
xxx-yyyymmdd_cal.xml Calculation linkbase  Defines how values of concepts should sum up from one to another
xxx-yyyymmdd_def.xml Definition linkbase Allows users to define relationships between elements. For example a relationship can be defined that the occurrence of one concept within an XBRL instance mandates the occurrence of other concepts
xxx-yyyymmdd_lab.xml Label linkbase Allows the user to attach labels to a given concept
xxx-yyyymmdd_pre.xml Presentation linkbase Defines how concepts are ordered and nested

 

(1) The naming convention for these files is as follows: xxx = company specific identifier (like ticker symbol), yyymmdd = the report date and the remainder of the file name specifies the type and role of that XBRL data file

Conclusion:

Remember that as you complete your XBRL filing, that it is very important to get your facts and values right. Your data should be mapped to the appropriate element in the UGT or extension taxonomy. Make sure the definitions and attributes or properties of your selected elements properly represent what you are reporting. It is especially important to get the period type, balance type, data type and other taxonomy attributes (or properties) correct. In addition, the calculation relationships between your data must mathematically work. All of your facts and values should be mapped to the proper taxonomy at the appropriate level.

Your financial statements are required to be detail tagged and your footnotes must be tagged at the following four levels:

  • Level 1: Each complete footnote tagged as a text block
  • Level 2: Each significant accounting policy within the significant accounting policy footnote tagged as a text block
  • Level 3: Each table within each footnote tagged as a text block
  • Level 4: Within each footnote, each amount (i.e., monetary value, percentage and number) is required to be separately tagged

As you complete your XBRL filings, remember to focus on your facts and values and their relationships to the UGT or extension taxonomy. Also give significant consideration to the definitions and attributes of the elements chosen. By doing so you will emphasize the data being reported, not how poorly the formatting of a rendering tool is. Remember too that the purpose of your XBRL filing is to make your data machine readable, not beautiful to look at. We have HTML and PDF versions of your filings for view ability.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: