This is the second installment of a three-part interview. The first part contains questions 1 through 5.

6.  XBRL has not captured the imagination of security analysts and other investment professionals as some had hoped. Why do you think investors have been relatively indifferent about interactive data? As the SEC’s XBRL adoption expands to more companies, do you see that situation changing?

XBRL shouldn’t capture the imagination of analysts, investment professionals, and investors. XBRL isn’t what’s important to them; the data is. Many investors don’t realize it, but they’ve been using XBRL or similar standards for years. The difference is that in the past, third parties have been standardizing and tagging company data, not the companies themselves. The main thing that changed with the public company XBRL mandate is that companies are now responsible for making sure that the data investors actually use is accurate. Companies spend so much money making sure their disclosures are as accurate and complete as possible that it would have been a shame to continue to let all that hard work be subject to third party interpretation, normalization, and potential over-simplification. We’ve all seen what happens in a game of “telephone.” There’s a reason hearsay is inadmissible in court. It may not “capture the imagination,” but eliminating an entire level of hearsay in the world’s leading capital markets has the potential to be a pretty big deal.

What I see changing isn’t necessarily respect for the data standard among non-technical users, although like all successful data standards, the standard must become more useful over time to avoid becoming obsolete. What I see changing is respect for the professionals responsible for preparing the data. Until I became involved in the XBRL project, I didn’t understand the full extent to which the accounting profession is vital to healthy markets. You can see that in the fact that while accountants and auditors were using SOX to improve public company reporting, financial engineers were working to avoid accountants by relying on non-GAAP models for ABS. With XBRL, the accounting profession’s work is transmitted more accurately and more fully to more people who can make more effective use of that work. I suspect that’s one reason the AICPA was such a strong supporter of XBRL from the outset.

7.  In a recent blog, you posited the idea that “NIEM is to XBRL as United States customary units are to the Metric System.” Could you expand on that idea and explain more fully how you see the relative contribution of NIEM and XBRL in implementing data standards for Federal government activities?

The main point I hope readers took from my post is that global standards are more efficient than national standards. NIEM is a domestic U.S. standard. Yet we live in a global economy. It’s just a no-brainer to me that when local standards and global standards are both available, you go with the global standard unless there’s a compelling reason for parochialism. That’s why the G-20 leadership supports global accounting standards. Heck, we almost lost Winston Churchill before WWII because he was accustomed to a parochial standard and looked the wrong way when crossing Fifth Avenue in New York City. Who knows how much we’ve lost as a result of parochial standards?

With respect to NIEM, why should one nation’s government care if its information standards are compatible with other governments’ standards? Well, two reasons are terrorism and financial crime. They’re both global challenges. At the SEC and at the House Homeland Security Committee before that, some of our greatest challenges were facilitating international cooperation among law enforcement and intelligence agencies to combat terrorism and financial crime.

Making NIEM global, through collaboration with XBRL standards, could significantly improve how law enforcement officials work with each other across borders. XBRL’s validation capability could also be helpful in the law enforcement domain. With all the smart people working on both standards, there’s no reason they can’t become fully interoperable open standards – or unified into a single standard. I don’t think anyone knows how NIEM and XBRL will ultimately work together, but that’s what makes working on data standards interesting – someone will always find better ways to make standards work.

8.  In a post describing health information technology standards, you suggest that the SEC’s adoption of XBRL could be used as a model for adopting standards in other industries. In this respect, what elements of the SEC implementation do you find worthy of emulation?

The same leadership gap exists with respect to medical records that existed before the SEC moved forward with XBRL. No perfect standard exists in any domain. After the SEC chose XBRL, much hard work remained to make it capable of supporting high quality GAAP reporting. In medicine, the plethora of incompatible proprietary standards is much worse than in financial reporting. Nevertheless, if patients are to enjoy the benefits of medical records created, transmitted, and used according to open industry standards, someone must overcome the proprietary interests and provide the leadership to choose and develop an open and effective high-quality standard.

In learning, grades can mean different things to different schools and different people. Unique students are taught in identical ways on agricultural calendars in the information age. Someone someday will develop open standards to support a system in which unique students enjoy custom lessons to meet their educational needs and measure their progress. Extensibility, dimensions, presentation layers and more could be big parts of such a standard.

In the end, recognizing the unique worth of every individual – in education, medicine, business, and every sector – requires robust methods to assemble, store, and use complex information. XBRL blazed the trail. I’ve frequently noted that if we could find a way to convert U.S. GAAP to a computer language – when no one is even sure how many tens of thousands of pages of literature comprise the standard – other challenges must be easy in comparison. Other industries have enormous amounts to learn from the XBRL experience.

[Disclosure: I’m the Chief Strategy Officer for CLOUD, Inc., the Consortium for Local Ownership and Use of Data, a new non-profit organization exploring the potential of cross-industry data standards for personal information that would give individual users more control over their own information.]

9.  In a post on your blog about a bill to make XBRL the data standard for disclosure to the US government, you wrote “Bringing labor-saving technology to banking and securities regulation is one thing, but making L.A.’s [legislative assistants] on the Hill redundant? What hath sunlight wrought?” Isn’t it possible, however, that XBRL will increase the demand for analysts, because analysis will be easier to do?

As a former L.A., I certainly hope XBRL makes analysis easier and boosts demand! Perhaps I was a bit facetious. The title of Clay Shirky’s book, “Here Comes Everybody,” says a lot. The nice thing about democracy is that we all have something to contribute, and the more high quality information we have – Chris Anderson’s “long tail” of information – the more we can contribute and the less time we waste sorting information that’s not useful. Too often, the toughest part of quality analysis is collecting the data to analyze. Making data available to the world by supporting open standards and open software to analyze that data can’t help but support smarter decisions.

Freerisk.org and Wikinvest are just two examples of how more accessible data can make analysis faster and better, if not easier. Having faster and better data supports deeper thinking about how to analyze the data. And thinking is hard – so I’m not so sure about “easier.” But by reducing the cost of analysis, XBRL pushes the supply curve of analysis to the right – meaning it intersects the demand curve at a point where there’s more analysis in the market at a lower price. By increasing the quality of analysis – less garbage in means less garbage out – the markets subject to analysis should work more efficiently, resulting in more capital being allocated to more productive uses – a virtuous circle.

10.    What XBRL developments in other countries do you find noteworthy, and what can the US learn from them?

What I find most noteworthy are the many and flexible uses for XBRL. The greatest lesson the U.S. might learn could be, “XBRL – it’s not just for GAAP anymore.” Australia’s Standard Business Reporting project is impressive, as is the work to standardize corporate actions XBRL US is doing with the International Organization for Standardization (ISO), the Society for Worldwide Interbank Financial Telecommunication (SWIFT), and the Depository Trust & Clearing Corporation (DTCC). Using XBRL for corporate actions on a global basis could be like moving from vinyl records to mp3’s. By cutting overhead costs – time costs and money costs – equity financing has the potential to make gains relative to debt financing. And that means stronger and more efficient global capital markets.

Moreover, smoother global accounting, as the International Financial Reporting Standards taxonomy continues to improve, smoother global trading, and a more standardized corporate actions process all mean that more capital can be allocated to its highest and best uses more quickly. More open and competitive global capital markets simply mean that billions of people will be better off.
 

This is the first installment of a three-part interview.

1. You recently discussed the role XBRL can play in helping to restore the asset-backed securities (ABS) market. Could you explain what benefits XBRL would bring that ASCII and HTML documents do not?

That’s a timely question. The most important near-term benefit would be exploiting XBRL’s off-the-shelf capability to support effective disclosure standardization for ABS. Longer term, I think the “faster, better, cheaper” advantages that SEC Chief Accountant Don Nicolaisen foresaw in the GAAP arena would apply in the ABS arena, as would XBRL’s disclosure maintenance capability.

With respect to the implementation process, it’s true that regulators or an industry consortium could sit down and choose standard ASCII or HTML or Excel column headings or row labels for most of the important information about ABS. In fact, they tried to do so in the run-up to the crisis, but it was a slow process and has yet to result in a fair and efficient market for ABS.

On the other hand, the open process of creating XBRL financial taxonomies in the U.S. proved extraordinarily effective. Once the technical process was underway, I was astonished by the speed, quality, and openness of the XBRL US project. White House adviser Beth Noveck wrote a book called Wiki Government about crowd sourcing patent application research. Well, the effectiveness with which XBRL US crowd sourced the GAAP taxonomy deserves its own book. Your recent interview with the CEO of XBRL Australia reflects my experience in the U.S.: The technology was simple; the politics were the complex part. We couldn’t crowd source the SEC implementation rule, but XBRL US transcended all of the typical politics associated with U.S. GAAP by crowd sourcing the taxonomy.

In addition to the process advantages, there are, of course, myriad technical reasons XBRL is superior to ASCII, HTML, Excel, or any other open or proprietary standard. Extensibility is a big advantage, as is the ability to observe the use of extensions and to create and update standard tags over time – without requiring users to buy new software.

As we’ve seen with ABS, keeping disclosure regulation up-to-date with financial innovation is critical. Over the past decade, one reason capital flowed disproportionately to ABS relative to public companies is because regulators used proven manual systems to keep GAAP up to date. SOX was expensive. It helped prevent more Enron’s and WorldCom’s, but at the same time, it drove capital toward non-GAAP investments. Despite Reg. AB, which was generally a codification of many years of asset-backed securitization legal practice, ABS financial practices continued to evolve, contributing to both the housing bubble and to the growth of multi-layered complex securities on top of basic ABS.

Non-standard ABS reporting made it difficult to see the real risk presented by ABS and by derivatives built on top of ABS. ABS, because they didn’t create human drama or present business strategy questions like public companies do, got less attention than their valuations might have merited were the information available in a larger, more transparent, more liquid market. XBRL won’t bring the excitement of boardroom fights, hostile takeovers, or new consumer products to ABS. But to the extent XBRL for ABS helps investors understand basic facts about the instruments they’re being offered, it’s analogous to GAAP for public companies.

Thanks to computers – and thanks to the fact that ABS are considerably less complex than public companies – technology that took decades to develop for GAAP is already available for ABS. The SEC has plenty of authority to mandate disclosure for securities, which are simply investments of money in common enterprise for profit derived from the efforts of others. The questions are how fast regulators can understand XBRL’s capabilities to enhance transparency and how the SEC can navigate the regulatory minefield set by those whose oxen would be gored by transparency.

2.  Part of your work at the SEC was to help mandate the use of XBRL for public companies, mutual funds, and credit ratings agencies. Are you convinced that XBRL implementations at the national level will always require mandates? Or do you see a path for voluntary adoption to be successful?

The "chicken and egg" metaphor is hackneyed but nonetheless applicable: People only want to use a standard when adoption is sufficient to make the standard cost effective. While more than 100 public companies found it cost effective to participate in the SEC’s voluntary filing program, the ultimate information users – investors – required much greater adoption rates to make XBRL worthwhile. I don’t like where this metaphor is going, but effectively we had to force companies to lay eggs. Fortunately, they’ve been AAA extra large so far. Future implementations with lower adoption hurdles may not require mandates.

One reason to support XBRL adoption was to empower independent auditors to provide faster, better, and less expensive assurance by efficiently combining integrated software tools with professional judgment to create more reliable financial statements. If investors in private companies become accustomed to XBRL-quality data from public companies, perhaps they’ll demand similar information from private companies, where more highly-concentrated investors typically have more leverage over management. It certainly makes sense for private companies hoping to go public within a few years to start using XBRL well in advance to get ready for a fast and efficient IPO.

Moreover, with fixed costs for public companies for GAAP XBRL implementation, the cost to expand XBRL to other applications becomes mainly marginal. With the most complex data set – U.S. GAAP – out of the way, implementing the same or similar technology to automate other parts of the business information supply chain is more manageable. For example, XBRL GL looks much more attractive. Someday, a supermarket will scan the UPC bar code on a can of tomatoes and the dollar of revenue will end up in a 10-K without any human intervention except to monitor the systems that ensure straight-through processing.

If the U.S. is to remain competitive in the world economy, we have no choice but to improve efficiency by automating business processes. Much of that work not only can be voluntary – it must be voluntary because it’s the consequence of competition among businesses. XBRL is poised to win its share of competitions. A nice voluntary step, for example, might be XBRL support from Google’s Data Liberation team. With Google and other market participants throwing huge support behind open standards, XBRL will have to repeatedly prove its capabilities in the years to come.

3.  An argument has been made that financial regulators like the SEC primarily adopt XBRL to help their own analysts do their job more efficiently, and the needs of investors are a secondary consideration. To what extent do you think that argument has validity?

In my three-and-one-half years at the SEC, I never saw any air at all between the interests of investors and the interests of the Commissioners and staff. People at the SEC might sincerely disagree about the best ways to help investors, but everyone believed their primary mission was to help investors. The nice thing about XBRL is that it can help both government and private analysts do their jobs better.

