It is important to note that all filings submitted to the SEC pass EDGAR validations otherwise they would not have been accepted by the SEC. The Cloud is a third party’s interpretation of the SEC guidelines as are all the validation tools on the market. It is not an official validation tool of the SEC. When the Cloud was first created, there were concerns that the terminology used, specifically error, was interpreted as not being accepted by the SEC for filing. This was not the case. The Cloud’s term error includes both SEC Rule violations and SEC Warnings. For example, the Cloud lists Error LC3. This Cloud error is actually an SEC warning related to the fact that no numbers can be listed in the element name label. Yet the SEC Rule requires that the element name label exactly match the financial statement label including the numbers. The filer must meet the SEC Rule as they will not be able to submit through Edgar without following it. Yet because the filer is following the SEC Rule, they will get a SEC warning because the label includes numbers and therefore, an error LC3 in the Cloud.

The Cloud has always meant to be used as a collaborative tool to help vendors and filers interpret the SEC EDGAR Rules. If you have ever looked at these rules, you will agree that it is very difficult for a non-technical person to interpret. We have worked with the Cloud’s founder to offer guidance on how we interpret the rules and he has provided us with valuable feedback in our interpretation. This has led to conversations with the SEC and has helped everyone in interpreting the SEC Rules more accurately.

In summary,

• The Cloud Report is not an SEC endorsed tool. It is a third party interpretation of the guidelines.
• All filings run through the Cloud Report were successfully filed with the SEC. The Cloud errors do not mean SEC errors.
• The Cloud Report was meant to be used as a validation tool, not to evaluate XBRL vendors.

The Cloud should not be used as a tool to rank XBRL vendors for several reasons:

• First, all filers have passed the SEC Rules during the filing process otherwise they would not have been able to file. The errors listed on the Cloud Report are SEC warnings.
• Second, XBRL vendors cannot necessarily control what the filer decides to do with regard to the SEC warnings. For example, if Rivet is providing our full service solution to a client, we change the terse element label to reflect the element name so that there is no SEC warning produced. If our client has taken the filing process in house, we cannot control if they make this change or not. Either way is accepted by the SEC, but without updating the terse element label, a warning is produced and on the Cloud, an error is produced. Since this has no bearing on their filing, they usually pass on performing this step.
• Third, the Cloud was meant to be a collaborative tool to be used in the filing process to ensure accuracy. All XBRL vendors have Cloud errors. The Cloud is an interpretation of the SEC guidelines and is not an official SEC validation tool.

If you find that this tactic is being used by a XBRL vendor vying for your business, you may want to ask the following:

• Please show me your percentage of overall errors compared to the other XBRL vendors for all filings to date. All vendors have some Cloud errors because Cloud errors are the same as SEC warnings and are accepted by the SEC for filing.
• Drilldown into a particular filing and have the XBRL vendor show you the actual Cloud error and have them explain in detail how this error impacted the filing.

Please let me know if I can be of any assistance during your evaluation phase. I would be more than happy to work with you in evaluating your XBRL needs.

Most annual reports are now provided online and often in an easy to navigate form via a table of contents and a searchbox capability – like Microsoft’s 2009 Annual Report for example.  This is what I would call level 1 of report transparency: I can view a report online,  navigate the content and find stuff – if I know what I am looking for.

Level 2 of report transparency is concerned with picking out themes or searching for patterns. An important basis for this is that specific terms and numbers are cross-referenced within the report content (as Accounting Elf mentions – for example cross-referencing a footnote to the financial number it relates to). This cross-referencing is something that XBRL tagging can help with in order to facilitate various kinds of content visualization.

One of the simplest forms of content visualization is the tag or wordcloud. Below is an example of a wordcloud extracted from Microsoft’s 2009 Annual Report:

Microsoft 2009 Annual Report Wordcloud

When the words are linked back to the report content this provides another navigation mode and rudimentary ‘theme surfacer’ but actually this wordcloud doesn’t tell us much that is of interest. Text mining products like Clarabridge do a much better job of showing the forest and the trees from a number of perspectives but currently these products are not optimized for searching financial documents including both textual content and XBRL tagged numbers. The whole semantic web area also offers plenty of other avenues for facilitating text mining and content visualization.

Level 3 of report transparency is the stakeholder  interaction layer that includes the ‘crowdsourcing’ capabilities that are such a feature of today’s social media tools – such as commenting, rating, relating, sharing and tagging. How much value this final layer can add to enhancing the communicative value of a financial report is debatable.

But certainly if at least bona-fide shareholders could comment on and rate aspects of a report and tag content items from their own specific perspective then the annual report content will be significantly enriched. This enriched content could become a genuine foundation for a two-way communication stream rather than today’s typical annual report, which smacks of the old command-and-control mentality.

CCM looks for GRC-related events by using GRC rules and regulations to identify these events as they happen in various monitored organization datastreams. Financial reporting, and financial transactions generally, are two key data streams in this respect. The problem is that with a variety of reporting and ERP systems in use in most larger organizations, CCM may have to be adapted one-by-one  to all of them to be effective in a holistic sense.

