to view how publicly-traded compliance software companies prepare their own
XBRL filings. After all, these are the XBRL experts. There are two such
companies – Workiva (WK) and Donnelley Financial (DFIN). This blog compares
their most recently reported income statements.
statement, the components of [Net Sales] are correctly shown on the [ProductOrServiceAxis].
Then, Donnelley inexplicably abandons dimensions in reporting [Cost of Sales]. [Net
Sales] and [Cost of Sales] should have a consistent taxonomy, sharing the same
domain elements. Why is this important? Analysts care about margins. In this
case, calculating gross margin by sales
type requires manually aligning domain elements with primary elements. While this
XBRL data may be machine-readable, it’s no longer machine-understandable.
Donnelley determines that both [Cost of Sales] and [SG&A] should be custom
items to highlight the exclusion of [D&A]. [SG&A] in the standard
taxonomy doesn’t include [D&A], so that extension is unnecessary. And while
[Cost of Sales] in the standard taxonomy does include [D&A], very few
companies explicitly include or exclude the item. And [D&A] can always be
reconciled against the cash flow statements disclosure of total [D&A]. In
any case, the [D&A] clarification can be made with custom labels without
defeating the statement’s comparability.
This statement constitutes a well-formed, compliant reporting
model. No extensions, no block errors, no taxonomy errors, no validation
errors, no missing or erroneous relations. Revenue and Cost of Revenue are
described using the same structure and domain members.
solely from this example, Workiva gets it. Donnelley doesn’t. The purpose of
XBRL is to achieve comparability by converting statements to a standard
taxonomy. Donnelley’s extended taxonomy model is both non-standard and
inconsistent, inhibiting users’ ability to easily digest the data. Workiva’s
presentation is more user-friendly, producing statements that can be both read
A recent Donnelley Financial (DFIN) white paper states that
"Efforts (by one researcher) to automate the semantic mapping of new
elements across taxonomies have had disappointing results". On the
contrary, XBRLogic has successfully developed semantic mapping as part of its XBRL
standardization process. If DFIN and other software vendors used a similar
process to inform their client’s tagging decisions, there would be greater
consistency, fewer errors and fewer extensions. Over 6,000 companies are
currently tagging in the dark, oblivious to the filing practices of their
peers. Real standardization requires translating disparate elements to a
single, fixed dictionary based on clear rules. Unfortunately, the XBRL
dictionary isn’t fixed (by design) and the rules are neither clear nor enforced
by the SEC. But software vendors can help by effectively serving as the
clearinghouse for industry tagging practices.
Here's a sampling of primary statement extensions created by
DFIN clients, showing XBRLogic's mapped standard elements. As you can see, most
of these extensions are unnecessary, particularly since filers can attach
custom labels to standard elements. Note that the selected row 'Customer
Deposits' was mapped by matching over 2,000 labels exactly and almost every
filer tagged the item to 'Customer Deposits, Current'. What a surprise! Why did
this company create a custom element? And why didn't DFIN present peer data to
guide the tagging process?
At XBRLogic, we’ve created over 74,000 maps to
date, summarized below.
One of the central functions of XBRLogic’s standardization process is mapping extended concepts and
foreign concepts. Extensions (custom tags) have broken XBRL as a source of
standardized financial statements. To achieve comparability, extensions require
mapping. Enter XBRLogic’s solution, which can be used to both map
extensions by end users and tag line items by filers. It’s the same process, fueled
by over 60 million tags created by 6,000 companies over the past 6 years.
The proprietary mapping process, called
Consensus Tagging, is multi-step, as follows:
- Identify Blocks.
Statements are broken down by blocks. ‘Current Assets’ is a block;
‘Inventory’ is a sub-block of ‘Current Assets’, etc. Based on the item’s
label and qualified name, blocks can be qualified or disqualified. The
mapping in the following steps must come from elements in the resultant
- Find Company Tag.
Occasionally, a company will create an extension for an item that was
previously tagged to a standard element. The prior tag is the best
mapping, since it was based on the company’s judgment.
- Find Exact Match.
The first label search looks for an exact match. The item’s label or qualified
name (normalized and stemmed) is matched exactly to a standard element.
When multiple elements are returned (common), the highest frequency
standard element is selected.
- Find Partial Match.
If an exact match is not found, partial matching is deployed. Strings of
stemmed keywords are derived using distinguishing lexicon types (NLP),
then used to search for partial matches among all labels, aided by Azure
SQL’s full-text indexing. The highest frequency result that meets a
minimum edit distance (fuzzy matching metric) is selected.
- Apply Expert System.
If label matching fails, an expert system of qualifying and disqualifying
‘block terms’ is applied to identify the standard element nearest in
meaning to the extension. If only the relevant block can be determined,
then the block default element is used.
- Use Default.
When all prior methods fail to identify a standard element, the default
associated with the original summation parent is used, i.e. ‘Other
Sundry Current Liabilites’.
The mapping process usually takes 1-2 seconds and is integrated into the
overall standardization process. All auto-created maps must be verified after
the fact by an operator. Maps can also be created in bulk, as shown in the
First, a quick review of XBRL as presented by the SEC
- XBRL financial data is NOT standardized.
Incredibly, the SEC allows companies to create custom elements unanchored to
standard elements, undermining the central purpose of XBRL.
- XBRL filings are incomplete, incorrect and
inconsistent. There are missing and invalid relations, incorrect signs, tags from
the wrong taxonomy and the wrong block, numerous inconsistencies with the
standard taxonomy, just for starters.
- The SEC enforces only the most egregious errors,
so there is effectively no quality control over XBRL data.
Therefore, anything beyond the most basic use of XBRL data
requires serious modification. The major data aggregators take hours to fix the
data. XBRLogic has automated the process and now is able to create
fully-standardized financials in under 2 minutes. Grab some popcorn and go
see the movie – it’s short!
Recently, a data vendor posted on Linked In that they could
deliver standardized financials in 20 minutes from filing with the SEC.
That may be impressive to the average investor, but to the professional
investment community, 20 minutes is an eternity. With automation, machine
learning and natural language processing, standardizing financial data is
rapidly becoming friction-less.
XBRLogic is at the leading edge of that movement, having
just achieved a 90% success rate for its proprietary standardization process
while delivering completely normalized financial results within 2 minutes.
That’s not a misprint. Two minutes for standardized, fully classified financial
statements, calculated 4th quarter and quarterly cash flows, and key
metrics. Using experience gained from automating S&P Capital IQ’s HTML extraction,
XBRLogic has developed a 100% automated process using XBRL-based filings.
XBRLogic is continuing to expand its coverage, first to
financial institutions, then to IFRS and other international jurisdictions. Parties interested in leveraging this
technology via licensing or collaboration should contact XBRLogic.