Common Misperceptions About XBRL

As is often the case, I have gathered far more useful insights from experts that I can weave into a four-page article for our print magazine. The article, slated for the September issue of Business Finance, examines the short-term and (more compelling, I think) long-term impacts of XBRL as the SEC prepares to release its final rules on the financial reporting technology. As one source emphasized, "XBRL is far more than financial reporting technology."

Discussions with finance and accounting executives whose companies already have voluntarily adopted XBRL, consultants, software vendors, and other XBRL experts helped turn up other common misperceptions, including the following:

XBRL is new. Actually, it's been around for close to a decade, nearly as long as I've been writing about corporate finance matters. Many other countries have already adopted XBRL requirements. And even though many surveys indicate that U.S. finance and accounting professionals need to bone up on the topic, they (and their colleagues who possess a blend of finance and IT skills) may be much more familiar with the concept than they realize. "If you have multiple accounting systems, a BPM system or a BI system, you are essentially inventing your own XBRL today." says Phillip Moyer, CEO and president of EDGAR Online Inc., a business and financial information provider that has applied XBRL technology (mapping data tags to individual financial statement line items) to thousands of companies.

XBRL is XML. This represents one of the most common and troubling misconceptions, says BearingPoint XBRL Lead Brian Hankin. Some vendors out there believe that their software can process XBRL because it has an XML processor. "XBRL is XML on steroids," he adds.

XBRL is only for financial reporting. Not true; it can also be used to help finance functions implement a number of process and efficiency improvements related to regulatory filing, fraud detection, controls monitoring and continuous auditing.