The Matter of Assurance

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
many forms.

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.


  1. Excellent summary of the problem to solve. I have experienced exactly this problem. Having automated production of XBRL, the customer asks – how do I know that what is in the XBRL instance document is what is on the printed financials ? In this particular case, the data source is a single “financial results” database that holds GL, entity information, audit working papers and financial statements disclosures in “one place”.

  2. XBRL’s design has been influenced by both the archival and interchange use cases of XML/SGML. Backing the XBRL instance out of the PDF is passing phase in its history, which can’t pass fast enough for me.
    Since XBRL has advertised itself as reporting neutral, someting other than the technology itself will have to push company managements in the direction of preferring that the XBRL be the legal version. I’ll settle for both being acceptable, as with digital signatures.

  3. It is my understanding that a company keeps several versions of the books. That would make the books a presentation off of the transactional data. So it doesn’t appear to be a problem that XBRL hold transactional data. The various target agencies would have their own presentations. Then, the problem becomes one of ensuring that your presentation matches that of each target agency. That probably means keeping different versions of the XBRL.
    The coorelation between the various XBRL versions would be policy or business rules driven. It would be a matter of XSLT as determined by business rules.
    There never has been, nor will there ever be, one version of the truth. Storying the data is the reality. And, no “storying” doesn’t mean lying. It means contextualizing, or improving its fitness for specific use, or information design.

Leave a Reply