cfo.com

Print this article | Return to Article | Return to CFO.com

X Marks the Spot, for Errors

Early results indicate that filing financial statements in XBRL is far from simple.
Alix Stuart, CFO Magazine
October 1, 2009

Tim Kingston, manager of corporate reporting at Zimmer Holdings, thought he was as prepared as he could possibly be to meet the Securities and Exchange Commission's new XBRL requirements. Soon after the SEC mandated that large companies begin filing financial statements that include so-called interactive data tags this past summer, Kingston researched his options and decided to buy software that could address the task, rather than outsource the process to a financial printer.

As summer began, he worked with the vendor, EDGARfilings, to map the company's earlier financial statements to the current dictionary of XBRL tags, creating a template for the medical-device maker's second-quarter numbers as they became ready. By early August, he was on the phone with EDGARfilings daily to finalize the documents ahead of the deadline.

"Everything was running smoothly," recalls Kingston. Until, that is, the day before the filing. That's when an independent check of the company's XBRL tags by its financial printer turned up a bevy of technical errors — errors that would, in theory, lead the SEC to reject the document.

After a huddle with colleagues and Zimmer CFO James Crines, Kingston pushed EDGARfilings to help get the documents right, ultimately filing a near-perfect document, albeit more than a week later than he had intended. Lesson learned? Next quarter, the company may outsource the process to its financial printer, in part to eliminate incompatibility and inefficiencies, says Kingston.

Indeed, while a flood of consulting support combined with SEC lenience (motivated in part by technical difficulties on its end) has gotten some 400 companies through the first round of filing XBRL-coded documents, many have discovered it's not as easy as it may seem. A report by XBRL Cloud, which runs technical audits of XBRL documents, finds that about 70% of companies had some type of technical error in their filings, with several counting more than 100 such errors.

Details, Details
The process, meanwhile, will only get more complex next year, as the time-consuming task of putting detailed tags on prose such as footnotes becomes part of the requirement. In short, the first round has proven to be "a wake-up call that just because we're doing XBRL doesn't mean we're doing it right," says XBRL Cloud president Cliff Binstock.

XBRL holds a number of appealing promises, including the ability for financial analysts to more readily slice and dice companies' numbers, and the possibility for companies to more easily manipulate the data in their own disparate systems, perhaps making regulatory reporting of all types more efficient (see "Some Pain, but Plenty of Gain" at the end of this article).

As it stands now, though, most companies view the process of tagging their data with the XBRL codes as a compliance matter, and not a very important one at that. At the moment, there are few consequences to doing XBRL well or poorly. The documents don't need to be separately audited, and entail limited legal liability for at least the next three years. They are also not being used by any critical mass of equity or debt analysts, according to informal polling by XBRL US, the group that writes the XBRL codes.

After touting the technology informally for a number of years, and signing up some 140 companies as voluntary filers, the SEC made XBRL mandatory last year, in the twilight of former chairman Christopher Cox's reign. Large companies have been on the hook since July; over the next three years all public companies will be required to file XBRL-tagged financials.

The SEC did little to help the process by waiting until July 20 to release the final 2009 XBRL taxonomy, or dictionary of data tags — well past when companies (and software vendors) should have begun getting their arms around it. A series of updates to the EDGAR filing manual also made it difficult for software vendors to stay current.

Running Sideways
Software angst, in fact, has prompted many companies to cry uncle. Rob Blake, senior director of interactive services for financial printer Bowne, estimates that about 75% of its clients were planning to buy software and tag their own financial statements before the SEC proposed rules on the topic, but only 25% followed through, with the rest outsourcing the process. "It did surprise me how many people were running sideways at the end," says Blake, who helped start XBRL software vendor Rivet and led some XBRL work at the SEC.

Another major financial printer, RR Donnelley, reports that nearly 100% of its 141 clients required to report in XBRL last quarter chose to outsource the process to them. "Some clients bought software but then came to us anyway," says RR Donnelley executive vice president Craig Clay.

