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
block list.
- 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
following screencast.
https://www.screencast.com/t/hchpuyVw5af