Written by Bob Schneider     Posted February 23, 2007

Last week I discussed how the outlays companies made for Y2K and SOX yielded benefits they had not anticipated. Should there be an SEC mandate for XBRL financial reporting, I believe complying companies will enjoy similar, unexpected returns because (a) XBRL is gaining wider acceptance at the Federal level, and (b) governments and agencies overseas are increasingly adopting XBRL for reporting purposes.

Interactive Data Is Gaining at the Federal Level XBRL has friends in high places in the government. I have previously noted the enthusiasm of SEC Chairman Christopher Cox; but interactive data has boosters throughout the Federal system, including the Treasury and Labor departments. In an interview with GCN published this week, Richard Campbell, enterprise architect at the FDIC, cited both HUD and Interior as departments currently using XBRL. Mr. Campbell's own agency has been at the forefront of interactive data adoption: the FDIC's adoption of interactive data for banks' Call Reports has been widely heralded as a major achievement.

Critics may say that the FDIC experience often cited by XBRL proponents remains an isolated victory. But as XBRL adoption moves forward, more success stories will emerge. Just this month, Chairman Cox described how interactive data was instrumental in helping his agency uncover the backdating of stock options for which dozens of companies are now being investigated.

As described at Law.com, the SEC recently required Form 4 the form companies use to report exercises of stock options to be in interactive format. At the same time, the Commission issued new rules that required option rewards to be reported within two days of the grant. Chairman Cox stated: "Once real-time disclosure was combined with interactive data...we began to find clues that had previously gone undetected. That led directly to the discovery of what we now know were billions of dollars of backdated stock option awards."

As such success stories multiply, the reputation of interactive data for transparency and efficient analysis grows, and more Federal bodies will require that their reports be submitted in XBRL. Thus companies' initial investment in interactive data can be spread over more projects. The marginal cost of new mandates will continue to decline, as companies acquire the experience, employees, and tools to fulfill XBRL reporting requirements.

XBRL Is Making Headway Internationally Even though it began in the U.S., XBRL is not in any way considered an instrument of American financial imperialism. Indeed, the U.S. has been behind other nations in adopting it. XBRL is a truly international standard that is being implemented on six continents. The AccMan blog of Dennis Howlett recently cited an analysis by Jay Hammond that says the leading adopters of XBRL include Japan, China, India, Spain, and the Netherlands.

Spain is perhaps the most surprising name among the group. Howlett concludes that "Spain aspires to become the benchmark nation for the Spanish speaking Latin American world Spain is perceived as a technology laggard. Yet here we have a country not just leading the way, but opening up all sorts of opportunities for itself as a technology leader." Citing Hammond, Howlett writes that Spain's centralized XBRL taxonomy project "...aspires to include environmental and social performance as well as economic performance."

I am not asking readers to become gooey-eyed at the prospect of XBRL saving the whales. What I am suggesting is that the breadth of XBRL adoption promises to be extremely wide, both geographically and functionally. As US companies seek to comply with the information needs of overseas taxing authorities, financial agencies, interior ministries, stock exchanges indeed, the whole host of international regulatory bodies it will be more likely they will be making those filings in XBRL. Once again, their inaugural XBRL investment for training, software, staff, etc. will yield benefits down the road as they comply with regulations mandated overseas.

All of this discussion ignores the non-regulatory benefits XBRL is likely to produce for communicating with customers and suppliers, improving operational efficiency, and facilitating M&A. But if we just consider the regulatory arena alone, the cost/return equation on the initial XBRL investment from an SEC mandate for financial reporting will likely be better than it now appears.

Written by Bob Schneider      Posted February 16, 2007

Events this decade have been so dramatic that it's hard to recall it began with prospects of a Y2K meltdown. Billions of dollars were poured into correcting the ancient code that expressed years in overly economical double-digits. The Y2K effort was naturally focused on avoiding catastrophe and not on any ancillary benefits. But after January 1, 2000, came and went without major incident some charging the fears had been overblown, others that the huge Y2K investment had saved the day technology officers began to contemplate the resulting gains.

Inventory-taking of software and systems that was once done haphazardly, if at all, was standardized. Systems for communicating software issues, both within the organization and to customers and suppliers, were upgraded. Formal software audit policies were introduced. Rules for contingency and disaster planning were detailed and prescribed.

The return on Y2K investment grew dramatically in the wake of 9/11. When the terrorists attacked, the redundancy built into information systems in the event of a Y2K meltdown proved highly advantageous. The global banks headquartered in lower Manhattan were able to shift with relative ease to the backup systems that had been enhanced through Y2K outlays. The Northeast Blackout of 2003 provided additional evidence of the efficacy of Y2K expenditures, with the relatively rapid restoration of power in many areas because of Y2K capital investment.

