There’s a very interesting debate going on over at Daniel Robert’s blog that began by considering the extra effort that will be required for footnote tagging but in the comment thread moved to consideration of the process of S.E.C. XBRL reporting. Here I’d like to draw attention to the focal point of where any process ‘savings’ are likely to be made.
As the blog post points out, a 2007 Journal of Accountancy article highlights an early adopter of XBRL reporting – United Technologies Corporation (UTC) – who clearly explain their current and anticipated quarterly 10-Q reporting process. The first point to reiterate is that producing a 10-Q has never been a push button process. Data is aggregated from a number of sources and must be collaboratively validated before being compiled into a report filing that combines both financial and non-financial data and is re-formatted for online submission.
The data sources are ERP systems and a range of other organizational systems. In large organizations, financial data is typically ‘staged’ within a consolidation reporting system and non-financial data staged within something else (e.g. a Word document in UTC’s case). Then all this data is combined together, and formatted and converted for submission to EDGAR.
Provisioning staging applications like consolidation systems generally depends on a pre-processing step called ETL – extract, transform and load. In the XBRL world, even if data was already tagged down in some ERP general ledgers using XBRL-GL, there’s still no way that all incoming data would be tagged. So tagging either becomes part of the ‘transform’ (i.e. pre-load) step of ETL or the acronym expanded to ‘ELTT’ to accommodate post-load tagging of untagged incoming data in the reporting application itself.
Now if you can cut a step out of this process by removing the need to stage data in both a consolidation reporting application and a Word document then this single-step submission staging should save time and effort and reduce the potential for error. But given that a new process requirement is introduced, XBRL tagging, some of that time will be clawed back by demands of the ‘enhanced’ process. Even so UTC estimated 145 hours of saved time or c.17%.
In this situation, the focal point for process savings becomes this single submission staging area – the reporting application that both gathers data from disparate feeder systems and prepares it for submission as a 10-Q. If this application is not fit-for-purpose then clearly any process savings will be eroded. That’s why it’s important that the reporting tool has been designed for the XBRL world. A world in which incoming data may already be XBRL-tagged, post-load tagging of non-XBRL data is efficiently managed and report output options are designed to make filing 10-Q submissions and complying with all aspects of the S.E.C. mandate as easy as possible. In other words what Rivet’s Crossfire was designed for. You can find out more here.
Tags: crossfire
