The short answer is not necessarily, but more importantly not only.

Whether the use of XBRL for compliance should be mandatory is increasingly a subject of worldwide discussion. XBRL can just be one of the many options available to businesses for e-filing so that the market can choose to adopt it or not – the Standard Business Reporting (SBR) model in The Netherlands and Australia is an example of this approach. The mandatory option is more common. Two highly visible examples include the Securities and Exchange Commission mandate in the United States and the recent HM (Her Majesty's) Revenue & Customs mandate in the United Kingdom.

To what extent is it possible to prove the benefits of this technology to businesses and other producers of data so that they would use XBRL voluntarily? This topic is extremely relevant for voluntary programs. It is not only about how good or useful the technology or the programs that are based on it is but also about justifying the significant investments that are necessary to set them up and maintain them on the government side.

It would be a mistake to think that demonstrating value in the use of XBRL for data producers is not a key concern also for mandatory programs. The benefits of XBRL for the regulated community are always part of the business case; however, the benefits identified are only the most immediate ones, almost exclusively focused on the data consumption side.

Transparency and comparability of financial information are obviously significant benefits not only for regulators and analysts but also for the broader business community. In general, companies are starting to realize that XBRL is especially effective in achieving those benefits, as opposed to other ways of providing the same information.

Still, the benefits for data producers must be more immediately relevant and meaningful in practical ways to get them excited or even lukewarm. They must see ways in which XBRL can improve their day-to-day operations, or they will continue to see XBRL as just overhead, an additional format in which financial reports can be printed, which brings no more value than doing the same in a Word document or PDF file.

So the real question is: whether XBRL is mandatory or not, when dealing with a domain such as financial reporting, which is objectively complex, and with a technology that is as simple as the domain that it represents, but not simpler (Albert Einstein will forgive me for this adaptation of his thoughts), how do you help businesses become aware of the real benefits enabled by an effective and widely adopted standard for business and financial information, beyond the obvious and mandatory benefits?

The key is to raise awareness on the internal use of XBRL and the standardization that it enables in processes that are not limited to compliance – after all, businesses already comply. Unless you can prove that XBRL is more than yet another way to print and submit your financial statements following the same manual and inefficient processes that are already in place, what's the point?

Once businesses see this, they will understand that XBRL benefits are significant and relate to common “pain points” such as the automation of manual, resource-intensive internal processes – in other words, that XBRL can save them a lot of money. This will lead to the use of existing taxonomies for purposes not limited to compliance and to the creation of new ones for internal use.

I have frequently compared and contrasted the bolt-on, built-in, and deeply embedded approaches to XBRL implementation – see, for example, my blog post that gives pointers to other articles where the three approaches are described – even though it is also a matter of adaptation versus evolution.

Regulators dealing with XBRL-based initiatives try hard to increase the regulated community's awareness of the benefits enabled by the internal use of XBRL. Still, I have observed that while initiatives that are limited to the submission of financial statements are in general less active on this topic, those who advocate broader efforts (typically projects that are SBR-like cross-government or form-based or both) see this idea of raising awareness as a key enabler for their success.

The existence of a mandate rather than a voluntary program, on the other hand, seems to play a different role. Benefits for the regulated community, as mentioned above, are always a key consideration. However, more attention in this case is devoted to making the adoption of XBRL as transparent as possible for data producers. This translates to keeping the processes as they are rather than leveraging XBRL to make a difference in report creation, not just report dissemination.

A typical example is the “XBRLization” of existing filing channels, such as portals or electronic templates already in use. The input remains the same, and it is converted to XBRL on the regulator side. This is perceived as a benefit, as the business does not have to deal with additional complexity but still benefits from transparency and the ready availability of financial information.

Another interesting area to analyze is the role that different types of support for XBRL report creation in software and tools play in different reporting environments. The first important distinction is between solutions that aim only at converting reports to the XBRL format (such as XBRL add-ons to Microsoft Word and Excel) versus those that support the automated creation of XBRL reports built into accounting software and consolidation/reporting applications.

The first type of solutions tend to be popular where mandates relating mainly to financial statement-oriented information are in place, since they represent a shortcut to achieve compliance that does not affect the reporting processes in place. The fact that not affecting those processes also means not achieving any process optimization made possible by the use of XBRL starts being understood only two or three years into the mandate. This generates at least a partial shift towards solutions more integrated into the corporate information system.

The second type of solutions – XBRL support built into accounting software and reporting/consolidating applications – is typically regarded as the preferred approach in environments where XBRL is not mandated, especially in SBR-oriented environments. A similar recurring pattern can be observed, even though the drivers are different. The immediate vendor focus tends again to be on a “bolt-on” support, partly because it is the cheapest and fastest solution (requiring only conversion to XBRL reports that the application can already assemble) and partly because it limits the risk of opening up their proprietary solutions and exposing them to the risk of giving up part of their user-base control. A year or two after implementation, a partial change of strategy usually happens, in some situations due to pressure from users but generally due to the realization that even a minimal switch towards the “built-in” approach can bring benefits for clients and opportunities for up-selling additional services and features. The “deeply embedded” approach, not surprisingly, still occurs only when large businesses become aware of the benefits and develop their own vendor-independent strategy.

While the regulator cannot actively influence the way that vendors support XBRL, the difference in the effort and resources invested in awareness around these issues within the software developer community in presence of a voluntary XBRL initiative tends to be significant.

Another issue, more related to the prevalent thinking among XBRL subject matter experts, is that the primary requirement when defining the architecture of an XBRL taxonomy is ease of comparability with similar taxonomies, so that information can be analyzed consistently across entities and jurisdictions. I am not suggesting that this is not important, it is indeed key, though comparability is not equally important in all XBRL-based initiatives. For example, it is likely to be less relevant where data is not published, as in tax reporting. But again, the focus should not be exclusively on the consumption of the information. Unless the taxonomy architecture is also conducive to the optimization of the creation of XBRL reports – in other words, unless it facilitates the re-use and optimization of the mappings that create those reports – this becomes another factor driving businesses toward a “bolt-on” approach and away from the real opportunities.

A key lesson that can be learned from the SBR approach, particularly in Australia, is that an XBRL taxonomy can and should be a key facilitator not only for the collaboration between multiple agencies and the reconciliation of different domains and reporting requirements in one common dictionary (a very significant benefit in itself, both for the government and the regulated community) but also for educating software developers and businesses on leveraging that common dictionary internally, achieving benefits that are just not available otherwise.

There is a lot that regulators can and should do with XBRL in addition to mandating it. A mandate has obvious benefits in terms of certainty and clarity of direction, which facilitates involvement and commitment of resources from key stakeholders. However, considering the experiences of non-mandatory programs and SBR-oriented projects helps all parties to move past an excessive focus on data consumption and toward a full realization of the benefits of full standardization and integration of the business reporting supply chain that will benefit any kind of XBRL-based initiatives.

Note: The upcoming XBRL International Conference in Brussels will include a training session to explore the role that XBRL Global Ledger (XBRL GL) plays in helping define strategies to deal with these and other issues relevant to the topic. XBRL's Global Ledger: Incorporating It into the Regulatory Environment – Standard Business Reporting, Tax and Statistics is scheduled for 1:30 to 5:30 pm CET on Monday, May 16, 2011.