There's been plenty of industry buzz lately about the importance of XBRL data quality — and for good reason. For the filer, submitting flawed, inconsistent XBRL data can lead to public embarrassment, unwanted SEC attention, and missed business opportunities. Moreover, analysts and investors increasingly employ companies’ XBRL data to make critical judgments.
But despite all the talk about data quality, the big question remains: what defines high-quality XBRL data? Understanding the factors that drive data quality, and recognizing high- or low-quality data, is a growing necessity for both filers and consumers of XBRL data.
Consistency is key to quality
The basic trait of high-quality XBRL data is consistency. Data must be prepared in a manner consistent with other filers, and it must consistently convey the same information as traditional HTML financial statements. With thousands of companies preparing XBRL data, how can a filer ensure this consistency? At Merrill, our extensive XBRL experience has led us to develop seven key requirements for high-quality XBRL data — five that ensure consistency with other filers, and two to make XBRL data consistent with HTML financial documents.
7 Keys to XBRL Quality
CONSISTENCY WITH OTHER FILERS
1) Compliance with XBRL Specification 2.1
All XBRL submissions must adhere to XBRL Specification 2.1. Fortunately, almost all XBRL preparation software conforms to this specification, eliminating the need for preparers to understand the requirements in depth.
2) Following DQC rules and guidance
To improve the usability of XBRL for investors and analysts, the XBRL US Data Quality Committee (DQC) has issued (and will continue to issue) automated rules to detect XBRL errors, and guidance to create consistency of tagging among companies. Running the rules before filing, and staying up to date with the latest guidance is critical to ensuring consistent, high-quality XBRL data.
3) Leveraging current US GAAP Taxonomy implementation guides
The Financial Accounting Standards Board frequently publishes US GAAP Financial Reporting Taxonomy Implementation and Reference Guides. These guides provide practical insight and guidance on how to use the US GAAP Taxonomy to produce consistent, accurate XBRL data. These guides change regularly along with amendments to the US GAAP Taxonomy.
4) Familiarity with current US GAAP Taxonomy
For financial statement disclosures, the US GAAP Taxonomy lists more than 15,000 XBRL data tags, as well as the appropriate structure for those tags — from the presentation layout of the abstracts, tables, axes and line items, to the dimensional structures where applicable. Consistency requires strict adherence to these tags and structures, even as they may change significantly from year to year. While the US GAAP Taxonomy implementation guides provide useful guidance, seasoned XBRL preparers know that there is no replacement for direct familiarity with the taxonomy itself. This expertise enables XBRL tags to be applied correctly and consistently, each and every year.
5) Deep understanding of the EDGAR Filer Manual
Submitting XBRL data requires strict adherence to the guidelines set forth in the EDGAR Filer Manual, which covers everything from how to select tags, to the naming of the XBRL documents, to extremely detailed instructions on preparing XBRL. Some parts of a filing can be checked with automated XBRL validation software, but the more complex elements require thorough human review by individuals with a deep understanding of the EDGAR Filer Manual. Unfortunately, many of the errors identified in SEC XBRL submissions are the result of filers’ lack of knowledge and improper applications of the complicated EDGAR Filer Manual instructions.
CONSISTENCY WITH TRADITIONAL HTML FINANCIAL STATEMENTS
6) Using SEC Staff Observations/FAQs to error-check XBRL submissions
Periodically, the SEC releases its SEC Staff Observations and FAQs — a collection of the most common and significant problems noted in reviews of recent XBRL submissions. Many of these address situations where XBRL conveys a different meaning than the traditional HTML financial statements, including incorrect positive/negative integer signage, improper axis/member combinations, values not tagged, improper calculations and unnecessary extensions. These errors almost invariably stem from misapplication of the EDGAR Filer Manual, reiterating the importance of an expert knowledge of EDGAR rules and guidance.
7) Applying accounting expertise
Too often, companies rely on preparers that specialize in automated technology — not accounting and the finer details of financial disclosures. The assumption is that the final reviewer will bring the requisite accounting knowledge to catch errors. However, while these internal reviewers may know their companies’ accounting, they’re rarely well-versed in XBRL — and errors slip through unnoticed. High-quality XBRL simply cannot be achieved when the initial preparer lacks core accounting expertise. This knowledge helps ensure an understanding of the accounting behind the company’s disclosures, as well as the accounting significance of the US GAAP Taxonomy elements, and is essential to properly mapping financial disclosures to convey the correct information.
More than a checklist — a complex and evolving challenge
These seven keys aren’t easy boxes to check. Producing high-quality XBRL requires deep understanding, with a finger on the pulse of the ongoing changes to regulatory requirements and accepted best practices, as well as the evolution of how XBRL data is consumed and used. Software automation and error-checking can help some parts of the XBRL preparation process, but ensuring quality isn’t a challenge that can be solved with technology alone.
Merrill recently received XBRL Data Quality Certification from the XBRL US Data Quality Committee (DQC). Learn how this DQC accreditation validates the high-quality XBRL data preparation capabilities of our Merrill Bridge™ SaaS disclosure management platform.
An earlier version of this post incorrectly attributed a statistic to Calcbench. We apologize for this error.