Just as the country was recovering from 9/11, the series of business scandals symbolized by Enron came to the forefront. In the wake of corporate deceit, the Sarbanes-Oxley Act (SOX) was passed in 2002. In my post XBRL Dovetails Nicely with SOX's Surprising Benefits, I discussed the Harvard Business Review article that enumerated the unexpected gains from the law. These included strengthening the overall internal control environment and exploiting convergence opportunities from other regulatory requirements. Although I wouldn't declare that the view of SOX in Corporate America is now widely positive, I think it's fair to say that many organizations have become resigned to the law and are now focusing on ways to leverage their SOX investment.

Now CFOs may face another significant challenge: a mandate by the SEC that public companies file their financial reports in XBRL. Such a requirement would be far different in both scope and character than either Y2K or SOX. It would not be a response to an imminent threat of systems meltdown or to a loss of confidence due to corporate chicanery. Rather, it would be an effort to improve upon existing methods of financial reporting that, all things considered, have worked fairly well. And the resources expended would be far below those for Y2K and SOX.

Nevertheless, since more than a few firms will view the cost/benefit equation from an XBRL mandate to be mostly cost and little benefit, it's important to consider whether there are likely to be longer-term positives from their outlays for XBRL. In other words, do public firms have reason to believe that, like Y2K and SOX, they will be able to leverage their XBRL investment?

In the second part of this post, scheduled for publication on February 23, I will discuss why I think the return on complying with an SEC mandate for XBRL financial reporting may be better than many companies now believe.

Written by Bob Schneider     Posted February 9, 2007

The laying of transatlantic cable in the second half of the 19th century revolutionized communications between the US and Europe. But the resulting telegraphy could hardly be described as instant messaging. It was not until the 20th century that speeds reached even 120 words a minute. Moreover, cabling was extremely expensive. It cost a quarter to send a single word from New York to London in 1900, a lot of money back then.

To pack more information into a message, senders and receivers employed code dictionaries of phrases and other expressions. The sender would find a phrase with his intended meaning and include the accompanying code in his message. (For example, in one code book, caninero stood for "have ceased selling" one word standing for three.) The code message would be transmitted by the telegraph or cable company. The recipient would look up the code words in another copy of the same book or follow other procedures to find their meaning.

Thousands of code books were created. The most popular was the all-purpose ABC Code (which went through seven editions between 1873 and 1936). There were also books for specific industries and segments, with terms useful for a particular trade. Some books were sold to the general public; others were developed by individual firms for their own use and remained proprietary. The codes particularly the specialized codes arranged their phrases by topic, sometimes in tables, to save space and facilitate message coding. (If you'd like to know more about the code books, take a look at Jim Reeds's fine introduction, or at the material and extracts assembled by my friend John McVey at his site.)

I'm hesitant to compare 21st century XBRL with a 19th century technology. Still, I do see direct parallels. The code books are analogous to XBRL taxonomies, the vocabularies or dictionaries that provide the foundation for information exchange. The telegraph transmission can be compared to the instance document, a file that contains content structured in the XBRL language. Whoever deciphers the cable's meaning does the work of the XBRL reader, which can access, view, and analyze an instance document.

The levels of specificity reflected in code books from all-purpose ABC Code to, say, Acme Inc. Code also yield rough equivalents in the taxonomy hierarchy. If we consider XBRL for financial reporting alone, ABC Code corresponds to the Commercial and Industrial taxonomy for US GAAP. Industry code books are aligned with industry taxonomies, eg, that for oil and gas. The 19th century firm had its own company code book; the 21st century firm has its own company XBRL taxonomy.

Then as now, competition for "standards" existed. As John writes: "The codes competed on various mixes of convenience, depth and/or breadth, error-resistance, reputation of compiler, novel system, even naturalness of their expressions (for the so-called "verbatim" codes)." Old books and systems were discarded as better ones were created, while others remained to complement the new works. Today we see XBRL competing with other XML-based standards (RIXML, FIX, MDDL, etc.) for broad-based recognition and acceptance, but also at times working in collaboration.

I don't pretend that there are any great lessons in comparing highly elaborate XBRL with the relatively straightforward telegraph code book, which in the end are dissimilar communication tools, introduced in business and regulatory environments separated by 150 years. But I do think it helps to put the challenges XBRL faces in perspective. It informs us, once again, that technology adoption is a process, where competition and collaboration work in tandem to respond to user needs.

Written by Bob Schneider      Posted February 2, 2007

My favorite line of comedian Fran Leibowitz is "You know you're an adult when the phone rings and you hope it isn't for you."

