The process of creating XBRL interactive data involves the mapping or “barcoding” of financial facts to standard or “generally accepted” codes. In the case of the final XBRL rule, the SEC requires issuers to match facts (i.e. numbers) appearing in financial statements and notes to a collection of adopted US GAAP codes. For example, “Gross Profit” would be mapped to the US GAAP code titled, “GrossProfit.” Through properly mapping financial facts to standard codes it becomes possible for computer programs to easily identify certain numbers, extract them from the document, and utilize them for summary reports and comparisons across similar companies.
In addition to mapping facts to codes the XBRL data must also describe how numbers within the reports add up. Once these calculation relationships have been established, XBRL will check the tagged facts against them to ensure there are no summation errors.
Issuers must evaluate their face financial statements and notes and schedules thereto and build a collection of codes and calculation relationships that accurately represent their accounting methodology. Once the collection of codes has been constructed and approved by the issuer’s accounting department, it can be used to construct and export XBRL interactive data as part of quarterly, annual, or transition reports and registration statements for submission to the SEC’s EDGAR system.
Any effort designed to address an issuer’s XBRL filing requirements should include accounting, SEC filing, and XBRL expertise. The participation of the issuer’s accounting department is critical in ensuring the correct codes are mapped to facts in the face financial statements and schedules and notes thereto. The filer’s filing agent needs to be aware of the additional steps and requirements added to the filing process and have an understanding as to how to resolve XBRL validation errors possibly generated by the EDGAR system. Finally, because XBRL can bring about issues not traditionally found in reporting, an XBRL resource should be developed and/or located externally to assist with any technical issues that may arise.
It's possible, but it will take anywhere between 200 - 300 hours to read through and develop an understanding of the US GAAP Taxonomy Preparers Guide, information needed to properly prepare XBRL documents for EDGAR filing. In addition, a software suite (or several software suites) will be required to allow the construction of a collection of company codes and the creation and validation of XBRL interactive data files for filing on EDGAR.
Most accounting software packages designed for small to medium sized companies currently do not offer XBRL export options. It is expected that with time such functionality will become more commonplace. Those that do support XBRL export options expect users to have a good understanding of what XBRL is and how documents should be properly prepared prior to export.
The steps involved in creating and proofing XBRL interactive data for EDGAR filing are not only different than those in place for preparing HTML and ASCII documents, but are more extensive and complex as well. In most cases the addition of XBRL interactive data in an EDGAR submission will result in a longer turnaround and increased cost.
Changes to numbers in the financial statements after a proof has been generated would involve adjusting both the HTML/ASCII file and the XBRL file. Similarly, the addition of a line item in a financial table would not only involve the updating of the HTML file and XBRL file containing the interactive data, but also the adjustment of the issuer’s core XBRL files. “Last minute” changes therefore could very well be time consuming and will likely result in delays not typically experienced with HTML/ASCII documents. To ensure a timely submission, issuers must finalize their financial statements several days prior to a given filing deadline allowing adequate time to prepare the necessary XBRL content.
A report containing the XBRL interactive data present in an EDGAR filing can be provided to an issuer for review and approval prior to submission. When proofing XBRL interactive data the emphasis should not be the presentation of the material in the report, but rather on the accuracy of the coding and completeness of the report. Most reports will not display the material in a form similar to the original face financial statements generated by the issuer’s accounting program or those submitted to EDGAR as part of an issuer’s 10-Q or 10-K in HTML format. The SEC comments on this issue in the staff observations dated December 13, 2011.
Accuracy of Coding
A report of the XBRL filing should be reviewed by the issuer to ensure the numbers present in the XBRL report are mapped to the correct US GAAP or company-specific codes. Coding errors may result in computer programs generating inaccurate or misleading comparisons and reports. For example, accidentally coding revenues as gross margin would result in XBRL analytical tools inaccurately reporting various earnings ratios.
Completeness of Report
A report of the XBRL filing should be reviewed by the issuer to ensure each number in the face financial statements is present. Numbers in parenthesis (i.e. shares authorized, par value, etc) should also be reviewed as in XBRL reporting they are pulled out of line item descriptions and coded individually.