It’s true that SEC analysts look for civil liability more often, while private analysts mostly look for investment opportunities, but there’s significant overlap. Either type of analyst is likely to consider whether a company has accurately disclosed all material information and either is likely to act on their conclusion. A private analyst decides to invest or not; an SEC analyst could call a company, issue a comment letter, or consult with the Division of Enforcement. While it could be a big mistake to trust a company just because the SEC hasn’t sued it, it’s also very clear that the faster and better the SEC can do its job, the less likely issuers can get away with fudging the facts. The roles of the SEC experts and private analysts are highly complementary to each other – not contentious.

Because so much money is at stake, and because resources for technology at the SEC are limited, I expect the private sector, not the SEC, to continue to lead the way in using XBRL. The SEC has considerable work to do to use XBRL to support more efficient compliance and surveillance. And because the legal environment in which the SEC itself works is itself enormously complex, the constraints won’t be technology. The SEC’s constraints will be legal and policy constraints.

What sort of data discrepancies are legally sufficient to justify imposing costs on public company investors to respond to an SEC investigation? How does one use technology to differentiate among skillful, lucky, and corrupt trading to show cause for a subpoena? Compared to questions like these, diversified investing (perhaps using XBRL to differentiate asset classes and industries and to identify different but potentially correlated investments) is easy.

4.  How do you think XBRL adoption by the SEC is proceeding? Do the issues described in the observations of SEC staff  on the statements filed thus far signal substantial problems? Or are they about what you had expected, or even relatively minor?

By all accounts, adoption is going well. The staff observations are informative. The first concern on the list relates to rendering, which is somewhat encouraging given that rendering isn’t particularly relevant to XBRL’s main purpose. After all, if you want the benefit of thousands of years of experience of putting ink on paper in a visually appealing way, you can still look at the dead tree format financial statements.

I also find it encouraging that the staff is urging filers to use standard elements. But that’s not a surprise either, since the use of standard elements helps investors make comparisons among companies and of performance over time. I expect the staff comments will be particularly helpful as the U.S. GAAP taxonomy is updated. As the taxonomy and the newly codified edition of U.S. GAAP become fully interoperable, tools using XBRL should make it easier for accountants and investors alike to visualize the importance of high quality accounting.

The really neat thing is that, before XBRL, the SEC found it difficult or impossible to hold third party data taggers accountable for the changes to GAAP in the normalization process. Now the SEC has tools to understand not only the official company reports but to understand how investors use those reports. The line of accountability, from companies to investors and the SEC, is much more direct. So is the feedback loop for GAAP itself. It will be interesting to watch how data about the use of GAAP is used to improve GAAP.

5.  At least in public, Mary Schapiro, the current Chairman of the SEC, has not been as outspoken as her predecessor, Chris Cox, on the importance of implementing XBRL for financial reporting. What consequences does this have for XBRL adoption at the agency? At this stage, with a final XBRL rule in place and adoption proceeding according to schedule, does commitment at the top of the agency make much of a difference?

To be fair, Chairman Schapiro has had quite a bit on her plate the past 10 months. And during his final year in office, Chairman Cox was extraordinarily busy dealing with the crisis of opacity via proprietary financial instruments, so he couldn’t spend as much time advocating transparency via open technology as he did early in his tenure. Fortunately, he identified XBRL as a priority very early. His experience with capital markets and technology dating to his service in President Reagan’s White House and earlier made XBRL a natural priority as soon as SEC technology director Corey Booth and the SEC’s first XBRL expert, Jeff Naumann, briefed him. Getting the process started early made it possible to finish with approval of the final public company rule in December 2008.

The most important time for the SEC to speak out for XBRL was during the work to develop the rules. With the roadmap now in place, there’s no reason for the Commission to be a backseat driver. What’s most important is for the Commission to support the staff’s work to make sure the SEC’s XBRL capabilities keep up with innovation in the private sector.

There’s always a place for leadership when it comes to transparency. Fair, fast, and efficient disclosure of asset-backed securities won’t happen without leadership from the top. I hope Chairman Schapiro and the rest of the Commission leverage the success of the GAAP and other XBRL programs to make ABS disclosure fairer, faster, and more efficient.
 

His comments are only his personal views, and do not represent those of the SBR program, PwC, or anyone connected with the SBR program.

1. What is Standard Business Reporting? What role does XBRL play in SBR? Is it possible to have SBR without XBRL, or are the two inextricably woven together?

SBR is a much broader concept of government agencies collaborating to improve business to government reporting. It could theoretically exist without XBRL, but the plain fact is that it could have occurred decades ago if that were the case. XBRL facilitates SBR by removing two significant roadblocks to inter-agency cooperation: (1) the need to agree on terminology between agencies and between business and government; and (2) the need to agree on the classification of things between these parties.

Obtaining agreement between government agencies on anything is a substantial task, so the less such agreements are needed, the greater the chance of success. The use of jargon is a natural human evolution in any economic activity, so it is counterproductive to try to eliminate it. Jargon is created to facilitate understanding, and XBRL taxonomies are likewise engineered to do the same thing. Allowing data concepts to be defined by many different references, each tailored to a specific audience, helps people understand how to use computers to share information. This runs counter to traditional IT thinking that dictates that every concept must be uniquely defined and everyone needs to agree on the definition.

XBRL says that you only need to agree that the concept is uniquely identified (so a computer can deal with it) and the people are free to use whatever human language suits them to describe it.

2. The SBR Conference 2009 included key figures from both the Australia and Netherlands SBR programs, as well as XBRL experts like Mike Willis. Do you foresee the formation of an international organization, perhaps along the lines of XBRL International, to facilitate adoption of Standard Business Reporting?

I would like to see that happen because it makes sense. SBR is a concept that is applicable to many governments and the infrastructure needed to implement it is common.

Little is gained by going it alone and repeatedly reinventing the wheel. Moreover, every new government that takes it on learns from those who went before and does it better, allowing the earlier implementations to evolve as well.

3. SBR implementations are currently being pursued in Netherlands, New Zealand, and Singapore. But the most ambitious adoption, beginning in July 2010, will be in Australia. Led by the Treasury, it will include the Australia Prudential Regulation Authority, the country’s Securities and Investments Commission, Australia’s taxation office, and the state and territory government revenue offices.
.
What factors do you see in Australia’s political and business environments that made it particularly hospitable for an SBR implementation on such a broad scale?

Reducing reporting burden is a common theme with governments around the world and has been for a while now. Economic downturns also bring the focus back to costs, and SBR is mostly about reducing cost in an area that adds little to business objectives. Not insignificantly, the Netherlands experience took much of the bravery out of the decision for Australia.

The key in both countries was political will. The endorsement and public support of a key political sponsor is essential. The technology is simple – the politics are highly complex.

4. As expansive as the planned adoption of SBR in Australia is, it is still primarily confined to fiscal and securities regulation functions. Longer term, do you see SBR being adopted by the Australian government and states in diverse areas like housing and law enforcement? What are the roadblocks to more widespread usage in government?

The biggest roadblock to government usage is probably government itself. There is a lot of talk about expanding the SBR approach into other areas, and this makes a lot of common sense – the problems it solves are common to most areas of information exchange. However, there is an enormous investment in the status quo. Many in powerful positions are huge beneficiaries of inefficiency and shifting the mindset is really hard, especially when very few have been exposed to the ways things CAN be done, rather than the ways things are done.

People who advise government have a vested interest in maximizing their time (and chargeable hours) in solving government’s problems, so efficiency and speed are often sacrificed to self interest. Proprietary solutions lock in future revenue streams for the provider that solutions like SBR would otherwise open up to competition through their use of open standards. As a new player, SBR-based solutions have a long way to go to break down long-established and well-financed barriers.

5. In a recent post on this blog, Nils-Bro Müller of XBRL Denmark wrote, even though XBRL’s benefits are well known, "Nobody seems to file in XBRL before it is mandatory to do so." However, SBR adoption in Australia, beginning in July 2010, will be on a voluntary basis. Are you concerned that Australia "will build SBR and no one will come"?

There is serious doubt as to whether SBR will achieve its target implementation rate without a mandate. The software vendors have long been asking for a mandate so they have certainty of a market for the functionality, but the SBR Program has resisted this.

One “problem” is that the reporting burden imposed by government is not that bad. While several hours of wasted time per quarter certainly adds up to a large amount of wasted time across the whole economy, it does not add up to a lot of wasted value. Small business people do not value their own time the way economists and consultants do, so they are unprepared to pay for software that gives them this time back.

Also, the government burden is only part of the reporting cycle in some cases and so automating only a part of the process does not create the efficiencies business is looking for. As soon as a manual step is introduced anywhere in the chain, the bulk of the benefits are lost.

I hope that enough vendors are encouraged to get into the market with XBRL-aware functionality that does more than just convert the existing output into XBRL format. Hopefully they will “see the light” and begin to use XBRL to make the entire process more efficient. Other uses (like online real time loan approvals) can then be offered that do resonate with the marketplace and thus kick off a virtuous cycle of adoption and benefits realization.

Three years ago keeping up with developments in the XBRL world was fairly simple: create a Google Alert for keyword XBRL, do periodic searches in a couple of engines, and sign up for daily digests from the XBRL Public Yahoo group.

Social media’s emergence, along with the creation of new XBRL-related blogs and websites, has made the XBRL conversation much richer, but it has also made it more difficult to track. In addition to the microblogging site Twitter, which generates a continuous stream of XBRL info and chat, there are XBRL groups in social media services like LinkedIn and Facebook, and several multi-purpose XBRL sites and aggregators — including XBRLSpy, XBRLBlog, and XBRL Network — have been inaugurated or upgraded. Although a little diminished by all the competition, the XBRL Public group remains alive and well.

Among these innovations, the most important has been Twitter. I now continually monitor Twitter Search results for XBRL because most XBRL-related blog posts, articles, events, and the like get mentioned here in some way. Occasionally, however, something noteworthy — like an interesting thread on the XBRL Public group — does go unnoticed, so I still haven’t abandoned any of the search methods I used three years ago.

What’s more, the 140-character-or-less tweet suffices to alert you to what’s happening in the XBRL world, but as a forum for developing XBRL themes and debating ideas, it has its limitations.

For example, recently, in response to CFO.com’s somewhat mixed appraisal of XBRL, a quick-witted observer tweeted “Vendors 1 | Everyone else 0.” It was the perfect tweet: pithy, clever, penetrating. It also seemed worthy of a detailed rejoinder, though, to dispute the notion that XBRL vendors were the primary drivers for the adoption of a data standard that now has been embraced for financial reporting by most major nations. But such a response would have taken more than 140 characters, and in the Twitter environment it also would have been unseemly and maybe unfair. After all, a tweet like “Vendors 1 | Everyone else 0” was just an imaginative quip on the topic of the moment, not a sweeping indictment of the XBRL movement. (Or was it?…)

My real concern about Twitter, however, is that its immediacy and brevity will lead to more tweets and fewer articles, blog posts, and blog comments. Twitter is fine for providing a link to an Internet resource or sharing a sweet bon mot, but it’s not a venue for sustained argument and debate.

Turning to Facebook, the other social media outlet that has made a huge splash, I have to admit I still don’t get it. I can’t comprehend a service whose taxonomy classifies my niece, college roommate, and business acquaintances all as “friends,” nor can I contemplate a conversation that simultaneously would be appropriate to all of them.

Facebook does have groups for those with similar interests, however, and currently there are a couple for XBRL; the main one has about only 50 members, and it’s fairly inactive.

In contrast, LinkedIn has numerous XBRL groups. Several have more than a hundred members, and some have as few as three. There’s some good stuff here. A few months ago, Dan Roberts published a short post on LinkedIn’s XBRL Matters group. Like Dan’s contributions to this blog, it was filled with interesting insights on relevant topics and themes: SEC Commissioner Mary Schapiro’s “not the picture of enthusiasm” comments on interactive data; XBRL as “background, infrastructure” that could be “better served by [the SEC] taking it off the front page,” and so forth.

All the same, I wonder how many people who would be interested in Dan’s post got to see it. While the XBRL Matters group does include many of the top names in the XBRL field, it still has no more than 200 members. And while Google does a good job of indexing LinkedIn profiles, I don’t see much evidence that it indexes LinkedIn group posts with the same efficiency.

Google also doesn’t seem to index messages of the XBRL Public group on Yahoo. (To be fair, Yahoo itself doesn’t seem to make much of an effort.) That’s a shame, because this group shows the XBRL community at its best. If you post a question, you’ll find the likes of Charlie Hoffman, Walter Hamscher, and Hugh Wallis answering it. Sure, if your query is “Can anybody here tell me what XBRL is?” you will be quickly and unceremoniously dispatched. But everyone who posts comments of import is treated with courtesy, and there continue to be some great debates. (One quibble: participants often aren’t fastidious about clipping quoted text, which makes it cumbersome to read a daily digest with a long thread.)

As you can see, there’s no shortage of XBRL venues in which to learn about XBRL and make your voice heard. But is the XBRL community best served by this “let a hundred flowers bloom” environment? I’m not sure.

