XBRL Cloud Verification vis-à-vis SEC's Validator

We get questions all of the time that sound like "Why do we show up on the dashboard, but the SEC accepts our filing", or "Why do we need any validation besides the SEC's?"

When you submit to the SEC, there is a validation against (mostly) Section 6 of the EDGAR Filing Manual (EFM).  XBRL Cloud and some other vendors provide a very similar validation.  In fact, there is a conformance suite to help ensure that vendors can meet or exceed the SEC's validation.

The EDGAR Filing Manual, is just the beginning.  There are other published documents (such as the U S GAAP Taxonomy Architecture) that describe common Best Practices or simply common XBRL usage.  A high quality validation tool will provide much more feedback than simply EFM-centric validation.

Finally, please remember that verification (of which validation is just one step) is much more valuable and comprehensive than validation.  Please see Terminology:  Verify for a description of verification.

XBRL 2.1 Specification Change

In a somewhat surprising move, XBRL International has recently promoted an XBRL 2.1 errata to RECOMMENDATION status that just-barely changes the behavior of XBRL (see the April XII Instances).  The change is related to the way XBRL performs calculations (and thereby determines "inconsistencies").

Generally, errata aren't even worth mentioning outside the sphere of the XBRL geeks.  Errata are most often used to clarify the specification--especially if vendors have different interpretations.

XBRL International has admirably gone to great lengths to keep XBRL 2.1 stable to make adoption possible.  Therefore, errata have not heretofore been used to change specifications.  To be completely fair, the proposed change is more likely to execute calculations as a "normal" person (read accountant) might expect.

The downside of this change is that nobody in the technical community is 100% sure what the side effects might be for, say, HMRC or SEC filings.  The general consensus (but not scientifically proven) is that there will be no practical effects of these changes.

Nonetheless, this note is just a heads up in case you find that a document that previously validated does not, or that your new document is unexpectedly generating inconsistencies.

---

Hugh Wallis, Senior XBRL Strategist, IBM Cognos FSR, points out:

Surprising and yet not surprising!! The "Proposed Edited Recommendation" (PER) that preceded this publication was on the XII website since the end of October last year (2011) and so stakeholders had ample opportunity to comment and evaluate the changes. This was necessary and appropriate because the changes were of class 3 as defined in section 7.7.2 of the XII process document at http://xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm. i.e. Corrections that MAY affect conformance, but add no new features ... A change that affects conformance is one that:

1. turns conforming data, processors, or other conforming agents into non-conforming agents, or 
2. turns non-conforming agents into conforming ones, or
3. resolves an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.

What was unfortunate was that XII never really publicized this PER on mailing lists such as xbrl-dev or xbrl-public so, unless one was alert enough and constantly checking the XII website, one might not have become aware of it. (I actually pointed out this omission to XII on a number of occasions but it was never addressed prior to publication of the REC). In addition, although the stated date of the new "Recommended" version is in January of this year, the actual REC document didn't appear on the website until some months later.

Nevertheless, in correspondence I have had with both the SEC and the HMRC, both of those bodies have indicated that they are not concerned that the changes will have any effect on the validity or consistency of any filings that they accept so that gives some cause for comfort.