Here's another telltale sign of adulthood: You realize the job you do isn't anything like what people think it is or what you yourself thought it would be.

Auditing is a prime example. Most first-year accounting majors would be surprised to learn that their first job out of school would be to help assure that financial statements are presented fairly. To the extent they know they'll have to work a while as auditors to get their CPAs, they probably figure they'll be looking to see if anybody has been stealing money from their clients. In other words, they'll be looking for fraud, which defined more precisely includes both the deliberate misrepresentation of financial statements as well as the improper use of company resources.

But for auditors, far from being their raison d'etre, fraud is a pain in the butt. Doctors don't like disease, and exterminators don't like vermin. But both recognize that they'd be out of a job if their respective nemeses were extinguished. Not so for auditors and fraud. With the exception of forensic auditing specialists, the external auditor would exist happily indeed, much more happily if fraud simply didn't exist.

Uncovering fraud while performing all the tasks of a financial audit -- including big-time frauds where management is on the swindle is really hard. At the same time, fraud creates enormous legal exposure for auditors. If even accounting majors think the independent auditor exists to find fraud, just imagine what the average juror believes. When the prosecutor asks "Where were the auditors?", their response that "Uncovering fraud is not our primary objective" is greeted with much skepticism.

The heads of the big audit networks addressed these concerns in their recent essay on their vision for the audit profession:

"There are limits to what auditors can reasonably uncover, given the limits inherent in today's audits. Specifically, unless companies or investors are willing to pay auditors to police all of a company's transactions, auditors are limited to using indirect means to ascertain whether fraud has occurred.These methods clearly are useful, indeed essential, to preventing and discovering fraud. But they are not foolproof, nor can they be expected to be. Hence, [an] expectations gap arises because many investors, policy makers and the media believe that the auditor's main function is to detect all fraud, and thus, where it materializes and auditors have failed to find it, the auditors are often presumed to be at fault. Given the inherent limitations of any outside party to discover the presence of fraud, the restrictions governing the methods auditors are allowed to use, and the cost constraints of the audit itself, this presumption is not aligned with the current auditing standards."

How XBRL Can Help
There is no way to eliminate entirely that "expectations gap." But I do think the widespread adoption of XBRL can go a long way to reducing it.

In his speech at the recent XBRL conference in Philadelphia, Ian Ball, CEO of the International Federation of Accountants, stated one of the direct benefits of XBRL for auditors: "Simple balance sheet statistical sampling efforts can be replaced by 100% validation routines or by deeper analysis of ledger-level data." If realized, this could be enormously important to auditors in both discovering fraud and ensuring external audiences they have done everything possible to uncover it.

Statistical sampling is essential to an auditing process that emphasizes gaining reasonable assurance at reasonable cost. But by necessity, only a small portion of all transactions are selected and reviewed, and so the possibility of fraud still looms. From a litigation standpoint, convincing jurors that auditors did their job when fraud existed but relatively few transactions were tested is a tough sell. Even if 100% validation is not achieved, expanding sample sizes and lowering materiality levels increases the chances that fraud will be discovered in the financial audit. To the extent 100% validation is possible, it will be a boon to the auditing profession.

"Deeper analysis of ledger-level data" would also yield huge benefits. The search for fraud is a hunt for the exceptional, and not in the good sense. It's finding some piece of evidence somewhere that something isn't kosher. Numbers and ratios that look fine for the entire company for the full year often compiled from disparate accounting systems, with manual data re-entry and sometimes poorly controlled spreadsheets -- can mask inconsistencies in the bowels of the organization for shorter periods of time. The introduction of XBRL as a single data standard for the firm enables the analysis of large data pools from deeply drilled levels at low cost, making the search for anomalies much more efficient.

The best solution to fraud, of course, is to make it hard to pull off. XBRL has substantial potential to improve internal control and thereby reduce fraud risk. The seamlessness of XBRL affords full-scale integration of company data with limited human intervention. Business rules both from the perspective of regulating the activities of employees as well as the constraints on the information entered into database systems can be more easily adopted and enforced. Because tagged data allows searches to be done much more quickly, control procedures that were formerly onerous can be instituted and performed without significant cost to the organization.

Finally, I think the benefits of XBRL-GL as a business reporting language as opposed to a mere financial reporting language (as discussed by David vun Kannon in his recent post on this blog) will be significant. Non-financial data -- such as whether and when an employee has taken vacation -- can be crucial in both detecting and preventing fraud. If this information can be easily expressed and manipulated with the financial data, analysis of employee activities will be enhanced, and discrepancies will be more visible. These advantages will be even more prominent if XBRL adoption becomes worldwide throughout industry, so that combined companies that formerly faced long lag times in merging data systems quickly integrate their data in the XBRL-GL standard.