Certainly different platforms are suitable for different users and purposes, and the variety is mostly welcome. But as I’ve indicated, I’m worried that, (1) the appeal of publishing real-time one-liners in Twitter will displace more detailed commentary; (2) the proliferation of groups and forums makes users wonder where to contribute; and (3) a lot of good content isn’t being seen because it’s not being indexed.

With the speed at which the Internet proceeds, however, my suspicion is that these concerns already are being addressed, and solutions and alternatives won’t take long to appear.

Nils-Bro Müller is Senior Advisor at the Danish Commerce and Companies Agency (DCCA), where he is responsible for the Danish XBRL solution. He has been working with XBRL since 2005 and is on the board of XBRL Denmark.

Denmark, where XBRL will be mandatory for company reports in 2011, has been making significant progress toward adopting XBRL since it became an Established Jurisdiction in November 2007. Starting in March 2008, small- and medium-size companies have been able to submit full annual reports in XBRL to the DCCA, the official registrar for Danish companies. As well, the submission taxonomy encompasses tagging for transmitting data to the Danish tax authorities and Statistics Denmark. All companies need to do is submit their data to the DCCA once yearly in XBRL format; the DCCA segregates and processes the document’s data and re-transmits it to other relevant public agencies. A company’s accountants can upload instance documents to the DCCA portal from their own computer; they also can use a Web service that delivers an instance directly to the DCCA’s backend.

One of the DCCA’s main objectives in publishing these reports is ensuring that their display and presentation be exactly the same as when they were signed at a company’s general assembly (stockholders) meeting. Therefore companies (or their accountants) choose a style sheet to be uploaded with the XBRL instance document. DCCA has developed a default style sheet that can handle the “look” of company accounts’ annual filing, which we expect many firms will use, but we can accept any PDF style sheet that the company or its accountants choose. We publish both PDF and XBRL versions of each financial statement, and an Excel version can be chosen as well.

Our XBRL implementation is based on the same software as that used for the Spain’s national banks’ XBRL solution. This platform originally was developed by Software AG in Spain, but DCCA converted this to run on a Linux platform. The application front-end and enterprise service bus (ESB) are standard JBoss software, which we use in many of our applications.

Our taxonomy is approximately 2,900 elements and includes both Danish and English text. Currently it covers what are classified in Denmark as Class B companies, which represent approximately 90% of all Danish companies. The taxonomy is based on the EU’s accounting directives Nos. 4 and 7, which prescribe P&L and balance sheet, as well as generally accepted accounting principles for Danish small companies (mainly for the notes to the statements). The taxonomy encompasses a full annual report, containing the following sections: statement by the board of executives and board of directors, independent auditor’s report, executive report, accounting policies, profit and loss, balance sheet, and notes.

Our solution was introduced because we believe companies, the financial sector, and the public sector will benefit from significant cost savings when XBRL is used for both internal and external reporting. A current problem is that companies and auditors aren’t yet ready or motivated to use XBRL, nor are systems in place to create instance documents. As a result, thus far we have received a relatively few 250 reports. This paucity of submissions is typical of other countries where XBRL filing is merely voluntary, however. Even though the benefits are well known, nobody seems to file in XBRL before it is mandatory to do so.

This is the paradox — that XBRL’s benefits are manifest, but companies won’t adopt it until they have to — that the international XBRL community must contend with. In my view, we’re currently ignoring that reality. Instead, we praise XBRL and all its benefits in well-worn phases each time we meet at international XBRL conferences.

At any rate, you are welcome to visit our XBRL portal, which is called DRP (digital reporting platform). Unfortunately we only have a Danish version at the moment, and you need a Danish certificate (OCES certifikat) before you can log in. But if you can, have a look.
 

Kurt Cagle is the managing editor of XML Today and a frequent commentator on XML-related issues. You can follow him on Twitter at @kurt_cagle

The specification space has become fairly busy lately as a new (well, actually, fairly old but resurgent) standard is now beginning to make waves outside of a fairly narrow domain. The US National Information Exchange Model (NIEM) has been in development since 2005, but with the new administration and a move toward increased modernization in the IT communication infrastructure of the executive branch, NIEM has definitely entered into the limelight.

NIEM isn’t a single XML standard. Rather, much like XBRL, it is a framework for developing XML standards for use within the Federal Enterprise Architecture (FEA) that promotes a schema repository model coupled with significant re-use of XML component documents. Originally emerging as part of the Global Justice XML Data Model, NIEM is a joint effort among the Department of Justice, the Department of Homeland Security, and the Office of Justice Projects (essentially an R&D agency closely aligned with the DoJ). NIEM Information Exchange Package Documents (IEPDs) are zipped collections of schemas and instance for specific data object models from emergency response reports to arrest warrants.

NIEM-based models have been quietly making their way through both the Federal government and, largely on the strength of the judicial and emergency management schemas, are now in use with all fifty states as well, with NIEM-related projects being considered in Canada. What’s more, as the data model proves itself, it has garnered interest in areas well outside of law enforcement, including education, marine provisioning, inventory management, and, yes, accounting. The Office of Management and Budget (OMB), the executive branch’s primary accounting arm, is now actively promoting NIEM-based standards throughout the various agencies and departments, a move that’s especially significant given that the recently created Federal CTO slot now held by Vivek Kundra is directed out of OMB.

XBRL proponents may be dismayed by this, given the oft-stated hope that XBRL would be seen as the accounting language to be used by key Federal agencies. However, the situation isn’t as clear-cut as it may seem. One of the strengths of NIEM is its core mission to reduce the amount of unnecessary duplication within ontologies given the large number of existing, well-defined industry and domain specific schemas currently in use. To that end, NIEM makes heavy use of such standards as GML, as well as most of the W3C core languages, Atom, and other specifications. Additionally, NIEM IEPDs can be written to work with payloads, which offers the possibility that XBRL could be transported within NIEM.

This is not to say that NIEM will likely end up creating a wholesale adoption of XBRL as a sub-standard. The two architectures are fairly different, with NIEM being much more structural in approach and only secondarily referential, while XBRL is primarily linear sequences of properties with heavy internal referencing. The differences are significant enough that while it is possible that the NIEM Program Management Office (PMO), the organization that ultimately vets NIEM standards, will be willing to greenlight a straight adoption of XBRL, it’s not especially likely.

What is more likely to happen is that some attempt will be made to create a set of "harmonized" schemas that would share common ontologies between major XBRL schemas, the NIEM core set, and any existing accounting standards that are currently in use at the Federal level. Structurally, there would probably be some kind of bridge service that might make it possible to map from one set of standards to another, either via a set of transformations or via related tools. This is something of an ongoing process that is taking place at a number of levels, as major schema frameworks get large enough adoption to effectively collide in various domains.

Long term, given the adoption that has taken place with regulatory agencies globally, it’s certainly unlikely that the US will walk away from the XBRL standard.  However, it is also unlikely that the US government will sacrifice what seems to be a working, increasingly widely adopted internal standard such as NIEM when it is more likely that such a standard could be adapted to subsume many of the better elements of the XBRL standard while maintaining its own internal cohesiveness. Given this, it may behoove the XBRL community to be open to the possibilities of harmonization, on this and other fronts such as the Semantic Web harmonization currently under discussion with the W3C.

In the long run, the goal for everyone is the same: to provide a set of standards that will improve the efficiency of government messaging; make for a greater degree or reusability of content throughout the thousands of departments and agencies at the federal, state, municipal, and tribal levels; and make government accounting ultimately more transparent and accessible to the people who use and depend upon it.

For those seeking more information about NIEM, check out the NIEM website. Additionally, the NIEM PMO is scheduling a NIEM National Training Event in Baltimore on September 30  to October 2. Speakers will include Vint Cerf, one of the founders of the Internet, and OMB CTO Vivek Kundra.

Both image are facets of the truth. But for those who want to participate in the XBRL conversation, it’s the picture of vigor and purpose that is relevant, even if the consequences don’t rise to the level of political insurrection. Sure, there’s the occasional tweet by a 20-year-old of “I’m still WASTED from last night and my XBRL paper is due in TWO hours. HELP!” But as a whole, the tweets that discuss XBRL represent reliable news and useful commentary on the interactive data world.

The 140-character limit of tweets defines the essence of the service, and it’s Twitter’s best and worst attribute. The required brevity concentrates the mind wonderfully and makes for quick reading. But some thoughts do require more than 140 characters, and by the time you include your username — and quite possibly a web link, a reply address, and an RT for retweets — there isn’t much room left over for content.

One enormous positive of Twitter that is perhaps not universally known, however, is that its database is updated continually in real-time (or thereabouts). This is in striking contrast to Google, which, even with diligent pinging, may not index your blog post for several minutes, a few hours, or even a few days.

I recently did a small study to examine XBRL tweets in some depth. I had two main questions: (1) Who tweets about XBRL, and (2) What XBRL topics do they tweet about.

Using Twitter search, I retrieved all tweets between August 23 and August 29 containing the keyword XBRL, reviewed the tweet, and classified the content by subject (eg, SEC filings, UK taxation, meeting/event). I also recorded each tweeter, reviewed their bio on their Twitter homepage, and classified them by occupation (eg, accounting, marketing) or, where more appropriate, function (news feed, XBRL organization, etc.).
 
As an attempt at a rigorous study of XBRL tweeting, the shortcomings of my work are multiple and substantial:

• Naturally, only public tweets are included, no private ones
• It’s highly likely there were a few XBRL-related tweets that did not include keyword XBRL (such as a reply to another tweet, where the XBRL subject was understood)
• Twitter search (formerly Summize) has a less-than-sterling reputation and is known to miss a few tweets. I did compare my hits to those from one of the independent Twitter search engines, however, and didn’t find significant differences
• The one-week sample was taken during late August, a quiet, semi-holiday period
• Whenever the study is done, a one-week sample will be greatly influenced by what is being published on the Web at the time. For example, during the week an interview with Michelle Savage of XBRL US in which she gave advice to IR professionals was tweeted and re-tweeted several times, boosting the IR content category
• Classifying both tweet (for content) and tweeter (for profession or auspices) in single categories was naturally sometimes difficult. When I tried to classify myself as a tweeter, for example, I had trouble choosing among several categories

With all those caveats, I still think the results provide some indication of who tweets and what they tweet about. In all, I looked at 143 tweets. Thirty of the 143 were retweets; but that number is understated, since I only counted a retweet if it included the characters RT (other tweets similarly repeated tweets without saying so).  Ninety-eight of the 143 included hyperlinks, which indicates well that XBRL tweets often recommend resources on the Net.

The content of the tweets can be broken down as follows:

The high count of 45 for XBRL General reflects a few broad articles that were published during that time about XBRL, including CFO.com’s XBRL: The Inside Story, which was tweeted and retweeted often (and which could have easily gone in the "internal reporting" category).

XBRL tweeters represent a wide variety of backgrounds, as shown by the breakdown of the tweets by tweeter category:

As I said, these data should be regarded with more than a pinch of salt, but it still demonstrates the range of background of XBRL tweeters. I think the one (slight) surprise for me is that there are few, if any, security analysts tweeting about XBRL. I can think of several reasons for this – not least that brokerages have strict rules about external communications – but I still find the lack of participation disappointing.

In total, there were 74 tweeters of XBRL during the period. The categories with the highest numbers were technology and media. But the overall distribution was relatively even. (XBRL Maven is a category I used for people like Eric Cohen and Neal Hannon who are leaders in the field.)

It will be interesting to do this study again in a few months for a different time period to see how the data have changed. In the interim, I will write an article soon that addresses the larger topic of XBRL and social media. 
 

Marc van Hilvoorde is responsible for the development and implementation of digital reporting at the Netherlands Tax and Customs Administration (Belastingdienst). As the technical project manager of the Netherlands Taxonomy Project (NTP) he was responsible for the development and delivery of the Dutch national taxonomy. He is a former member of the XBRL International Standards Board and former chair of the Domain and Rendering working group.

Statutory and regulatory reporting is hardly the favorite subject of company managers, but most of them accept it as a necessary evil. The vast majority of businesses comply with its reporting requirements without much protest, supported by an army of accounting, audit, and IT professionals.  

In the many years I have been involved in the field not much has changed, and that seems a bit odd to me. It’s true that we have noticed a shift to digital reporting that improves timeliness and data quality. The old information exchange model is still very much in place, however. Regulators typically request the same information at the same time from every company, so many government agencies have large computer systems that do major duty during “filing season” then are put on standby the rest of the time. Additionally, the existing dogma in regulatory reporting seems to be “one size fits all.” As the numerous spreadsheets floating around on servers and hard drives within organizations can attest, however, the accounting industry already knows that one-size-fits-all simply isn’t true.

Furthermore, regulators almost never consult with other government agencies to get on the same page with their specific inquiries. In fact, it is difficult to align different investigations within the same regulatory agency. As a result, regulators repeatedly ask for the same information — information that’s already been reported, information that could be obtained just by asking another agency. I get more than a little annoyed when I have to manually update three different calendars with the same information, and I know others share my frustration.

