Recently by Bill Zoellick

Can tags lie? Of course they can. But this is usually not a problem because incorrect or misleading tagging typically causes trouble for the very same people who are doing the tagging. This gives them an incentive to get the tags right. And, if the tags aren't right, there is an incentive to fix them.

Consider an XML-based publishing application. I want to get the tags right so that the presentation comes out right.  Or, in a syndication application, I want my tags to be semantically, not just syntactically correct, because I want someone else to use and link back to my information. Even in an XML-based commercial transaction, where there might in fact be more incentive for me to have the tags tell lies -- increasing the quantity of goods shipped, for example -- the external controls already built into the transaction (counting the quantity of goods received, for example) create an incentive to ensure that the tags tell the truth, reducing overall processing costs and ensuring repeat business.

All of this changes when we use XBRL to communicate financial information to analysts and investors. The incentives to misrepresent information or, in some cases, to hide it altogether, are substantial. This makes XBRL different from many other XML applications and requires a different approach to validation. This is not just a detail. The shift from intrinsic incentives that help get the tagging right to a need for external controls changes the way XBRL is used. It also adds to the list of capabilities that must be in place to build an XBRL market. 

A couple of days ago I wrote about an instance of XBRL's leaping over the market chasm to see use in a no-nonsense, pragmatic, "early majority" application. This isn't just idle marketing chatter. The question of where XBRL stands along the technology adoption curve is one that any organization or company thinking about using XBRL needs to be asking. Just how mature is this technology? How big a bet can you put on it? And if you do make a bet, what steps do you need to take to hedge it?

On Tuesday of last week XBRL-US sponsored a set of presentations in Washington, D.C. focused on "XBRL in Government and Industry." The conference was hosted by the Federal Deposit Insurance Corporation (FDIC), which was appropriate since it was the FDIC that was the source of some of the most significant XBRL activity announced at the conference. 

Here is the news: By October 1 of this year, the more than 8300 banks submitting Call Report data to the FDIC, the Federal Reserve System, and the Office of the Comptroller of the Currency will be required to do so using XBRL. Because most banks submit these reports through use of software and services supplied by a handful of vendors, this requirement will not bring about changes in the internal operations of most banks. The initiative does, however, represent a significant application of XBRL, and opens the door to greater reuse of data and simplification of workflows for other regulatory reporting requirements. It is also a good example of the kinds of broad improvement in financial information communication and processing that XBRL enables.

On Wednesday of last week PR Newswire sponsored a set of webcast presentations on XBRL. This was part of PR Newswire's increasing engagement with XBRL. The company is in the business of publishing earnings releases and would like to see more of them arriving tagged in XBRL. To that end, PR Newswire has entered into a number of agreements with technology firms and others engaged in XBRL. last week's panel discussion showcased an agreement with Rivet Software, in which PR Newswire offers Rivet's Dragon Tag tool, which can be used to set up XBRL tagging of documents from Microsoft Excel and Word. The panel included Campbell Pryde, Executive Director at Morgan Stanley, Wayne Harding, VP Business Development at Rivet Software, Daniel Roberts, National Director of Assurance Innovation at Grant Thornton LLP and Vice-Chair US Adoption for XBRL-US, and Liv Watson, Vice President of XBRL at EDGAR Online, Inc.

The presentations would be useful for anyone wanting an update on XBRL issues. They are available in an online archive. 

As anyone following my contributions on the Gilbane blogs knows, I think that XBRL is an important early-stage standards initiative. I also find myself wondering about the eventual pace and scope of XBRL adoption. In particular, I have been wondering what will drive adoption. Much of the early XBRL activity has been focused around external financial reporting--rather than internal use of XBRL--and I have been wondering where the payoff would be for a company. If the benefits of these early XBRL initiatives go primarily to external users, what is the motivation for the investment?

Today's Supreme Court ruling reversing the decision against Arthur Andersen is big news in the compliance world. My bet is that it will have two important effects--both good. 

The first is that, once again, it will be OK to destroy documents in accordance with a company's retention policy. The second is that it is going to become even more obvious to companies that they really do need to have a carefully designed document retention policy, along with a way to ensure that it is implemented and monitored.

