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.
What would auditing an XBRL financial statement mean? Having
accountants read through the actual XBRL? Probably not, huh? So, they are
dealing with something derived from the XBRL? How do they know that this output
fairly represents the actual XBRL? How do they know that there isn’t something
in the XBRL that isn’t showing up in the rendition that they are reviewing?
And … just what is the "XBRL document?" The result of
XBRL that you can see does not come from just one thing. The representation that
you see on the page draws from many linked files and uses processing
capabilities scattered across other linked files. So, an audit couldn’t really
look just at a single file — the opinion also depends on all the other stuff
that is linked in that makes sense of the particular XBRL instance document.
I’m not arguing that this is not a solvable problem. But I can say that
it is not a SOLVED problem at the moment, and can also say that the solving of
it is going to take some time and some serious effort.
In the meantime, what will happen in the real world is that auditors will
express an opinion on financials that will be represented in PDF or HTML, and
then someone will take those PDF or HTML pages and convert them to XBRL.
That’s fine — the XBRL is WAY more useful than the PDF or HTML — but is also
an obviously flawed approach:
- The XBRL is just a translation of the "real" financials.
We are left with the question of whether it is really right and whether
there were errors in translation.
- More fundamentally, the XBRL is not the official, normative document. It
is, instead, some kind of shadow form of the real thing. That seems like a
pretty poor basis for legally binding data interchange. Someone,
someday, needs to be able to provide a professional opinion about the XBRL,
itself, as a fair representation that does not contain material
Don’t get me wrong … this is not some kind of "fatal flaw" in the
XBRL story. But it is a real problem, and a really good illustration of
kind of difficult problem that emerges, 20 years down the road, as we continue
to pursue the SGML and XML ideal of separating content from presentation. As we
have found again and again, the semantics depend on both content and
presentation. Audited financials are just an extremely demanding application
that underscores that point.