Managers may see statutory and regulatory reporting, and its requisite inefficiencies, as proper and necessary, but that does not absolve regulators of their responsibility to innovate and make things easier for them.

In the Netherlands, the Government, regulators, and business all have recognized this obligation. Toward that end, the Government and regulators are collaborating in support of the adoption of Standard Business Reporting (SBR), a continuation and deepening of the Dutch Taxonomy Project begun in 2004.

Based on the XBRL standard, a national and cross-agency taxonomy has been created. The national taxonomy is not only for regulatory and statutory reporting; it can also be used for tax filing and statistical reporting. Commercial banks have said they will use the taxonomy for credit assessment reporting as well.

Why is SBR important? It has become increasingly clear over recent years that regulations, and the ways regulators operate, need to change. Regulators traditionally have faced the risk of not having necessary data; more recently, a different exposure has become more prominent: having the right data but not doing anything with it. In the current global financial crisis, we now read reports of numerous red flags that simply were missed. So often, a simple cross-agency inquiry could have revealed the truth but was not performed.

To address the need to use data properly, the current financial information supply chain simply is no longer sufficient. Computer systems already are pushed to the limit. Systems may contain the necessary data, but often they seem incapable of presenting it in a proper way to regulators. Meanwhile, regulators in turn are becoming reluctant to ask for more data, in part because it can be too time-consuming to analyze additional information. Unfortunately, there are examples of regulatory reporting which is only that: reporting. In other words, data is sent and received, without any further investigation or analysis. For every regulator, this should be unacceptable. Unused data is a waste of the time spent preparing it, and its mere collection fails the public by providing a false sense of security.

The piles of data will only increase, so if information overload were the issue, all regulators ought to stop collecting data. The real issue at hand isn’t information overload, however: it’s the need to search, find, and retrieve the information that’s been collected. To make information discoverable for users, tracking and tracing data is an important precondition. Thus, tagging data with the help of an XBRL taxonomy facilitates search, retrieval, and analysis.

More must be done to make life easier for business, however. One of the key items for regulatory innovation is facilitating cross-agency collaboration. Regulators need to introduce more robust and more sophisticated information exchange models and build the infrastructure to fit those requirements, and software vendors need to build new systems that support users’ needs.

These needs are evolving, as boundaries between organizations blur. Goods, money, and people move around the world ever more quickly, and this faster circulation means a more rapid flow of corresponding data and information. This means that it’s necessary to develop new globally oriented views on what regulation in the future will look like and how it will function. The new regulatory dogma should be “Get the right information at the right time,” guided by the principle of cross-agency reuse of information.

Here is an illustrative parallel: this regulatory and reporting trend matches the development of GPS systems to replace paper road maps. When drivers use a GPS system, they are concerned only with their own routes; they don’t need to open an unmanageable, one-size-fits-all paper roadmap. Each driver determines what destination to pursue and which road he wants to travel, and each driver gets his own route and the right information at the right time: “Turn right here.”

Similarly, statutory and regulatory reporting can move much closer to the actual needs of the users of information, and at the same time decrease preparers’ reporting and administrative burden. This improvement is the goal of the SBR program.

Businesses can motivate regulators to innovate and change their behaviors, as well. This is why the Dutch cross-taxonomy now is under constant review by the public domain. People have asked, Why are these tags in there? Who is using this information? By shaping what information is defined by the taxonomy, the public shares a tool of regulatory control: identifying, explicitly, what information is sought, at what intervals, and under which law.

It is in the interest of both the users and preparers to move towards the reuse and comparability of information. Introducing digital reporting using open standards like XBRL can provide wonderful opportunities to achieve these goals, which will benefit everyone involved. Just ask your local regulator.

Development of an XBRL taxonomy for IFRS in Chile began in January 2008. The SVS team comprised members of both the IT and financial departments of the agency. The going was initially tough: it was the first time that the team had had contact with XBRL, and we had to absorb its rules and devise methods to work with it successfully. These difficulties were exacerbated by the many changes in IFRS during the 2006-2008 period. Our team included several accounting professionals and their views often differed on what disclosures were required under IFRS. Resolving these disagreements and obtaining consensus took some time.

Finally, in October 2008, the SVS released the SVS CL-CI 2008-10-31 XBRL Taxonomy for reporting of financial statements under IFRS. The new taxonomy is an extension of the IFRS General Purpose Financial Reporting (IFRS-GP) taxonomy for 2006, the latest version at the time the SVS taxonomy was created, and has been updated according to the 2008 Bound Volume. 

The current SVS CL-CI XBRL Taxonomy represents the legal regulations (IFRS as well as Chilean GAAP) applicable when the taxonomy was released. It consists of a single schema file that imports IFRS-GP elements and defines additional concepts. The SVS CL-CI XBRL Taxonomy uses 2,636 IFRS-GP concepts, of which about 2,490 are non-abstract items. It does not use the presentation and calculation relationships defined in the IFRS-GP. It does use all elements of the IFRS-GP 2006 taxonomy that were still in force and ignores that do not serve current needs. Additionally, we created 1,087 elements to fulfill requirements under the new rules.

However, we do not use certain structures from the IFRS-GP 2006 taxonomy, including notes to the financial statements required by asset, liability, and income statement disclosures; income statement classes; and so forth. Instead, we chose to use the presentation linkbase from the 2008 IFRS Taxonomy for disclosures required by IAS or IFRS.

In essence, although the SVS CL-CI Taxonomy is an extension of the 2006 version of the IFRS-GP Taxonomy, its architecture is based on the IFRS 2008 Taxonomy. Additionally, the taxonomy has been modularized standard by standard and regulation by regulation based on IFRS and Chilean GAAP. Each standard has been organized in components of the report (statements, notes, and disclosures).

There has been resistance to these changes inside the financial department, and it has been hard for our analysts to accept the new information model. They did not like the presentation of disclosures as required by IAS and IFRS, which represented a substantial change from how disclosures have historically been handled in Chilean financial statements. On the other hand, the new information model has made it easier to prepare financial statements, because it contains every disclosure required by IFRS rules, and there are clear references to where to go and what to do. Against that positive, however, it should be said that the new model is more complex. We have received criticisms from companies that too much detail is being asked of Chilean companies, which often don’t have readily available the information that’s now required.

During the taxonomy development period, the team prepared a webpage to report about the project and developed tools to help companies use the taxonomy. We also created a “taxonomy explorer,” which is useful to review the taxonomy, the presentation linkbase, the elements, and all the references. We have offered workshops for companies to give them some basic knowledge of XBRL and to encourage them to generate their financial statements in XBRL files.

Nevertheless, the first submission of XBRLized financial statements by companies was difficult. We intended to offer a tool which would enable companies to enter the required XBRL information and generate their XBRL files. But this attempt proved to be a mistake, and we had many problems in actual practice. We now require companies to generate their own financial statements and not use the interactive form. (Company financial statements are available on the SVS website.)

In addition, there have been the start-up problems you’d expect where company staffs have had little background working with IFRS and XBRL. We receive many technical queries, such as how to indicate a particular element and how to deal with tuples using certain software.

The truth is that each time new software has been implemented, there have been new problems. Startup is always hard. At the beginning there is lack of knowledge and resistance to change; but as people learn, they embrace the new standards. When we first started there were no experts in XBRL, but with the current requirements (and hence demand) for XBRLized financial statements, many software vendors have developed tools for the generation of XBRL files from within companies’ own systems. The SVS team is now working on the taxonomy for next year’s filings, which will be an extension from the IFRS Taxonomy 2009.

Dr. Michael Alles is associate professor at the Department of Accounting, Business Ethics & Information Systems at Rutgers Business School and editor of the International Journal of Disclosure and Governance, whose August 2009 issue is entirely devoted to XBRL. His specialties are continuous auditing, XBRL, and governance.

For a technology that is designed to increase the transparency of information, there is much that is still opaque about XBRL itself. Even as the firms that make up the overwhelming majority of market capitalization in the US begin reporting to the SEC using XBRL for the first time, fundamental questions remain about the demand for interactive data and how investors and others will make use of it.

Just a few weeks ago at an XBRL panel at the American Accounting Association annual meeting in New York, Bob Laux of Microsoft, which in early 2002 became the first technology company to report their financials in XBRL, said “I would love to know why it was that so few firms joined the voluntary filing program (VFP)." As Glen Gray noted in his talk XBRL: Solving Real World Problems:

Despite the potential benefits of XBRL only 137 companies (out of over 10,000 filers) participated in the SEC’s voluntary filing program (VFP). Less than 1% of the banks required to use XBRL for quarterly call reports to the FFIEC are also participating in the SEC’s VFP. XBRL adoption appears to be sitting on the edge of the chasm between the early adopters, who are tolerant of the issues associated with new technology and are less concerned about near-term ROI, and the majority of the potential market, who are more sensitive to costs, ROI, and ease of use.

Contemplating the low levels of participation in the VFP, Bob asked plaintively "What does that say about XBRL?"

What, indeed.

One is tempted to dismiss such questions about the VFP as obsolete now that XBRL is mandated, but that may be too facile. The fact of the matter is that XBRL is marketed as so self-evidently beneficial at so trivial a cost (“chickenfeed” is how Bob described the cost of the approximately 24 person-hours that he said it took Microsoft to tag its latest reports, down from 180 hours in the first year), so widespread in the efficiencies it would generate throughout the information value chain, and so clearly going to reduce the cost of capital for reporting firms, that people should have lined up around the block demanding XBRL. In fact, some of the original pioneers of XBRL, such as Eric Cohen, have mixed feelings about the government mandate for tagging, since they had always envisaged XBRL adoption as arising naturally as a market-driven phenomenon.

However, as Professor Gray points out, even as US banks have built up a deep familiarity with XBRL — given the early decision by the FDIC to require tagging of call reports — the bottom line is that almost no banks took the (what presumably would have been for them a trivial) extra step to also tag their financials. There is clearly something going on here — fear of litigation, lack of knowledge, lack of interest — that was not envisaged.

And demand is not the only unanswered question about XBRL. Take assurance: the SEC does not require it (as yet), but it does not discourage auditors from looking at tagged documents. On the other hand, for reasons best known to itself, the SEC does not allow the audit opinion itself to be tagged!

Of course, one can make the market efficiency argument for not mandating that mandated XBRL statements have a (mandated) audit opinion and, instead, letting the market decide the value of such statements, with firms providing voluntary assurance if they judge it warranted. But the contradiction between having to mandate XBRL statements because the market isn’t demanding them and then leaving assurance to market forces is fairly obvious. 

While the position of firms on assuring XBRL reports may change as their two-year safe harbor provision expires, even if assurance proves desirable, the question remains about how that assurance will be provided. Ironically, here the apparently low cost of preparing XBRL statements works against their assurance. If it takes Microsoft only 24 person-hours to tag their reports, realistically how many audit hours will they be willing to pay to provide assurance for them? And even 24 hours may be an outlier, with Phil Moyers of Edgar Online claiming that, with his automated tagging approach, a typical firm’s statements can be processed in no more than 8 to 10 hours.

Contrast that with the elaborate framework Professors Alex Kogan and Raj Srivastava have come up with for aligning XBRL assurance with standard audit practice and their argument that no current proposal for auditing XBRL instance documents is consistent with auditing standards. Will audit firms be able to come up with an expedited low cost audit procedure for XBRL documents (i.e., low enough relative to the expected cost of repeated XBRL tagging that may be no more than a few tens of thousands within a few more years)?

It’s possible, but let’s not forget that Congress expected that it would take a typical firm no more than 90 minutes to comply with Section 404 of the Sarbanes Oxley Act, as opposed to the billions of additional revenue that it generated for the audit firms. The fact is that in the litigious environment of the US, no auditor will sign off on an entirely new statement with only the brief examination that low cost allows, while it is equally unrealistic for firms to pay more to assure a document than they pay to prepare it.

What these examples indicate is not that there is a fundamental problem with XBRL as a technology, but that it is now much more than a technology. It is becoming part of the fabric of US business life and hence subject to all the forces and pressures that occurs in business, from resistance to change to fear of litigation.

The latter may be the biggest hurdle that XBRL will likely have to overcome if it is to fulfill its promise, as evidenced by the tale of the extension tags. As far as the VFP is concerned, a very large proportion of tags were extensions. The story is apparently that lawyers recommended to filers that existing terminology from the firm’s financial statements be retained as an extension rather than allow even small changes in order to use an official taxonomy item. And there is much more use of extensions today than one might expect given that the current taxonomy has over 14,000 tags.

What is interesting is that this “better safe than sorry” argument was never apparently countered by the case that better tagging would facilitate better comparisons with peer firms and a more favorable reaction in the capital markets. Perhaps the latter argument will come to the fore as more firms file in XBRL, and the SEC is clearly pushing firms harder to stick to the standard taxonomy. But this example clearly demonstrates that predictions about how tagging will work in practice cannot be made on a purely technical basis alone, and hence, many more unexpected outcomes are to be expected as the mandatory program kicks in.

