XBRL 2.0

Digital financial reporting that actually works


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:

  1. 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. 
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.