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 misstatement.
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.
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”.
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.
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.