Perhaps the reality is that managers simply do not perceive tagging in the way that the IT specialists who have made it a reality do. One more story: academics have repeatedly pointed out that many of the VFP filings did not even do something as basic as validate, and often contained many other easily detectable technical errors. Hopefully, these problems will decrease with more experience and the SEC previewer feature will greatly help filers submit only valid instance documents (though the fact that the SEC felt obligated to offer a previewer in the first place is quite telling). But the question is why filers made such elementary errors in the first place, when voluntary filers most of all are surely driven by expectation about the net benefits of XBRL. Perhaps “good enough” is about as far as managers are willing to go with tagging and see no reason to give it a higher priority. That would disappoint many of the advocates of XBRL, but it is perhaps a realistic assessment of where tagging fits into the already overfull agenda of today’s CFOs.
 
With the SEC mandate for XBRL coinciding with the tenth anniversary of the birth of the standard, it is worth asking where tagging will be going over the next decade. Will it become the new language of business, as the AICPA put it in a recent publication, or will XBRL be ubiquitous in the way PDF is today: part of the plumbing of business infrastructure, essential certainly, but also unremarkable. Success may actually mean that it is both, but we should have no illusions that the road from here to there will be smooth just because we have a taxonomy that is 2.1 instead of 1.0. It is time that XBRL be seen by users, regulators, academics and preparers as a business practice, with all the complications and unknowables that this implies, and finally put aside the illusion of the technician, i.e., that if you build it they will come.

Because Hitachi Data Systems hosted the XBRL Technology Workshop & Summit, my objectivity may be justifiably questioned if I sing its praises. But the event, presented by XBRL US, was much more interesting than I had thought it would be.

My expectation was that most of the conference would be highly technical and interest only developers. Instead, the wide-ranging presentations illustrated both the breadth and depth of XBRL’s potential, as well as the significant challenges ahead for implementations.

Paul Wilkinson did an outstanding job of blogging the conference proceedings on July 28,  29, and 30,  and slides of many presentations have now been uploaded to the XBRL US site. Re-reading Paul’s comments and the slides, I experienced the alternating sensations of exhilaration and concern I had while listening to the speakers. 

On Day One, Campbell Pryde, Chief Standards Officer of XBRL US,  discussed the development of US taxonomies. What enormous progress has been made in the three years since the SEC awarded funding for the first US GAAP taxonomy! (Someone asked Campbell in another venue: With 17,000 elements in the GAAP taxonomies, why would anyone think of adding an extension?)

At the same time, Campbell’s discussion of the use of 2008 versus 2009 GAAP taxonomies as well as FASB Accounting Standards Codification evoked Matt Kelly’s admonition in his post on the SEC mandate: “Adoption not only requires some specific vow of action; it requires maintenance, day in and day out, and that can be hard to deliver.”

Makoto Koizumi’s talk reminded me of the excellent series of posts by Kobayashi Toshinori on the XBRL implementation at EDINET, and the strong participation by Japanese companies of its voluntary filing program. Koizumi noted, however, that there is no immediate plan to introduce XBRL for footnotes. The SEC’s XBRL mandate requires only limited tagging of footnotes, not the deep tagging that had originally been envisioned. And as Amy Pawlinkci has discussed, there are no immediate plans to allow US companies to tag the MD&A either.

In both the US and Japan, therefore, tagging for the foreseeable future will be mostly for the primary financials. Is that sufficiently ambitious to demonstrate the value of XBRL and gain the support of the investment community? This question was put in relief by the presentation of Darrell Heaps of Q4 Systems: he has talked to many Investor Relations Officers (IROs), and few see what XBRL does for them. On the other hand, the transformation of the “investor web” that Darrell described from only static corporate websites to dynamic social media (Twitter, wikinvest, Seeking Alpha, etc.) creates exciting possibilities for a data standard with the capabilities of XBRL.    

For me, the key message of Convergence of Taxonomies for Financial Reporting, a group presentation led by Josef McDonald of Ernst & Young, was that XBRL for IFRS is driven by the individual IFRS standards, while US and Japan GAAP taxonomies are hybrids of standard-driven and market-driven elements. This difference accounts for the lack of industry taxonomies in IFRS, and why US GAAP taxonomies are much more highly developed than those of IFRS. The good news is that, looking out toward a time of convergence in accounting standards using XBRL tagging, the world’s leading taxonomy creators are closely cooperating on international taxonomy development.       

The presentation on XBRL and corporate actions given by representatives of DTCC, SWIFT, Citi, and XBRL US was extremely exciting. Their slides demonstrated the labyrinth that corporate actions data must navigate to be fully disseminated, a process involving multiple stakeholders including issuers, filing agents, custodians, stock exchanges, and investors. As described in their excellent conference backgrounder, once the Corporate Action XBRL Taxonomy being readied by XBRL US is completed:

Issuers (or their agents) will be able to create their press release, prospectus or letter of transmittal in XBRL format, clearly indicating the market, event type, security type and whether the offer is mandatory or voluntary. All of the information that the issuer has “tagged” or identified within their document will be “machine readable” and can be extracted, searched on and consumed by the stock market, custodian, depository, transfer agent and, ultimately, the investor. Because the taxonomy is developed following the ISO 20022 standard, the data will be available in a familiar format to all users.

In my opinion, this raises a couple of questions: Doesn’t capturing key data points from text-based documents like press releases and prospectuses present the same sort of difficulties that have slowed tagging of financial statement footnotes? And with an overhaul of financial regulation in view in the US and other jurisdictions, won’t corporate action taxonomy maintenance be unusually difficult for the next few years? Regardless of these challenges, corporate actions seems an especially ripe area for the application of XBRL.

Steve Wright of Salesforce.com Foundation spoke about data in the social sector. Steve discussed the inadequacies of using a currency like the dollar for measurement of costs and benefits in the social services marketplace, and described initiatives for deriving better yardsticks for more effective measurement of social impact. Efforts like PULSE/IRIS for creating financial, operational, and social impact metrics can be effectively leveraged through XBRL reporting.  

I agree entirely with Steve on the futility of using dollars to evaluate returns on social investment. The challenge, which Steve recognizes entirely, is coming up with better measures. The concerns I have are data quality and assurance.

For example, in this blog post on Change.org, Steve posits an organization in Dakar working to decrease disease by building urban sanitation stations. Assume that the metrics created accurately reflect social impact. What biases do the data collectors have, how are they reflected in the data, and what kind of assurance can be performed on data in such an environment? But regardless of these concerns, Steve’s work is representative of yet another area outside external financial reporting to which creative minds are seeking to exploit the rich potential of XBRL.   

It was extremely encouraging to hear from the young Japanese interns at XBRL US. Their work on topics like formulas, extensions, and corporate actions was all the more impressive for having been accomplished in two weeks (some of their slides looked like they would individually take two weeks to prepare).
 
I was a bit disappointed, however, to hear little mention of accounting in any of their work, and the absence of any American interns engendered the usual worry of whether US schools were producing kids with these kinds of skills (and if they are, where were they?). But I know that XBRL US  must have been delighted to have their contribution.   

The last session was on Database and Business Intelligence, which included presentations from UBMatrix,  Morningstar,  Informatica, and Oracle. I wish Morningstar no ill; but if data aggregation (a chunk of Morningstar’s business) is supposed to wither away with the waxing of XBRL, shouldn’t their people be a lot more unhappy than they seem to be? Homi Byranji of Reuters seemed similarly unworried in his presentation at the London Investment Professionals Conference  last year. If their demeanor is anything to go by, XBRL doesn’t doom the data aggregators.

Finally, I have often wondered why bloggers reporting from a conference will end with a mundane personal note that could only be meaningful to a small group of readers. I now understand why they feel compelled, as in my case, to say how great it was to match faces to the names I have admired over the past three years, and to have the opportunity to thank guest writers in attendance for all their hard work on behalf of the blog (Neal Hannon and Ashu Bhatanagar deserve special mention). I also know that this summary has only discussed half the presentations, and has done justice to none. If any speaker would like to follow up their talk with a blog post, please contact me. 

Joanne Locke, senior lecturer at the University of Birmingham (UK), is a member of the International Accounting Standards Committee Foundation’s XBRL Advisory Council. Her current research focus is the trend toward global standardization of business information.

"Where are the missing masses?" is a question that social theorist Bruno Latour poses for sociologists. It also a useful query for the XBRL community: What happened to the large numbers of users that were expected to demand "interactive data" and create the critical mass for its adoption? As Todd Neff wrote in Compliance Week, "Investors and analysts have since celebrated this regulatory milestone [the SEC mandate of interactive data] with an extended, gaping yawn." XBRL is being adopted by regulators and stock exchanges regardless of the lack of interest, while claiming that investors are the key beneficiaries.  

I want to tackle two broad questions: (1) Are retail investors (the masses) important? and if so, (2) What is needed to provide them with interactive data that is useful for them?

Are Retail Investors Important?
The SEC has emphasized the need to protect retail investors through interactive data’s potential for improved accessibility and transparency. Investor protection is part of the SEC’s mission and EDGAR was old and in need of updating; however, very little is understood about how individual investors use company reports for investment decision making. Indeed, the little evidence available suggests they mainly don’t. So if the purpose is to provide protection by increasing the efficiency of the capital markets by turning retail investors into an "army of regulators" as David Roth in his Wired article suggests, I think the effort is misdirected.

Recently, attention has returned to the role of investment funds and other institutional investors in active stewardship and governance oversight of the companies in which they invest. A study that will soon be published by the ICAEW, Digital Reporting Options for Europe, shows that the proportion of the capital in the UK and US markets provided by institutional shareholders is steadily rising. In the UK, Sir David Walker has recently released a report on governance in banks which takes this view and echoes earlier calls for institutional shareholder responsibility. Given that professional investment analysts working in this sector already have access to sophisticated databases that provide data directly for their investment decision models, interactive data does not provide them with any significant enhancement.

It may be that despite the regulator rhetoric about benefits to retail investors, that this is not actually the key argument. It may be that we simply believe that it is a citizen’s right to have the potential to access the best data that can be provided if they so choose, as Bob Schneider argued in this post. This approach is attractive from the point of view of the power of the internet to create something closer to "level playing field" and "democratization" for individuals. But it is equally important to consider the hyperbole used about the potential effects and carefully evaluate the cost/benefit, the regulatory structures for controlling the tagging, and how the data will be audited. These are critical questions.

What Is Needed to Provide Retail Investors with Interactive Data in a Useful Format?
If we take the view that improved access to data is an investor’s right, then how do we ensure that the functionality provided by interactive data doesn’t actually mislead and confuse less sophisticated retail investors?  

Experimental research undertaken as part of the Digital Reporting Options for Europe project compared user decision making and perception using PDF statements and an XBRL-tagged presentation in an Excel spreadsheet that included key ratios calculated automatically. The results show that investors tend to view ratios automatically calculated from the tagged data as more "accurate" than their own calculations based on cutting and pasting (or retyping) from the PDFs. They relied on them without questioning the basis on which they were calculated.

The experiment consisted of two companies’ accounts. The problem in this example is that the automated calculation does not take into account that the financials, both prepared in conformance with IFRS and accurately tagged, were not comparable because one company had internally generated intangibles and the other had purchased brands. This fundamental difference between the two companies results in a different accounting treatment that renders the financials not directly comparable (footnote information must be integrated to adjust the figures). This is just one of many possible examples where even where companies comply with the requirements, comparison is not straightforward.  

I can hear XBRL proponents saying, "Yes but that’s a problem with accounting that exists today." Yes, that’s true – but it may be exacerbated with interactive data. The "slicing and dicing" and automated processing of data removes the retail investor further from the chance of integrating this information, which is at least presented in the context of the whole report using PDF. Automated calculation makes it easier to focus on the ratios and presenting them side by side gives the appearance of direct comparability. Unless the software and portals that are designed for retail investor use are carefully structured to provide support to improve the quality of decision making, we risk providing not a simple tool, but a simplistic one, that misleads. As researchers have noted, this problem is magnified many times if the tagging isn’t accurate or the company creates unnecessary extensions.

The challenge ahead is to provide a careful, objective evaluation of what interactive data can and can’t do for retail investors. To safeguard investors and deliver the potential benefits – regulators, software vendors, investment advisors, and academics – will need to take responsibility to ensure that the mechanisms by which interactive data are disseminated and analyzed are fit for purpose in the hands of the intended user. So far, the SEC has taken the view that it is not the appropriate body to guide the development of such tools, leaving it to the market. But unleashing interactive data without balancing guidance and appropriate tools may end up hurting the investors it was intended to empower.

Gary Purnhagen has more than 20 years’ experience in helping firms in diverse industries meet document processing challenges, including SEC disclosure. His past experience has included responding to the SEC’s EDGAR program, use of the Internet and other digital media for information dissemination, and most recently the evolving use of XBRL for financial reporting. He is an independent consultant assisting firms in embracing innovation and responding to the SEC’s XBRL mandate.

