Cliff Binstock's presentation #XBRL2012

Cliff Binstock, President of XBRL Cloud spoke at the XBRL US Conference in Austin, TX on September 12, 2012.  The topic was how to prove that your financial informations is correct, complete, consistent, and accurate.  You can watch his presentation.

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.

XBRL Cloud Verification vis-à-vis XBRL US Consistency Suite

One question we get frequently is the how XBRL Cloud's EDGAR Verification Suite compares to XBRL US's Consistency Suite (CSuite).  The short answer is that these are compatible--not competitive--products.  In fact, they work so well together that XBRL Cloud integrates and resells CSuite.

The EDGAR Verification Suite, at a very high level, provides:

1. Automated Validation for XBRL 2.1, EDGAR Filing Manual, U S GAAP Architecture, and other best practices.  This automated validation is designed to assist filers in asserting that they are following all known best practices.
2. Interactive Verification Application that allows users to visualize, manipulate, and inspect an XBRL document.
3. Automated generation of documents to support an Evidence Package.

The Consistency Suite, on the other hand, provides:

1. Automated Validation to help filers assert that they are using the correct tags with appropriate values and contexts.
2. Comparison Application to help filers see how other companies are using tags.

You will want all available tools at your disposal every quarter to help in the verification process.  Using one package or the other will provide a certain subset of the necessary checks:  you would only be verifying some aspects of your filing.

You an learn more about the EDGAR Verification Suite here, or more about the Consistency Suite here.

Verifying XBRL Inconsistencies

One of the questions we get frequently is:  "I have many inconsistencies in my filing, are these okay or not?"  Unfortunately, the answer to this question is not an unequivocal "yes" or "no".  You must verify each inconsistency and determine if that inconsistency is acceptable.

First of all, due to the way calculations are specified in the XBRL Specification, it is entirely possible that different sections of a report reference the same calculation.  For example, a disclosure might provide detail on a primary financial statement.  The detailed disclosure might foot; and some of that detail "bleeds" into, say, the Balance Sheet.  So, if you are looking at a statement like the balance sheet, and see inconsistencies, it is entirely possible that these are acceptable, because there is no way to avoid them.

With the above as background, it is very important to realize that many inconsistencies today are not correct.  The key reasons that inappropriate inconsistencies appear are:

1. It is possible in intend a particular calculation on the financial statement, but have missing or extraneous concepts in the corresponding XBRL calculation.  An example of this is a missing item.  Suppose on your financial statement you have:
   
   Total Current Assets = Cash and Cash Equivalents + Inventory + Accounts Receivables
   
   but you have an XBRL calculation that looks like:
   
   Total Current Assets = Cash and Cash Equivalents + Accounts Receivables
   
   [Note:  "Inventory" is missing].   This type of error might occur if the software you are using does not force the "presentation linkbase"to be in alignment with the "calculation linkbase"
   
2. Incorrect use of negative values or "negated" labels.  Some values (say "Treasury Shares") should always be a positive number.  These might be subtracted, however, from Stockholder Equity.  A common error is to make the number negative (negative shares makes no sense), instead of negating the label (so it is rendered as a negative number) and subtracting the number in the corresponding XBRL calculation.

There are no doubt other numerous reasons why you might see XBRL calculation inconsistencies.  The key point is that you must verify each and every inconsistency to ensure that the XBRL accurately reflects the intent of your report.

Terminology: Verify

Lots of people creating XBRL ask questions like, "Is my XBRL valid"?  Before any other discussions, it's important that we are all using the same terminology.

When you create a business report you want it to be as accurate as possible.  For financial documents (ignoring XBRL), there are various workflows and terminology to help you accomplish this.  You want to check your footing, tick-and-tie, run through checklists, or have someone audit the document.  All
of these activities ultimately have the same goal: to verify that the content of your report is correct.

Automated validation is important--imperative--but it is far from sufficient to completely verify your document.

You can verify an XBRL document via a combination of several disparate processes:
    * Automated Validation
    * Computer-Assisted Review
    * Manual Review

Automated Validation

XBRL was designed to incorporate built-in validation mechanisms such as the "calculation linkbase" which to some extent can check your footing.  Because of the semantic nature of XBRL, there are now additional suites of checks (such as the EDGAR Filing Manual, the Global Filing Manual, the Financial Reporting Taxonomy Architecture [FRTA], and more) which can be fully automated.

Computer-Assisted Review

The goal of computer assisted review is have the computer pick out anomalies, or show you pointed lists.  For example, you might wish to view a short list of the set of unique dates that you used in your filing.  Or perhaps you want to look at concepts that are used in more than one report section (a.k.a. "network", or "extended link").

Computers are also good for searching.  Therefore, you might want to ask questions like "Let me examine all inconsistencies", or "Highlight all negated concepts"

Manual Review

Sometimes you just want to look at, say, the Balance Sheet for a visual review.  It is important to be able to render XBRL documents in your favorite format (like Excel).  Even more important is the ability to interact with the document, since it's hard to see the inter-connectedness of XBRL in a two-dimensional medium.  For example, "Show me the calculation behind this number", or "what does this text block really look like?"

Welcome to the XBRL Cloud blog!

My plan is to provide extremely valuable pointers on how to create accurate
XBRL-based business reports.  Each blog entry will address one specific topic
in detail.

I look forward to any and all feedback on how to improve my messaging or
suggestions for topics that you would like to see covered.

Stay tuned!

Cliff Binstock
President
XBRL Cloud