XBRL 2.0

When a leading national restaurant chain and a leading software vendor combine forces to produce an SEC filing, we'd expect an outstanding work product, right? Not in this example. 

First, a simple validation routine in Workiva's software would reveal that Luby's cash flow statement doesn't add up against their specified taxonomy. My guess is that the software does the validation, but doesn't require the correction. That doesn't let Luby's off the hook; it's their filing and their responsibility. 

Second, unless Luby's has become a bank or insurance company, they're using tags from the wrong US-GAAP taxonomy. This may not seem like a big deal unless you try to compare Luby's results with other restaurants, for example.

Sadly, this is par for the course with XBRL filings. Insufficient attention is paid to the details. Considering that a major reason for requiring companies to file using XBRL is comparability, every stakeholder should work to ensure that this goal is achieved. That means greater care by the company, more robust software and better enforcement by the SEC. This is accounting, not rocket science, and users shouldn't have to fix the data before using it. 

XBRL. An extensible business reporting language. Public companies report in a digital format using a common taxonomy. Speed. Accessibility. Economy. Comparability. Sounds really good, right? Well, it could be. Unfortunately, the SEC’s implementation of XBRL is yet another story of a well-intentioned government program that refuses to succeed.

Let’s set aside the fact that ‘extensible’ has come to mean that a company can add new ‘words’ to this business language at any time and for any reason, or for no reason. Standardization isn’t enforced and comparability isn’t achieved. XBRL will never be the default ‘reporting language’ of business until the ‘dictionary’ is controlled.

But there’s an equally troubling aspect of XBRL that undermines its utility. The SEC’s requirements for tagging company data to the US-GAAP taxonomy lack specificity and enforcement. Elements from the banking taxonomy are used by commercial companies. Company ‘duration’ elements are tagged to XBRL ‘instant’ elements. Company-defined relationships among elements are inconsistent with the XBRL taxonomy. Companies routinely redefine standard elements via labeling. And the list goes on.

Here’s an example. Campbell Soup Company has been using an incorrect tag in its XBRL filing for years. It’s decided that ‘Other cash flow from operations’ in its Cash Flow Statement is a good fit for the US-GAAP subtotal ‘Adjustment to Reconcile Net Income to Cash … “. And that it’s a good idea to re-label the US-GAAP element that aggregates all adjusments to net income as ‘Other’. A non-subtotal is tagged to a subtotal, a standard element is completely redefined and the user is left to figure it out. This error hasn’t been noticed by the company, nor by Workiva’s filing software (which should flag obvious tagging errors), nor by the SEC’s enforcement division (which should run every filing through robust validity tests).

At AsReported.com, we see exceptions like these every day in our standardization process. They’re a symptom of the loose tolerances accepted by the SEC and the filing software that it spawns. With few rules and limited demand for the XBRL product, companies view XBRL as a compliance headache rather that an investment in more effective communication of financial results.  

One of the primary objectives of XBRL is comparability. Create a standardized taxonomy and require that companies tag their financial results to that taxonomy. This would be a universal language of business and provide access to standardized data that was only available through expensive subscription services in the past. And since this standardization was being done by the filing companies, this data would be available to everyone almost immediately. Good plan. Poor execution. The SEC’s implementation of XBRL allows companies to add items to the standard taxonomy. So, the taxonomy isn’t really fixed; it’s more like open source. Add items, change item relationships, redefine the meaning of items, use items from other industry taxonomies, etc. It’s pretty much anything goes.

I think there’s a reasonable argument to be made for extensions. Every business is unique and sometimes there simply is not a standardized concept that captures the meaning of the company’s line item. Fair enough. But there’s always a related item that the extension could be linked to, and the cost of adding those links would pale compared to the benefit to end users. Alternatively, companies could express their uniqueness by adding dimensions to standard concepts. For example, an ‘inventory type’ dimension would allow a company to add custom members, all rolling up to a standard inventory item. This is easily accommodated by XBRL’s dimension structure.

Short of that, the SEC should at least require that extensions be rare and completely necessary. Remember that when a company tags an item to a standard item, it also creates a unique label. So even without extensions, a filing company is able to bend the meaning of a standard concept to reflect its own meaning.

After mapping over 50,000 company extensions as AsReported.com, it’s become apparent that there is little if any regulation over whether, how or when extensions can be created. The tables below are a sampling taken just from ‘Current Assets’. As you can see, there is little justification for many of these extensions as almost identical items exist in the standard taxonomy.

For most serious end-users of financial data, comparability is essential. By design, XBRL doesn’t require comparability, even though it aspires to it. And its implementation turns a blind eye to completely unnecessary extensions.  

While XBRL has rightly been criticized for  lack of standardization, poor enforcement of guidelines and poor data quality, there are hopeful signs. For example, the FASB's US GAAP Financial Reporting Taxonomy, against which companies are required to tag their own taxonomy, contains a reference linkbase that serves to bridge XBRL with current accounting standards. It's a useful tool for both filers and auditors of XBRL financial data, particulary if exposed in user-friendly application software. AsReported.com has integrated these references into its XBRL framework and is implementing a web version. Here's a brief demo of this functionality...

XBRL-FASB Links Demo