In my previous blogs, I have talked about how the iXBRL document validation process consists of a number of steps, like a ladder. If the validation process returns a failure at one step, it must stop processing immediately. It must NOT move on to the next step.
Why? Because each level of the validation stack is implicitly designed to assume that the previous levels are fully compliant with the taxonomies and other constraints.
Unfortunately, this means that a trivial mistake in the iXBRL document might be enough to halt the review process with most of the testing incomplete.
And so, in the real world, users demand that applications are “helpful”. They want applications which will do their best to continue processing, despite validation errors. But this is unreliable – and dangerous.
Individually innocent mistakes can combine to result in a grossly misleading presentation of an iXBRL report.
Two errors
In preparing an annual report, a filer makes a couple of mistakes.
The draft sent to the auditors refers to an extension taxonomy at http://www.example.com//extension.xsd – with a double-slash where it should have been single-slash.
The auditors take a diligent approach to the review, and consider both the human-readable HTML presentation in the Inline XBRL report and the plainer semantic view that comes from displaying the XBRL facts along with their extension taxonomy labels. Unfortunately, they use a “helpful” XBRL review tool that automatically corrects http://www.example.com//extension.xsd to http://www.example.com/extension.xsd, so the technical error in the schemaRef escapes their notice.
The erroneous double slash is identified after the report is published when someone attempts to view the report using a compliant processor, which flags a fatal error like this:
xbrl.core.dts.UnresolvableReferenceError
The 'schemaRef' element refers to a document at 'http://www.example.com//extension.xsd' that could not be obtained.
The filing team do not want to change the audited report, so they direct their IT colleagues to republish the extension taxonomy at the double-slash location. Unfortunately, the IT team publish an earlier, broken draft of the extension taxonomy, which mixes up the labels for “Trade Creditors” and “Amounts Due to Group Companies”.
Two views
The compliant processor will use the taxonomy at http://www.example.com//extension.xsd, as the XBRL specification requires. The “helpful” processor, which assumes that double-slashes are always a mistake and so ignores them, will use the taxonomy at http://www.example.com/extension.xsd.
Depending upon which processor you are using, you will see a different label displayed alongside the concept metadata. In one case “Trade Creditors”, in the other “Amounts Due to Group Companies”, two significantly different concepts.
Why validation is essential
This kind of problem arises because not all processors adhere to the specifications. The specifications which make up the Inline XBRL stack are designed to ensure that all processors operate the same way – and show viewers the same information. But it only works if validation is treated as non-optional.
This is a real example of an XBRL processing application which, in trying to provide extra functionality for users, contravenes the specification and leaves itself open to mistakes (or even deliberate exploits) which could mislead auditors and investors.