By Mike Schlanger, Vice President of XBRL Business Development and Strategy for Merrill
Most publicly traded companies in the United States are now filing their financial statements in XBRL. While the first generation of filers has a few years of experience by now in XBRL tagging, the learning curve continues for many professionals involved in corporate disclosure. In this two-part article, Mike Schlanger, Merrill Corporation's Vice President of XBRL Business Development and Strategy, with input from Lou Rohman, Merrill's VP of XBRL Services, summarizes the most important underlying considerations that filers must know when preparing XBRL instance documents, some of which might run against the grain for others in the XBRL industry. In Part 2 (which will appear in the August 2013 issue of Dimensions), we explain that along with internal expertise, external expertise is usually necessary; the honeymoon is over (liability risk is now real for many filers); and XBRL is here to stay with multiple uses for the data.
XBRL is a language, and you are the translator The preparation of SEC filings as XBRL instance documents is more complex than most filers realize. XBRL is a language-Extensible Business Reporting Language, in full-that allows a computer to recognize and process the financial information you submit to the SEC. Like any human language, XBRL has rules and protocols that must be followed to ensure the full meaning of your disclosure is captured when translated. While you do not have to become expertly fluent in XBRL, you must be proficient enough to understand more than just what tag to use: you also need to know how the language works, how values must be entered, how select tables need to be structured, and much more, so you can verify that the translation accurately reflects your SEC EDGAR filing.
As evidenced by the SEC's repeated calls for companies to improve the quality and accuracy of their XBRL filings (see, for example, Dimensions articles on the SEC staff observations, on Page 4 of the May 2012 issue or Page 6 of the June 2012 issue), too many filers appear to be taking translation shortcuts. They are not devoting enough time or getting the proper assistance to learn what they need to know before they can validate the accuracy of their reports. The cost to you of such apathy? You are effectively delegating your job-confirming that your financial statements are being reported correctly-to your XBRL vendor, while the potential liability for a misstatement remains entirely (and painfully) yours.
The errors we continue to see in XBRL filings are surprising. Financial reporting directors and managers are known for great attention to detail, which is clearly demonstrated in the quality of their EDGAR filings. Yet many of these same professionals are submitting XBRL filings with glaring mistakes, which include: unnecessary extensions, invalid axis member combinations, missing calculations, values entered incorrectly, and more. These are mistakes that the SEC has repeatedly cautioned companies to focus on and take action to avoid.
It is difficult to learn entirely everything you need to know about XBRL and the EDGAR Filer Manual; however, the companies that are submitting high-quality XBRL have conquered the task, and many have used outside help to understand what they do not know.
At Merrill, we start our client engagements from a simple premise: filers should be taught how to verify that the XBRL translations we produce are properly prepared. Through consultation with our XBRL-fluent CPAs, Merrill clients learn what they need to know about how XBRL works. This can take time. Our clients' corporate disclosure teams typically learn as much as possible about XBRL from our consulting team and continue to build upon their knowledge with each passing quarter.
Software does not verify accuracy. Software can verify whether certain items in an XBRL filing are compliant with the rules and specifications, but there are a significant number of items in an XBRL filing that cannot be checked by software. For these, it is important to have knowledgeable individuals review the XBRL for errors. Moreover, filers who review only the rendered version of the XBRL document are blind to its structure and therefore vulnerable to mistakes.
The potential for errors in value entry-a common tripwire-illustrates the point.
A value erroneously entered as a negative in XBRL may appear to be a correct figure in the rendered version, but the value will be consumed incorrectly by users of the data, and any applicable calculation relationships in the XBRL will likely be incorrect as well. Filers need to understand what happens with values as entered. If you are relying on just the rendered version of the document, you are not assured of your ability to verify accuracy.
Another illustration is incorrect tag selection. As the SEC states in its Staff Observations-Summary of XBRL Information for Phase 3 Filers, “[c]arefully selecting the best tags is likely to be the greatest contributor to the quality of your XBRL submission.” Proper tag selection and proper structuring of those tags are probably the most important steps Merrill takes to make sure that XBRL files meet the needs of the company and the SEC. But there is much more to be done. Filers must adhere to the EDGAR Filer Manual rules and build a company taxonomy that mirrors the US GAAP Taxonomy as much as possible.
Experienced personnel such as Merrill staff provide the valuable knowledge transfer-through consulting and teaching-that a filer needs to verify that the XBRL is both accurate and telling the same story as the HTML EDGAR document. Overall, we perform many steps that focus on the quality of the XBRL information when we prepare and review XBRL files.
XBRL potholes are everywhere. We see many of the errors that the SEC has mentioned in its Staff Observations when we bring on a new client and review its previous filings. These errors include incorrect positive/negative signs, inaccurate tag selection, incomplete tagging, erroneous unit designation, unnecessary element extensions, inappropriate scaling of amounts, and botched calculations. In an example that shows how extreme some of these errors are, we recently saw a number reported in the XBRL file as $100,000,000,000 when it should have been $100,000. The mistake arose because the company was reporting other numbers in millions but failed to adjust for the lower amount, and the automatic addition of six extra zeros therefore inflated the figure to $100 billion. The company was unaware of the problem.
Other frequent errors, which may not be automatically detected by a software program, include:
- Improper axes and domains selected for the members that are on a specific axis. We recently reviewed a file that used the taxonomy element “Business Segments Axis” to classify categories of financing receivables. That was an improper axis for the items being disclosed. Given this construction error, there would be inefficiencies in the ability of software to provide a financial analyst with information related to the categories of financing receivables, including comparisons with other companies. In addition, the analyst would probably be receiving confusing information about the company's business segments. Most filers are apparently unaware of the axes and domains that are used to construct their data, since these do not render on the SEC website.
- Inconsistent tagging between text and tabular data. Another common error is inconsistent tagging for values that are displayed in the textual data versus the same information tagged in tabular presentations. Some filers segregate the textual disclosures from the tabular disclosures in the XBRL. This can result in unintentionally tagging the same values with different elements or dimensional contexts.
The most important feature a filer should understand is how amounts in the financial statements map to those in the taxonomy elements, including the underlying dimensional structure that supports the selected elements. Registrants need to have confidence that the files do not have the types of errors repeatedly mentioned by the SEC staff in its observations. It is not adequate to review just a rendering of the XBRL files, or to rely on software validation tools alone, to verify accuracy.
Many filers are unaware that their review approaches are sufficient to ensure that their files are accurate and fully conform to the SEC requirements. It bears repeating: Even if the software validation report shows no problems, do not assume that the XBRL files are prepared in accordance with the SEC rules. While software validation plays an important role in producing high-quality XBRL, it does not guarantee that the files are free of errors.
To be continued in the August 2013 issue of Dimensions.