XBRL 2.0

Digital financial reporting that actually works


I recently listened in on a meeting of the XBRL-US Data Quality Committee (DQC). The DQC was reviewing new non-mandatory rules governing XBRL tagging. It included a 20-minute, mind-numbing discussion of the proper presentation of lease liabilities. It was unclear what this had to do with XBRL.

More generally, I was struck by the extent to which XBRL governance had devolved into complex accounting minutia. The whole idea behind XBRL was to simplify financial reporting against a common dictionary that would allow easy comparisons across companies. We could have predicted that like other regulatory endeavors, countless rules and restrictions would make compliance more costly and undermine its original goals.

Between the DQC rules and the Edgar Filing Manual, there are plenty of rules to follow. And yet, there is wide variability in how the rules are interpreted and little clarification, much less enforcement, from the SEC. The result is chaos that resides just beneath the surface of normal-looking financial statements. It’s in the metadata - the tags, the hypercubes, the dimensions and the taxonomies. It requires experts to understand. Ultimately, the main benefit accrues to companies built solely to help filers meet the requirements. Financial data hasn’t been ‘democratized’ as many claim, it’s been ‘institutionalized’. Small investors were the target beneficiaries, but they still must pay for costly subscriptions to access quality fundamental data.

To paraphrase from ‘No Country for Old Men’… IF THE RULES BROUGHT US TO THIS, OF WHAT USE ARE THE RULES?


Anybody familiar with XBRL has heard of extensions. But not many are aware that extensions go far beyond these custom tags. In fact, filers create an entire EXTENSION TAXONOMY as a bridge from their internal taxonomy to the US-GAAP standard taxonomy. Literally anything in this extension taxonomy can be customized: tags, labels, signs, units, hypercubes, dimensions, members, captions. Obviously, this is a recipe for chaos. 

But there’s one requirement of this taxonomy that allows the data to be usable – the CALCULATION ARC. This simply describes the relationship between two primary elements, like ‘Inventories’ is a summation component of ‘Current Assets’ with a weight of 1. The calculation arc gives the extended taxonomy meaning. With it, users (and more importantly, users’ software) can complete the translation to the standard taxonomy by mapping custom tags, correcting signs and validating facts. Without it, standardization and efficient data ingestion are extremely difficult.


Here’s the requirement from the Edgar Filer Manual – Version 2:

6.15.2. If the original HTML/ASCII document shows two or more line items along with their net or total during or at the end of the Required Context period, and the instance contains corresponding numeric facts, then the DTS of the instance must have an effective calculation relationship from the total element to each of the contributing line items.


The problem is that 22,132 calculation arcs are missing YTD. That's 2.1% of the 1,013,308 primary line items tagged in 13,333 commercial XBRL filings. Many others are mis-specified. The reasons? 

  1. some filers simply don’t bother  
  2. most software vendors don't require calculation arcs
  3.  the SEC chooses to look the other way.  

Clients of certain software vendors are more likely to omit calculation arcs, like Novaworks. Here’s a montage of some recent Novawork’s client filings that are largely devoid of the required calculation arcs. (items in red are missing arcs, any colored item is a problem)