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
"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.
The 11th International XBRL Conference–the happening thing at the Westin in
Boston for the past two days–was full of first-rate presentations. But I did
have a favorite. It was by Elmer Huh, Executive Director, Global Valuation
Services at Morgan Stanley. Huh’s job is to look behind and beyond the
numbers that companies present in their income statements and balance sheets to
cars, he is professionally trained to look beyond that fresh coat of paint and
new chrome to see the rust, body filler, and worn engine that is
underneath. He showed the conference audience how they might use XBRL to
do this with spectacular effect on a good number of companies.
To understand the full import of what Huh is saying, it helps to understand
something about accounting. It is something that you have probably suspected all
along: Accounting is not about THE TRUTH. (See? You knew that …)
One of the interesting things about the XBRL application space is the way
that it takes some of the problems that have been around since the birth of SGML
and XML and brings them into sharp focus. One of the "foundation"
ideas behind XML — and, before that, SGML — is that the tagged file is the
reference object–its the part you keep–and the printed output is, well …
just output. You can always make another one of those. The idea, as everyone
knows, that you save the document in one form, and then publish and deliver in
Now, suppose that what you are saving–in XBRL–is your firm’s financial
statements. Here is the question: When the auditors show up to offer their
opinion as to whether your financials fairly represent the state of your
company, which form of financials do they offer their opinion on? The XBRL?
Or some kind of printed version?
It’s an important question. It is also something of a trick question. If you
don’t answer "the XBRL version," then it is pretty clear that XBRL is
not really the version that matters. Oops. So much for plans to really
submit financial statements in XBRL to the SEC on anything but a test basis …
Right? But, if you DO answer "XBRL," you quickly come face-to-face
with the fact that nobody has any clear idea of just how you would do that.
XBRL is a business
standard. The immediate users include financial executives, accountants,
analysts, and financial regulators, as well as investors of all sizes. All the
suits and ties in the audience fit the picture of this user community–this sure
does not look like the same crowd that I see at web publishing conferences.
But, scratch the surface, and there is a lot that’s the same. The audience at
this conference is mostly people who are building things. They are early
adopters and vendors and integrators serving early adopters.
One of the most interesting talks in the first set of the Tuesday morning
sessions came from Peter Derby, whose job is to make the SEC more effective and efficient.
His title is Managing Executive for Operations and
Management, Office the Chairman, US. Securities and Exchange Commission.
I am writing at the end of day 1 of the 11th International XBRL conference in
Boston. Over the course of the day I have seen a lot and learned a lot–which I
will share with you in a moment.
But I wanted to start with this end of the day perspective: this is a really
exciting area of activity. If I were starting a small XML company today, this
market would be at the top of my list. It is an EARLY market–no question about
it. It is the kind of conference where the vendors still feel obliged to show
you the actual markup — early, early. But there is energy and opportunity here
that is missing in many of the more mature areas that we cover for the Gilbane
Report. This is an exciting place with a lot of problems yet to solve.
One of the cover stories on the new, April Journal of Accountancy carries the blurb: “Six Reasons to Love XBRL.” The article is actually part of continuing coverage by the American Institute of Public Accountants
(AICPA). The AICPA’s commitment to making CPAs increasingly aware of XBRL
is a good thing if you are interested in seeing more and more ability to do
intelligent processing of financial documents.
One unfortunate thing about the article, though, is that the six reasons to
love XBRL are all focused primarily on its use outside the company–after
you have produced financial statements in XBRL. As I have noted
before, some of the really interesting applications–applications that could
be used as part of an internal control framework–happen only if you begin using
it inside the company and earlier in the process.
I think we’ll get there.
By the way, there is a conference on
XBRL coming up in Boston later this month that you might be interested in if
you are wanting to learn more about XBRL and its applications.