XBRL 2.0

Digital financial reporting that actually works


It’s instructive 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.


In this 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.


Then 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.


Judging 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 and analyzed.  


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.



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.