Yesterday the Public Company Accounting Oversight Board (PCAOB) issued its response to concerns that Sarbanes Oxley Section 404 requirements were onerous, unwieldy, and just too expensive. The PCAOB published a policy statement that affirmed the goals and requirements in the regulations implementing Section 404, which requires that public companies have effective internal controls over financial reporting and requires that an independent auditor provides an opinion regarding the effectiveness of these controls. No surprise there. 

What was more interesting and important was that the PCAOB did acknowledge that many first year audit efforts were inefficient and too expensive. The important parts of the statement called for a top-down, rather than bottom-up, approach to internal control assessment. The PCAOB also made important clarifications about the kinds of interactions between auditors and the companies that they audit that are permissible and useful.

Understanding this business about "top-down" and "bottom-up" is easier if you put it in the context of how auditing practice has developed over time. Without that big picture perspective, Section 404 and the PCAOB statements sound like a lot of accounting jargon. But, given the perspective, it is easier to see that we are talking about some fundamental changes--and about expense and confusion emerging from not getting the changes right during this past year.

Today marks the official release of the public draft of the governance, risk management, and compliance (GRC) paper that I have worked on over the past couple months with Ted Frank, of The Compliance Consortium, and others. The writing of the paper was driven by three convictions:

• GRC stands apart:: Governance, risk management, and compliance are all of a piece--and they are related to a coherent set of objectives and practices that are fundamentally different from the other things going on in an organization.
• GRC needs high level attention: Governance, risk management, and compliance comprise a set of concerns and objectives that must be dealt with at the board of directors and senior management level.
• GRC is manageable: Even though governance, risk management, and compliance touch thousands of processes and objectives throughout an organization, there really is a small, manageable set of concerns that should inform board and management decision-making.

I have just finished working on a paper with an industry group that is concerned with compliance issues. The paper takes a broad look at enterprise-wide compliance issues, as distinguished from the trap (an easy one to fall into) of dealing with compliance in a fragmented way, driven by the demands of different (and changing) regulations.

What are the requirements for an enterprise-wide, operational approach to compliance? Well, to get the full answer you will need to read the paper when it comes out in the next few weeks. But there was one requirement--a requirement that I want to talk about here--that ties into the threads and postings about XBRL here on the Gilbane website.

Some of the presentations from the 11th XBRL International Conference, which took place in Boston during the week of April 25, are now available at http://www.xbrl.org/pastevents/. Presentations that I found useful included the Tuesday General Track presentations by Otmar Winzig of Software AG and Elmer Huh of Morgan Stanley, as well as the Wednesday Plenary Session presentation by José María Roldán of the Committee of European Banking Supervisors (CEBS).

The XBRL International website also contains a new, updated version of the XBRL 2.1 specification, along with a newly released conformance suite. There are also two new documents that provide guidance for the construction of XBRL taxonomies. The first is a recommendation for the Financial Reporting Taxonomies Architecture (FRTA), and the second is an FRTA conformance suite.

XBRL is, in some ways, a funny kind of XML language. It doesn't make much use of the capabilities within XML Schema to express relationships such as order, hierarchy, and so on. Viewed strictly as XML, XBRL looks pretty flat, without a lot of contextual constraints.

But that's nonsense, of course. Financial documents are highly constrained and contain intricate interrelationships. XBRL expresses these relationships within "taxonomies"--special XBRL constructs that define business "concepts" and that relate these concepts to each other. The relationships can, in fact, be really complex ...more so than would be possible within a strict XML Schema definition.

Once consequence of this decision to define the bulk of XBRL semantics outside the range of standard XML semantics is that XSLT (XML Stylesheet Language Translator) doesn't work very well as a way to transform XBRL documents into something that humans can read. Since XSLT cannot "understand" the information in the XBRL taxonomy, XSLT does not have the information that it needs to present the "facts" in an XBRL instance in a way that reflects the taxonomy relationships. 

So, how do people produce formatted output from XBRL today? In a Wednesday morning session at the 11th International XBRL Conference, Raymond Lam of BlastRadius explained that the usual solution is to hard-wire all the necessary contextual information into the XSLT rules.  The result is an XSLT stylesheet that contains nearly as many separate template rules as there are separate facts to be presented.  Bummer.