Companies that are sticking with self-tagging note that outsourcing doesn't come cheap. "Cost was a very significant key in our decision" to self-tag, says Fred Bleier, chief accounting officer at International Paper. Bowne, for example, charges $24,995 annually to cover XBRL filings, compared with less than $5,000 for most tagging-software packages. Most expect outsourcing to get even more expensive when detailed footnote tagging becomes part of the package, a process that most financial printers haven't yet put a price tag on.


However, constant revisions to the taxonomy can make the tagging process a full-time job for in-house staff, which has its own costs. Bleier, for example, believes he is saving money by having four people on his finance team handle the tagging, but says he is "leery" of code changes that may come while his staff tries to get a head start on footnotes. "If we get a good bit of [the footnote tagging] done between now and second quarter next year and [then] there [are] more changes, that would be a big bump in the road," he says.

There is plenty of room for errors, even aside from the technical ones, as one study by professors at North Carolina State University found. Eileen Taylor and co-authors Jon Bartley and Al Chen analyzed the 2006 10-Ks for 22 voluntary XBRL filers, checking the data-tagged version against HTML versions. They counted 121 instances in which a negative number was entered as a positive, or vice versa. There were 142 cases of missing items, and other items were duplicated 112 times. While much has evolved since then, Taylor says many such errors persist in the recent filings she has looked at. "Nobody's doing a great job," she says.

Can't Start Soon Enough
So what can finance executives do now to lessen the pain? "My recommendation is that people get involved as far in advance as practical," says Bleier, whose company also ran into last-minute software glitches despite months of preparation and a test filing last year.

One piece of good news is that "the software is improving every day," according to Neal Hannon, former director of financial-reporting technologies for the Financial Accounting Standards Board who is now consulting with software firms on XBRL applications with the Gilbane Group.

Coming down the pike are more features, like the ability to compare your company's tag choices with those of competitors. Longer term, software that can recognize word patterns in unstructured text may help speed the tagging of footnotes and other prose.

Regardless of which path a company chooses to get its data tagged, though, there is no escaping the responsibility of validating the data, as Zimmer discovered. Finance staffers must ultimately make sure that the XBRL tags match both the current taxonomy and the underlying 10-Q or 10-K before it goes off to the SEC, or risk rejection. A typical validation process might involve running a filing through the software's own checks and balances, then having a financial printer validate it independently before it goes to the SEC.

Unfortunately, while correct tagging solves one compliance problem, it may reveal a host of others. "The SEC will definitely use XBRL to discover non-XBRL problems more quickly," predicts Hannon. "The technology can help them spot a problem in a few days rather than a few months."

Alix Stuart is a senior writer at CFO.


Some Pain, but Plenty of Gain

Most finance executives accepted the Securities and Exchange Commission's mandate on XBRL with something of a groan, but not John Stantial, assistant controller at United Technologies Corp. (UTC). Not only was he glad for the mandate, he says, but "I would have been happier if it had happened five years ago." Since 2004, Stantial has been working to integrate XBRL into UTC's filings in hopes of more easily pulling data from disparate systems within the $58 billion conglomerate.

Thanks to a clear vision and an early start, UTC has evolved a system that uses Clarity FSR software to tag the data within the company's Hyperion financial-consolidation suite, which can then generate XBRL-coded filings, as opposed to spitting out a filing and then adding the XBRL tags as a last step, which is what most companies do. "If you view this exercise as nothing more than a governmental reporting requirement, you've really missed the boat," he says. Already, switching to a more bottoms-up approach has streamlined the company's reporting process, he says, and shaved 5% to 10% off the time it takes to compile a filing.

ERP vendors are also racing to make their products XBRL-friendly. Both SAP and Oracle have partnered with UBMatrix, an XBRL-tagging software firm, to offer clients XBRL tools (at an additional cost) that are compatible with their consolidation systems.

Few companies have followed UTC's model, however. Nonetheless, Stantial insists that XBRL can go "from being a necessary evil to being something that can benefit every company, but you need to make that transition in mind-set first." — A.S.




CFO Publishing Corporation 2009. All rights reserved.