In an ideal world, properly formatted XBRL files should render using the various software packages on the market matching the presentation of the HTML or PDF version of the same information. Unfortunately, this is not the case. Today, depending on which rendering software you use, how you code the XBRL file, and to what level of detail you present, you could have discrepancies between the rendered XBRL files and the HTML or PDF.

XBRL proponents (and I count myself as one) will say this is a result of the original intent of XBRL and is a problem that is being addressed by initiatives such as Inline XBRL. All true. The original intent of XBRL was to create a format for computers to understand the content and context of business reporting information. It was hard enough to get the formatting correct for the computers to be able to understand this information and so the focus was not on addressing the rendering issue.

Inline XBRL essentially allows the XBRL file to be wrapped up in HTML, presenting the XBRL tagged information in HTML. The browser, presenting the HTML coding ignores the XBRL coding. The Inline XBRL in practice is still a year or two away.

Let’s pause for a moment and look at the need to render XBRL. At this point in the adoption of this new evolving technology the primary need for rendering XBRL is to allow a company to review the XBRL coding to assure that their XBRL files accurately reflects their financials as reported. Today, the best way of doing this is to render the XBRL financials and ensure that they match up with the HTML or PDF format, which was signed off by management.

The software available for preparing XBRL all can render XBRL coding to some degree, although proper valid XBRL coding at times will not render correctly. These problems can be alleviated at times by arbitrary changes in the order of codes. This requires that the preparers spend time attempting to get around the rendering “bugs” to allow proper rendering for review by the company’s management for assurance purposes.

If this was not enough of a problem, the preparers have to contend with the SEC’s Viewer, which could have its own problems with a correctly formatted XBRL file. So now, the preparers are forced to begin experimenting with the code to get around the rendering problems with the SEC Viewer.

Furthermore, while the SEC’s rules call for the rendering of the XBRL file to agree as closely as possible to the financial statements, there are real limitations to the SEC’s Viewer. For example, it seems that the SEC’s Viewer cannot handle identifying balances as Audited or Unaudited. The solution for many filers has been to ignore this crucial piece of information — in other words, compromise the quality of information in order to improve rendering. Rendering problems also occur when dimensions, which allow for multidimensional presentation of information, are used.

Again, these problems are a reflection on the current state of the emerging technology and will eventually be addressed. However, for the time being, they are causing great concern for the filing community at large. There is no magic bullet for the problem today, although awareness by the filing community of these limitations will help in a rational response to it.
 

7. It may not be widely known that the AICPA played a crucial role in the launch of XBRL more than a decade ago. Could you describe how the AICPA was instrumental in inaugurating the data standard?  

Back in 1998, AICPA member Charlie Hoffman brought the XBRL concept to AICPA’s New Technology task force.  As quoted in a history of XBRL that the AICPA has just released titled The story of our new language: Personalities, cultures, and politics combine to create a common, global language for business: “Hearing Charlie Hoffman’s presentation on a new technology that would allow separate systems to share financial data in real time on the Internet, the team moved quickly to fund more prototypes and to make a business plan.”  

From that time forward the AICPA has supported the development and adoption of XBRL through the work of various committees and task forces, and through the establishment of XBRL International, Inc. (XII) and the XBRL US jurisdiction which was originally housed under the AICPA committee structure. In 2006, the XBRL US jurisdiction became an independent legal entity. Since then, the AICPA has remained actively engaged in XBRL US, and in XII, leveraging our communications channels and the intellectual capital contributed by our members to support the successful implementation of XBRL.

8. For decades accountants have been challenged to understand new information technology. Do you see XBRL as just one more piece of IT that accountants need to be familiar with, but not know in great detail? Or will XBRL require, at least for some accountants, a more in-depth, technical understanding? How might this vary among the different areas of accounting, e.g., financial reporting, internal auditing, external auditing, etc.?

The most important skill set accountants bring to the table with respect to XBRL is their strong knowledge and understanding of financial reporting. This is because tagging data is the equivalent of classifying data in company financial statements and footnotes, and it is critical that the “tagger” be intimately familiar with financial reporting when tagging financial statements, or with whatever subject matter they are tagging.  

That said, CPA preparers, internal auditors, and external auditors alike should have at least a basic familiarity with the mechanics of XBRL from a technical perspective. Software facilitates the process to some extent, but there are many technical rules to be complied with when tagging in XBRL and when submitting documents to certain bodies such as the SEC, which has written very extensive and detailed guidelines in a new chapter of the EDGAR Filing Manual dedicated to XBRL. Some understanding of how XBRL works from a technical perspective is also necessary to comprehend potential pitfalls. Many people think that XBRL-tagged data is inherently the same as the underlying data from which it is derived, much like turning a Microsoft Word document into an Adobe PDF, and that the data is somehow “inherently accurate.”  This is inaccurate – the data is only as good as the knowledge and skills of the tagger and/or a third party called in to check the accuracy of the tagging, and in the case of financial reporting in particular the required skill set is at the core of the CPA body of knowledge.

For more on this topic, readers may wish to refer to the AICPA XBRL Q&As on what accounting professionals, financial statement preparers, and audit committees need to know about XBRL.  For more detail specifically on what internal auditors need to know about XBRL, I would recommend the paper XBRL: What’s In It for Internal Auditors by Gianluca Garbellotto.  
 
9. How do you view the state of XBRL education for accountants right now? How do you see that changing in the future?

There are many progressive accounting professors out there teaching XBRL, and some have been doing so for many years. I think as XBRL adoption increases around the world, XBRL or at least the concept of interactive data in general will become more consistently covered in the education of accountants. We are starting to get inquiries from more and more professors as to whether there is standard curriculum they can be teaching related to XBRL, and I hope to learn more about what is being done and what is needed at the American Accounting Association (AAA) conference in early August.     

10. With the financial crisis as a backdrop, there has been much discussion of using XBRL for the reporting of TARP, asset-backed securities, executive compensation, and other areas relevant to the financial system. Do you see much chance that XBRL will be adopted for reporting in any of these areas? Which do you see as most promising for XBRLized reporting?

With respect to TARP and asset-backed securities, in his March 11 testimony to the Domestic Policy Subcommittee Oversight and Governance Reform Committee, XBRL US President and CEO Mark Bolgiano explained how “requirements for transparency in TARP funds reporting and oversight can be met using an existing standard [XBRL] that brings a consistent format to data on financial condition, risk, value, and compensation information regardless of sources.” XBRL can be used as a tool after the fact to help unravel the information (or in some cases lack thereof) that underlies the current credit crisis, but more importantly it should be proactively applied on a go-forward basis  to enhance transparency and access to data, thereby helping prevent future crises.  Readers can follow the latest on a bill currently before Congress on this topic.  

11. At the recent Paris XII conference you had the opportunity to speak to and hear from XBRL professionals in many countries. Is there anything that you learned from their experiences that would be instructive for those seeking to adopt XBRL in the US? Do you view the US as a leader in XBRL implementation, a laggard, or somewhere in-between?

I was encouraged to learn more about the diversity of ways in which XBRL is now being applied throughout the world. The AICPA has been and continues to be an advocate of what we call the “broader footprint” – the application of XBRL for reporting streams beyond financial reporting – as we feel this is where the biggest gains will be made in terms of process improvement and enhanced transparency of information.  

XBRL adoption varies greatly around the world, which is not surprising given different needs and different legal and regulatory environments. I think what’s most relevant here is not how one country or jurisdiction is doing vis-à-vis another.  Rather, there are very positive projects going on around the world that illustrate the vast potential of XBRL to be leveraged for process improvements in reporting in all areas of the private and public sectors and at the local, state, national, and international levels.  

In the US to date, this potential is exemplified by pilot programs put in place under the leadership of Nevada Controller Kim Wallin, who foresees the potential for greater efficiency and enhanced transparency through the use of XBRL for tracking grants and other financial information, as well as by the FDIC project for call reporting, and SEC rule-making related to financial reporting and other investment data.  

Internationally, XBRL is being used not only for financial reporting to securities regulators but also to tax authorities and stock exchanges, for reporting in the banking sector, and to standardize business reporting across multiple streams in various jurisdictions. Many examples can be found in the AICPA Journal of Accountancy article XBRL: Who Are the Early Adopters? by Karen Kernan, and on the XBRL International website.

1. Could you provide readers with a general overview of the areas and activities in which the AICPA is currently involved in with respect to XBRL?

We are a member of the XBRL US jurisdiction, and our President and CEO Barry Melancon is Vice Chair of the Board of Directors of XBRL US.  I am a member of the XBRL Communications Steering Committee, and our SVP of Member Competency and Development, Arleen Thomas, is a member of the XBRL International, Inc. (XII) Steering Committee and serves as Treasurer of XII.  My team and I also staff the AICPA Assurance Services Executive Committee and its various task forces and working groups, which include an XBRL assurance task force that is focused on considering potential services related to the accuracy of XBRL data tagging.  This task force recently released a Statement of Position on Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data.

2. Former SEC Chairman Chris Cox once said that requiring assurance for XBRL filings would result in its "crib death", while Dan Roberts, former Director of Assurance at Grant Thornton,  wrote the lack of an immediate assurance requirement in the SEC’s XBRL mandate "made a mockery of the dream of interactive data."

Do you see merit in both points of view? If Cox and Roberts represent polar opposites on XBRL assurance, where does the AICPA’s stance fall?   

If there is one thing we’ve learned through the work of the XBRL Assurance Task Force, we’re navigating uncharted waters on this topic, and it is a constant learning process. In the absence of some kind of effort to address the completeness, accuracy, or consistency of XBRL-tagged data, there is no way of knowing that the XBRL-tagged data is an accurate reflection of the underlying, audited financial statements. Given that it is the XBRL-tagged data that will ultimately be consumed by investors, regulators, and other users of information, failure to look at the accuracy of tagging creates both a disconnect and a potential expectation gap between the audited financial statements and the data that is actually being consumed.  Alternatives for addressing this issue are articulated in a recently issued Center for Audit Quality Alert entitled Potential Audit Firm Service Implications Raised by the SEC Final Rule on XBRL.  

3. What do you hear from the AICPA membership regarding XBRL? How would you describe their general attitude — "cautiously optimistic," "one more headache I can do without," or "what’s XBRL?" How has that opinion changed, if at all, over the past few years?  

Thanks in large part to the efforts of past SEC Chairman Cox to support the use of XBRL for enhancing the efficiency and transparency of financial reporting, knowledge of XBRL in the US has increased significantly over the course of the past three years.  We have made and continue to make an effort to educate members and the general public on XBRL and how it will impact the practice of both preparers and auditors through articles, whitepapers, conference presentations, workshops, and other channels.  

Much of our attention now is on educating our membership and the general public on how XBRL can be leveraged beyond financial reporting to a “broader footprint” for process improvements in reporting in all areas of the private and public sectors and at the local, state, and national levels.  It is through adoption of XBRL for this broader footprint that producers and consumers of information will realize the true potential of XBRL for enhancing process efficiency (e.g., by eliminating the unnecessary duplication of efforts that results today from manually providing common data elements to multiple channels) and transparency (e.g., by communicating data in a common format that can be automatically consumed by diverse software platforms).

4. As the AICPA’s liaison to the EBRC, you have worked to create a new XBRL taxonomy for the Management Discussion & Analysis. In its Comment to the SEC’s proposal, the AICPA expressed the hope that companies would be able to tag their MD&A. Commission staff have indicated, however, that companies will not be able to include the MD&A in their current XBRL filings.

What are your thoughts on that decision? When do you think the SEC will allow, and even require, tagging of the MD&A?

As Bob Laux wrote in the blog posting that you link to in this question:

…the Enhanced Business Reporting Consortium (EBRC) is currently in the process of improving the taxonomy for Management’s Discussion and Analysis (MD&A).  The current MD&A taxonomy consists of approximately 70 tags with most of the elements at the same hierarchical level. This required the creation of numerous company-specific extensions to make the taxonomy useful for those companies that tagged their MD&A under the SEC’s Voluntary Filing Program. While the new taxonomy being proposed by the EBRC currently only consists of approximately 140 tags, it has a structure that should significantly simplify the tagging of the information as well as facilitate access for users of this information.

It is my understanding that at least part of the SEC’s decision not to permit companies to include MD&A in their XBRL submissions at this time is based on the fact that, at the time of the final rulemaking, there was no existing taxonomy that had gone through a formal public exposure and review process that would enable meaningful tagging of MD&A (there is an MD&A file listed among the 2009 XBRL taxonomies that was also listed with previous versions of the taxonomies at the SEC website, but it is simply a list of tags that follow the table of contents for MD&A disclosures under Regulation S-K, and tagging at this level would not be useful to consumers of MD&A disclosures). 

