While speaking at the 2011 Year-End SEC Conference in Phoenix earlier this month, and this week at the same program here in Silicon Valley, an interesting question came up. Despite filers’ efforts to match their HTML financial submission to the rendered version (vendor’s viewer or reviewers’ guide), the SEC and XBRL US continue to report numerous data quality and consistency issues on XBRL submissions.
Where is this disconnect? This two-way comparison is akin to comparing two static spreadsheets without regard for a third element: the underlying raw data and interrelationships of the facts. As a result, XBRL data may be entered incorrectly with the wrong mapping or signage, or unit or calculation errors.
The importance of a three-way match
In accounting, we substantiate a financial obligation by matching three documents: an invoice, a valid purchase order and a receiving document. Similarly, in the world of XBRL, a three-way match of the three key documents—HTML submission, SEC Private Previewer and the metadata, with final verification against the metadata (the underlying raw data in the instance document)—is key to a successful filing. As the SEC says, “the rendered version of the Interactive Data File may be a useful tool to help determine the completeness of your data, but is not the best mechanism to check the accuracy of the tags selected or other underlying details.”
What you see is not always what you get
Often the signs in your HTML and viewer are presented with brackets due to negated labels, but the raw data in the instance document should almost always be tagged as positive numbers. The U.S. GAAP taxonomy is designed to reflect a natural or absolute balance. Think about general ledger systems, which show debits and credits rather than positives and negatives. It’s helpful to think about XBRL in this way. If you see a negative number in the raw data, ask whether it makes sense for the balance to be negative. Always check the definition and determine if this element should be one-way (always positive, like revenue and expense) or two-way (increase/decrease, gain/loss, proceeds/payments, profit/loss and so on).
Three-way match = completeness + accuracy
Whether you use a bolt-on or a built-in solution, the three-way match is critical to the XBRL control process. Work with your service providers or software tool to extract contextual metadata from the instance and other linkbases to perform the following common errors review: (1) negative values, (2) units and (3) negated labels and calculation links. This will allow a complete review of selected elements and determination of whether the data has been entered correctly.
Quality XBRL data is of paramount importance as key stakeholders (such as regulators, data aggregators, analysts, investors, filers and auditors) begin to use and rely upon XBRL data for business decisions. It is ultimately the filer’s responsibility to ensure that the underlying metadata is complete, accurate, and consistently mapped to allow data consumption software to tell the right story.
