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.
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.
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.
paraphrase from ‘No Country for Old Men’… IF THE RULES BROUGHT US TO THIS, OF
WHAT USE ARE THE RULES?
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:
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?
- some filers
simply don’t bother
- most software vendors
don't require calculation arcs
- 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)