While a draft of the EBRC MD&A taxonomy was available for public review at the time of the rulemaking, public comment on it was limited by the fact that few companies had attempted to tag MD&A under the SEC’s Voluntary Filing Program. The EBRC MD&A taxonomy was built to take into consideration the needs of the companies that had attempted to tag MD&A under the Voluntary Filing Program.  As Bob Laux said in his post, “It is hoped that the financial reporting supply chain will openly collaborate on the proposed taxonomy in order to create more detailed tags so that narrative information can be provided in an interactive data format.”  I believe this will naturally occur as more and more companies start tagging their financial statements in XBRL under the SEC Final Rules, and as investors gain access to XBRL-tagged data in a consistent manner and can begin to understand the potential benefits of tagging narrative information such as MD&A.

This belief is supported by the following excerpt from a recent research study made possible by a grant from the FINRA Investor Education Foundation and support from the EBRC entitled Impact of Information Tagging in the MD&A on Investor Decision Making: Implications for XBRL:

This paper investigates how professional and nonprofessional investors use the information contained in the Management’s Discussion and Analysis (MD&A) portion of the corporate annual report in making financial decisions. In studying use of the MD&A, we compare the standard paragraph format used by U.S. public companies to a “tagged” format consistent with eXtensible Business Reporting Language (XBRL)…

…Overall, results are consistent with our expectation that the availability of tagging…facilitates better incorporation of risk information into investors’ mental model of the subject company, for investors who choose to focus on that information. Further, it takes them less time to review that information in the tagged format, which indicates a more efficient decision process.  In sum, this study’s results suggest that the tagged MD&A structure results in more effective and efficient incorporation of risk information into financial decision-making.

The EBRC continues to invite interested parties to review the proposed MD&A taxonomy at this website. Follow the instructions for logging in and the MD&A taxonomy will be midway down the navigation tree once you are logged in.

5. In the AICPA whitepaper you authored titled The Shifting Paradigm in Business Reporting and Assurance, you say:

Because information on the Internet, especially the Web, can be easily created and revised without proper authorization, the integrity and authenticity of information lacking independent assurance should be skeptically considered by entities and individuals using XBRL to produce and consume information over the Internet.

Could you discuss the threats and dangers you perceive and what steps you think will be required to ensure that XBRL information on the Internet can be relied upon?

This question is partially answered in my response to Question 2 above as it relates to the accuracy of tagged data.  However, as described in your reference to the AICPA Assurance Services Executive Committee whitepaper excerpt above, there is more at play in an electronic environment than just the accuracy of tagging. There are also issues of data security and authenticity.

For example, how do you ensure that an online, electronic auditor’s report with the electronic signature of the firm purported to have conducted the audit is in fact authentic (as opposed to a paper-based original that is physically signed by an authorized representative of the firm and kept in a secure, physical location such as a locked file cabinet)?  Some audit firms are monitoring the Web for fraudulent postings bearing their name.  New technologies such as digital signatures and other means should be and are being explored by preparers and auditors alike to ensure the authenticity of financial and other business information that is increasingly being made available to, and accessed by, investors and other stakeholders online in an electronic format.  

6. Your paper also states:

Moreover, with more disaggregate information being reported [as a result of XBRL], auditing also will shift its emphasis away from verifying the way in which the firm aggregates and condenses its data, towards a broader conceptualization of assurance, particularly data level assurance.”

Are you concerned that asking auditors to not only express an overall opinion on the fairness of financial statements but to assure individual, disaggregated data elements as well places an unrealistic burden on them?

I believe reporting over time will evolve further toward an electronic model where users can define and consume the data elements that are most relevant to them. I have no doubt that audit and assurance models will evolve to address the changing needs and expectations that will come out of the evolution of the financial and business reporting model. The AICPA Assurance Services Executive Committee (ASEC) is committed to assuring the quality, relevance, and usefulness of information or its context for decision makers and other users into the future by (1) identifying and prioritizing emerging trends and market needs for assurance, and (2) developing related assurance methodology guidance and tools as needed.  In addition to the ASEC XBRL Assurance task force referenced in my response to Question 1 above, the ASEC has established a Data Integrity task force, which is developing principles and criteria for data integrity to supplement the Trust Services Principles and Criteria that were previously established for system reliability.

Hard as it is to imagine now, most publishing executives initially viewed the For Dummies imprint as a dubious idea at best. How could insulting potential readers by calling them dummies – right on the book’s cover! — possibly be smart marketing?

But the For Dummies brand became spectacularly successful.  Faced with learning computer software from impenetrable manuals, readers came to view the “for dummies” title as a sign of author empathy, not ridicule.

XBRL certainly comes under the “this stuff is complicated – help!” category of difficult technical topics that the imprint has traditionally covered (before it took up less challenging subjects, like hamsters and indoor grilling). Many readers will likely be familiar with Hitachi’s XBRL for Dummies book written by Peter Weverka and Wilson So. In October, Wiley will publish an XBRL for Dummies book written by Charlie Hoffman, the father of XBRL, and Liv Watson, one of the pioneers in the field. With two books with the same name, we thought it would be useful to tell you a bit about each.      

Hitachi XBRL for Dummies is a short-and-sweet intro to interactive data in 84 pages. Published last year, it defines XBRL and includes a brief history; it dispels common myths and describes the standard’s benefits. Notably, the book explains how XBRL is being used by companies for both external and internal reporting, as well as its potential uses in government.

At 384 pages, Charlie and Liv’s XBRL for Dummies is a more comprehensive volume. As Charlie states on his blog:

I am doing my best to condense my 11 years of working on XBRL including hundreds of conference calls, meetings, working with others in creating the specification, working with others creating taxonomies, and generally learning practical approaches to making XBRL work into the book.

The book will tell you what XBRL is, why it is, and how you can get your company ready for the new SEC-mandated business reporting standard for publicly traded companies. It is targeted at the business reader with no previous experience with XBRL.

Our advice (naturally): get the Hitachi Dummies book now and preorder Charlie’s and Liv’s book from Amazon.  

(This article has also been posted on Charlie Hoffman’s Financial Reporting Using XBRL blog.) 

Paola Fumiani is Project Manager at InfoCamere, which developed and manages Italy’s national data transmission system connecting the country’s 104 Chambers of Commerce and 300 different offices. She is a permanent member of the workgroup of the Associazione XBRL Italia, which developed the XBRL taxonomy for financial reporting in Italy, and a member of the XBRL EU Business Registers Working Group.

“No paper by 2012!” That’s the rallying cry of Italy’s Ministry for Public Administration and Innovation (MPAI), and its drive toward modernization is exemplified by the e-filing of general deeds’ business registration and the “XBRLification” of annual tax deposits. The MPAI’s initiative makes clear that digital is soon to be the de facto standard for public administration.

Business registration e-filing started with the Telemaco Project, a Web-based e-filing project for Italy’s Chambers of Commerce. The Project was set up by InfoCamere to simplify the Chambers’ administrative procedures by utilizing Web tools. The goal was to reduce the time and costs required to register new information and facilitate remote interactions with the Chambers of Commerce. 

The Project began at the turn of the Millennium, and a law made electronic filing compulsory starting in 2003. The benefit for companies was immediate: a 30% reduction in costs simply by moving from traditional “in person” filing to e-filing.

Evolution of E-filing in Italy for the Business Register

Telemaco’s e-filing application provided the foundation for XBRL adoption by providing the tools for filing, sending, managing, and storing signed Annual Accounts files.

A 2006 law strongly supported by the tax agency drove applying XBRL to the Business Register, with the aim to get all financial data directly from the official source — the Business Register — in a structured  format and no longer from tax forms. While companies have had to file Annual Accounts to the Business Register and with their tax forms, XBRL will help to reduce administrative burdens for businesses by allowing them to send only once the same financial information.

By law, the Chambers of Commerce must notify the tax authority — in an electronic format — about company registrations, their most significant changes (like closure, liquidation, bankruptcy, changes in company officers and transfers), and financial tax-related information. Business entities must also file their annual accounts with the Business Register in an automatically processable format, i.e., XBRL. (The Chambers of Commerce don’t have the mandate to modify  — in this case, retype — e-signed documents.)

In a technical addendum, the law describes the rules of how this would be accomplished, in particular, the taxonomy to be used by all participants of the Annual Accounts deposit process.

The technical addendum was published in the Official Gazette on December 31, 2008, but another step still was required to start the compulsory XBRL filing: the official website where the Italian GAAP taxonomy is published. This requirement was mentioned in the technical decree but left to be defined by the Ministry. This site finally was launched on February 16, 2009. 

On the same day, compulsory XBRL filings to the Business Register began. Because of the timing of this launch, only 5% of the companies were obliged to file in this fashion — almost 95% of companies already had closed their fiscal year before that date.

According to the law, any update to the taxonomy can be made without passing new law provisions, but with the approval of a national accounting experts committee, technical validation by XBRL editors, testing by the developers of accounting software, and integration into the Business Register environment. It is up to the users to check for updated taxonomy versions on the Ministry’s Web site.

Through this effort the Business Register is moving from a static document repository to a “living” electronic register with clear benefits for users and customers. For example, by using automated procedures, the Business Register now can perform the customary quality assurance at a saving of €0.60 per annual account: in 2010, €0,60 x 950.000 annual accounts = €570.000 in savings. In addition, the same quality assurance tests done by the Register are available for free on the Web site so customers can validate their annual accounts before filing. This application reduces errors and substantially reduces the need to re-file annual accounts’ changes.

Another possibility being explored is using the data collected with balance sheets and profit and loss statements to develop new services directed to SMEs, Chambers of Commerce, and financial analysts. A prototype service, the so-called Bext Service, is being used to produce statistics based on aggregated annual accounts from different companies, selected by geographical area, activity code, legal form, number of employees, and turnover.

As more source data comes available, the statistical studies of the Chambers of Commerce will improve on a national scale in a shorter period of time. For example, the Chamber of Bozen published a March 2009 survey of the economic activity in the province that compared activity through 2006. This was produced with an unavoidable delay that — under the new system — no longer will be necessary.

InfoCamere has also transformed annual accounts from 2005–2007 from PDF into XBRL. The XBRL-enriched reports of annual accounts allows the Chambers of Commerce to produce meaningful statistics studies on the evolution of economic activity on a national or on a local territorial basis — a development that is likely to benefit not only the Chambers, but many other areas of public administration as well.

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director with the Technology and Knowledge Management team of Deloitte & Touche LLP.

Recently Kurt Cagle wrote a post on this blog on alternative representations for XBRL. He freely admitted that his perspective was an interest in the XML language design, not based in domain expertise. In one of his follow-ups to a Comment on his post, he says:

Many of the big headache issues that have faced the XBRL.org committee could be readily solved if they simply admitted the obvious — that XBRL IS XML, not some weird variant, and that the tools exist, are freely available, are powerful, and are preferable to the cumbersome solutions put in place to try to turn XBRL into its own meta-language.

I’m actually somewhat surprised by Kurt’s stance from the outset, namely, that significant and insightful criticism of a design can be accomplished without knowing very much about what business problem the design was trying to solve. In fact, this business problem was stated during the beginnings of XBRL to be very broad – namely, a single language for business reporting that would be applicable to every link in the information supply chain.

XBRL makes an important distinction. Business reporting data has a bimodal distribution. Some data is fact data, produced by many reporters, changing every period. Some data is metadata about the facts, changes slowly, and is primarily produced by sources other than the fact producers. Fact producers must, however, be able to produce and integrate their own metadata, and multiple metadata systems must be able to be interrelated. In a nutshell, this is the business problem that XBRL has historically aimed to solve.

Facts do carry contextual metadata, and XBRL’s design for handling this has changed over time. With the rise of dimensional XBRL, I could easily be convinced that we have not done a great job with context metadata, just OK. Contexts were designed to be shared between many facts, and dimensional XBRL instances can lead to one context per fact.

But Kurt makes this assertion:

…XBRL has the notion of a context, in which all data items from a given report each have a context attribute which points to a corresponding data structure that gives details about the context: the reporting period, reporting agency, any specifics about the preparer, and so forth. Any XML designer would likely fold up all of the key information about that context into a contained element, with an appropriate identifier, and any elements that span contexts could then reference the primary context as an IDREF.

Frankly, I don’t fully understand this. Contexts today are referenced with an IDREF attribute, so exactly what his suggestion would do better rather than different is not clear.

On the metadata side of the XBRL design, taxonomy design is based on XML Schema and XLink. I still wouldn’t trade the immediate value of schema validation for the forward looking (still, after 10 years) value that may, in the future, accrue to using the semantic technologies of RDF/OWL, etc. There are warts on both XML Schema and XLink that I would love to see fixed. On XML Namespaces, too! Fixing any of them would provide more value to XBRL users that adopting RDF/OWL.

So what does it mean to admit the obvious? Here’s what obvious:  XBRL is a database transfer format in XML syntax. Human readability is not a priority. In applications where that is recognized (such as many banking systems), XBRL has been a quiet success. Several large security regulators are hybrids of data transfer and human presentation, and XBRL has been a tough sell and slow going for these applications.