That’s why data with netadata, using a standard taxonomy like those provided by XBRL, is going to help any CCM effort. In this case, CCM software is looking for specifically tagged data rather than just data, in order to test if a GRC event has occurred.  This should make both finding the data and defining the business rules to apply to that data easier because all data is tagged in the same way and one rule need be defined and  applied to the tagged data.

Here at Rivet we have long advocated XBRL not just as a external compliance reporting tool (e.g. to the S.E.C.) but also as an internal control and communication tool. If your organization is intending to implement CCM, then this could be another example of why using XBRL internally could pay dividends .

1. making the standard easier for developers
2. making XBRL information more comparable across taxonomies
3. making XBRL information easier to consume alone or in combination with information expressed in other standards

Your input on reaching these goals is sought via a well-thought out questionnaire. Now I’m too lazy to fill in questionnaires and I’m not involved in XBRL development but have a few ideas of my own.

I think one of the biggest challenges facing XBRL, and indeed any largely ‘technical’ specification, is connecting the abstract with the concrete or applying the technology to the real-world. So what I would like to see is:

An XBRL Dictionary for Managers

Just a simple regular dictionary format little e-book that just lists say the top 1000 ‘terms’ in XBRL and provides the main tag and closely linked tags for the term and a brief description of use. The kind of thing you might keep on a shelf and refer to now and then even if just for fun. Not a taxonomy document but a conventional dictionary.

A SQL API

Most XBRL data originates from ERP/Reporting systems that use SQL databases so before worrying about OWLS and RDFs why not focus on a SQL abstraction layer that makes getting data from a source RDBMS into a target XBRL instance easier? If this kind of thing can be done via UML models that business analysts and the like can work from, so much the better.

Use Case Drillthroughs

There’s nothing like visual use cases for clarifying how something works. I’d like to see a top level rendered report like an income statement or balance sheet with successive drilldown layers that show tags, possible error paths, source data etc. so that a practitioner can see with a few clicks just how the whole thing hangs together.

Cross Taxonomy Benchmark/KPI Mapping

Taxonomy differences across jurisdictions are a killer for delivering one of the key benefits of XBRL – comparative benchmarking. A mapping layer between jurisdictions for the a set of ‘most used’ tags would be very helpful in enabling the next generation of comparative benchmarking software that depends on XBRL.

XBRL Content Broker Hub

A centralized XBRL content broker hub with a published Web Service API – not a just an RSS feed – would do a lot more to democratize XBRL filed data and make it available to a wider range of consuming applications. For example, I’d like to see ERP systems being able to query this service directly and pull in competitor/peer group data to enable continuous benchmarking at the operational system rather than reporting system level.

Due to the lack of experience most vendors have with Detail Tagging, there has been an overall inability in the industry to properly price the ever important second year of the SEC Mandate for XBRL. UUp to this point most vendors have not been able to put a price on or estimate the amount of time and energy Detail Tagging will consume. The numbers thrown around have not been pretty. Some clients have heard numbers as high as 80-100K for a year of Detail Tagging. That’s one giant filing tax.

Rivet has successfully gone through the process of Detail Tagging with companies such as T. Rowe Price. Our understanding of the scope and depth of this second year has allowed us to fairly price and predict how Detail Tagging will work, both for us and for you.
When evaluating your provider for their ability to provide compliant, timely XBRL service for Detail Tagging, you may want to focus in on the following to ensure that your filing will be taken care of:

• Have them demonstrate the software capabilities with your current filing so you can fully understand what it will take to get the job done.
• Do they have the scalability to handle the additional work requirements of detail tagging for you and all of their clients? Have they shown you?
• Do they have an Industry Expert assigned to your account? Are they an accountant or CPA? Is this service available 24/7? Who exactly will you speak with if there is a problem?
• Confirm that you can be as involved in the process as you desire. At some point, you may want to bring the tagging process in house. Confirm that you can do so at your discretion with continued support if needed.
• XBRL is a mandate. Pick a vendor that will give you tools to analyze the data and allow you to reap the benefits of XBRL. Does your provider include in your package benchmarking and key performance indicators with all SEC XBRL filers in your industry and any others you choose?

Because XBRL is a mandate, there are a lot of players joining the game in the last inning. If your provider didn’t start thinking about XBRL until the ink hit the paper on the mandate at the SEC, they may not have the best technology to handle this very technical interactive data requirement. Sure, a service clerk overseas can write the XML code to produce the XBRL documents, but is this solution scalable, how much is it going to cost, and can you really trust it?

So just in case you are wondering, I’m not suggesting that XBRL is a ‘turkey’ in the US sense of the word – it just makes a great headline. And while you wait for Sage and other ERP vendors to fully embrace XBRL you might like to consider what Rivet’s Crossfire can do to help you to manage your XBRL reporting in the meantime.