It still is not clear that the Web, defined as the experience of non-expert consumers, has — or should — drive design and technology choices for XBRL. This is a point I made in response to Tim Bray comparing XBRL to RSS in terms of trajectories of technology acceptance. I do not think they are comparable, certainly not just because they are both XML. XBRL both in design and concern (and adoption path) is closer to RDBMS than the Web.

This is NOT because database vendors had any large contribution to the design of XBRL. It is because of the choice of business problem to be solved. It is still true that it is more important for XBRL to displace CSV files and Excel spreadsheets as the data transfer format of choice in corporate culture than it is for XBRL to shift focus to another syntax choice.

On the subject of alternative syntaxes, it is important to make a distinction between a replacement syntax and multiple syntaxes. A replacement syntax faces a powerful hurdle of overcoming the strength of incumbency. You can’t just be as good, you have to be a lot better, to replace an incumbent. Multiple syntaxes face the issue of confusing users. A general rule of language design is to not give multiple ways to “skin the cat.”

It is a truism of XML that you’re only a style sheet away from some other format. But multiple exchange formats seriously detracts from the value of an exchange format in the first place. There is also the problem of exchanging executable code (the style sheet) as well as data.

If XBRL was XML in the "admit the obvious" sense that I think Kurt meant, then there would be no XLink in XBRL. The XML schema would instantiate a particular containment structure that matched the containment hierarchy chosen by … who? And that would make loading thousands of reporting companies filings into a regulatory database easier … how?

I forgot, it’s obvious.

Ashu Bhatnagar is CEO of Good Morning Research, a Softpark company that specializes in building Semantic XBRL technology. The GoodMorningResearch.com machine automates XBRL tagging of Excel data in RDF format with one-click Save As XBRL functionality. Mr. Bhatnagar moderates the Semantic XBRL group on LinkedIn.

Widespread and almost uniform consensus exists on the overarching high-level vision of XBRL and the benefits associated with the concept of XBRL-tagged financial data. However, when it comes to this vision’s implementation, the execution processes, methods, and available software tools are as diverse as the players involved… and there are no clear favorite front-runners.

For example, let’s look at the choice of methods for one of the key steps of the XBRLization process that involves tagging of financial data from a source document with appropriate XBRL tags as predefined in an accepted taxonomy document.

Broadly categorized, the XBRL data tagging processes fall under the following four generic methods:

1. One-Click Automated Data Tagging Method
In an ideal situation, the filers would continue to use their in-house and existing financial reporting tools, including Microsoft Office Excel, and simply click on a button for Save as XBRL. This method of XBRL data tagging would resemble the method when we save a Word document with Save As HTML function for publishing in Web-ready format, or Save As PDF for publishing in a printer-ready format. Clicking on such a button or menu option in an existing software tool would be a nirvana from the usability point of view, because it hides all the complex mark-up details from the user and shifts the arduous and error-prone burden of data tagging from humans to the machine.

Unfortunately, such automated tagging of financial data with taxonomy-defined XBRL tags requires semantic interpretation of data. In other words, it requires computers to recognize financial data almost as well as an accountant trained to interpret matching taxonomy-defined financial metrics. This would be a feat that borders on artificial intelligence and expert systems.

Almost all current knowledge management tools lack the sophistication required to deliver on such a capability. Promising work is being done by researchers in the Semantic Web domain who are actively pursuing knowledge automation tools and technologies. A handful of new patents have also emerged that are pushing the boundaries in this area, but we’re still some time away from converting these "bleeding edge" technologies into fully ready-to-use expert systems.

2. Template/Form Based Data Tagging Method
This method involves creating a small set of pre-approved templates which look like online forms. These forms have XBRL tags pre-attached to the data fields which start out as blank spaces that are filled-in by the filers manually entering appropriate data by rekeying or cutting-and-pasting from other in-house reporting tools.

This form-based method has been adapted by a few regulators around the world. The Securities and Exchange Board of India together with Bombay Stock Exchange are among them, having mandated one hundred listed companies to file in XBRL using its CorpFiling system, which uses pre-tagged blank template forms.

The advantage of this form-based system is that the learning curve associated with XBRL taxonomy, selection of appropriate tags, and validation rules is restricted to a select few professionals who design the templates and forms. In theory, this method should be easier for end-user adoption, because it almost entirely hides the complexity and learning curve of XBRL from the filers who actually fill the forms with their data.

In practice, the disadvantages of this one-size-fits-many method are several, including:

• These generic template-based forms rarely map neatly to any individual company’s filing. In order to keep the complexity of the form low, a minimalist approach is taken whereby fewer than one hundred financial metrics are embedded from an available list of over several thousand metrics as defined by US GAAP or IFRS GAAP. Taxonomy extension, by design, is strongly discouraged and company data forced to fit a generic form.
• With growing use, necessity forces the need to increase the number of templates or forms. When these templates’ count grow beyond a few dozen, the true fragile nature of these templates takes over, and significant IT resources and costs need to be expanded for managing this environment as a document management system with version controls, access privileges, maintenance, and support.
• The transparency of data with detailed drill-down is negatively affected to such an extent owing to limited metrics being tagged that the data has very limited use for a more sophisticated institutional investor or a sell-side/buy-side analyst.

3. Drag-And-Tag Data Tagging Method
This is a more practical approach, a wizard tool-based method where the filers bite the bullet and commit to educate themselves on the subject of XBRL with reasonable level of understanding. Software tools from several vendors now exist that enable a step-by-step wizard-like process that allows appropriate metrics to be selected from a pre-selected taxonomy list, generally organized in a collapsible tree structure for easy navigation. These selected metrics are dragged and dropped, one at a time, by hand, on the appropriate data in a source document (such as Excel or Word),  thereby creating the XBRL mapping or tagging the data.

While the manual process does sound onerous, it gets better with time when the subsequent tagging exercises are able to reuse the mappings from the previous exercise; this greatly simplifies and speeds up the process. The most important criticism of this process remains the time-consuming, error-prone, manual tagging effort, which can only be outsourced to resources that have skills in both accounting and IT. Ensuring high degree of QA and validation checking becomes a significant part of the effort in this tagging method.

4. Automated Semantic Extraction and Man-Machine Expert System Methods
This method involves machine-automated tagging and is based on semantic extraction of meaningful and relevant tags based on prior training of the system with expert knowledge.

One of the many new and emerging examples of this method includes OpenCalais from Thomson Reuters, which automatically creates rich semantic metadata for the submitted content in less than a second. Using natural language processing, machine learning, and other methods, Calais analyzes the document and finds the entities within it. Calais goes well beyond classic entity identification and returns the facts and events hidden within the text as well. However, it is not clear if Calais will remain focused on tagging unstructured text, such as business news, or will it also be used for XBRL tags for company filings as well.

Similarly, the World Wide Web Consortium (W3C) defines the Semantic Web as a vision for the future of the Web, in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available. The Semantic Web will build on XML’s ability to define customized tagging schemes and RDF’s flexible approach to representing data. The first level above RDF required for the Semantic Web is an ontology language, named OWL, to formally describe the meaning of terminology used in Web documents. While machine-automated ontology development tools are an area of advanced research activity and not yet ready for commercial production, early results show sufficient promise that manual tagging of XBRL tags is likely to be a short-lived practice.

In summary, in answering which tagging method is best of all, it seems that over the next few years all of the above methods will be in use at the same time and serve different needs of different users. In the long run, however, machine-automated tagging technology should mature enough to become the primary XBRL tagging method.   

Kurt Cagle is the managing editor of XML Today and is a contributing editor to O’Reilly Media, DevX, and TechNewsWorld.  He is working with Diane Mueller on a general XBRL book for O’Reilly Media to be published in early 2010. Mr. Cagle runs a consulting firm, Metaphorical Web, dealing with future technology issues, XML, distributed computing, and the like. He can be reached by email.  

The Semantic Technologies 2009 Conference in San Jose ended recently, a fascinating event in what I’m coming to consider the most bleeding edge arena of development on the Web today. It was perhaps more notable this year for the surprising number of "suits" in comparison to the crowd in recent years of PhD students shepherded by their respective professors. The Semantic Web is changing, maturing, and reaching a point where development is beginning to move beyond the laboratory and toward real world solutions.
 
Semantic Web and XBRL issues have previously been ably explored on this blog by Andy Greener and Ashu Bhatnagar. I wish to build on their work by comparing semantic technologies.  

The focus of XBRL would seem to be tailor made for the Semantic Web, specifically for technologies such as RDF, RDFa, and OWL. For those of you unfamiliar with the terms, RDF is short for the Resource Description Framework, a rather glorified term that, at the most basic level, provides a way to describe both resources (anything that can be cleanly represented as a data model, such as a quarterly filing, a set of documentation, or an invoice) and the relationships (or links) between those resources. To put things into historical perspective, XLink (which linkbases are built on) was effectively abandoned by the Semantic Web community fairly early on because of the difficulties inherent in dereferencing given content, and RDF became the logical successor.

RDF syntax originally was based in XML, and there is still an XML representation. However, other notations that were less verbose and dense also emerged, including the N3 notation and Turtle notation, which is a superset of N3. XML and Turtle notations are essentially synonymous, and translators for moving between RDF/XML and RDF/Turtle are freely available. Another notation — and one that holds considerably more potential for XBRL — is the RDFa format being supported in the W3C by Mark Birbeck. RDFa provides the same relational structures — such as the fact that a given text block is a date or taxable account total — that can be encoded within normal RDF, but does so using attributes within HTML or other related XML content. This means that an XBRL "report" could be written in a normal HTML markup, but with critical properties encoded via attributes of elements to provide the detailed information for some external processor.

The OWL moniker is a little less obvious. It derives from the Web Ontology Language, the letters inverted in order to create a somewhat easier to remember acronym. OWL is a language for describing classes, class properties, and individual instances of such classes, which sounds somewhat similar to the XML Schema Definition Language (or XSD, as it’s usually now) in that it can be used to describe entities. The difference is that OWL can describe a considerably broader array of relationships, and those relationships can include more sophisticated "graphs" than XML (where a graph can be seen as the foundation of a data structure) because what’s being modeled is knowledge, rather than simply objects. This distinction means that it becomes possible to make inferences by following the relational assertions with the classes. OWL includes support for a query language called SPARQL (a recursive acronym meaning SPARQL Protocol and RDF Query Language), which makes it possible to explore such assertions, with the results being passed back as XML documents.

A second, perhaps more critical, distinction is that unlike XML Schema languages, RDF and OWL assumes an open assertion model. That is to say, the model can change dynamically as new conditions emerge or as alternative needs arise. This differs from an XML model where in general the various properties are arranged in a comparatively limited hierarchical structure (more flexible than a relational database model, but nowhere near as flexible as RDF/OWL). This flexibility can come at some cost, of course. RDF/OWL queries are usually slower than the equivalent XQuery or relational database query operations, but given the use cases involved, this may not in fact be that big of a limitation.

If this sounds similar to how XBRL schemas are created, that’s because it is. An XBRL schema typically is a bundle of assertions, either property assertions such as the fact that a company’s total asset value is a specific value or that the asset value property is associated with the context of 3Q09 earnings. Similarly, that asset’s English long label can similarly be bound to the total-asset-value property. These are all triples, and the RDF/OWL ontology could very easily encompass this information and then produce the output in one of any number of formats as necessary.

Moreover, such assertion chains can produce fairly sophisticated automated analysis. For example, through sets of OWL assertions you could get a listing of companies and their earnings derived from capital  investments in the 3Q09 where the reports are for companies involved in the airline industry, that have P/E ratios exceeding 25, and that are located in the Pacific Northwest. Such a query would be hideously complex in SQL, doable but still complex for an XML database, and relatively easy within an RDF/OWL database.

What’s more, an RDF triple store (which is what such an assertion database is called) can also work with information outside the scope of the XBRL in a principle called Linked Data. For instance, a second triple store might contain a list of biographies of C-level managers for Fortune 1000 companies, including previous companies that they worked for. Because such Semantic databases employ a common underlying transport language (RDF), this means that such SPARQL queries could incorporate both sets of data in order to "pivot" on a given individual in order to see his track record of earnings by company he worked for to correlate whether he’s generally proved an asset or liability to the company.

The advantages inherent in an RDF representation of XBRL should make a compelling case for being able to express XBRL documents in this manner, especially if such information could be extracted from annual reports or other reporting documents via RDFa. Indeed, Diane Mueller, a member of the XBRL.org Board of Directors, and Dave Raggett, a W3C Fellow, a developer of the HTML specification, and one of the key people in the Semantic Web space, are currently working on such a proposal for XBRL.org (full disclosure: I am currently working on a book with Diane on XBRL for O’Reilly Media). Additionally, an XBRL/Semantic Activity Group has been established within the W3C in order to explore these very options, and will meet face-to-face for the first time in conjunction with the XBRL.org annual conference in Paris in July 2009.

The Semantic Web has been moving out of the research space for a few years now, to a certain extent due to a growing understanding of the concepts, maturity of the tools, and opportunities to apply them. XBRL is likely to be one of the more significant use cases for the technology as we move into the distributed cloud of data and all that this implies.