comply-control-communicate

We regard the XBRL journey as having three stages: Comply, Control, and Communicate. If you accept the premise that corporate reporting is essentially about communication, then after more than a decade since XBRL was ‘invented’ we are still at stage one. The few (but growing number) of organizations subject to mandated reporting in XBRL are communicating a relatively limited set of information, mostly financial in nature, that is of interest to a limited number of people.

Stage 2 – Control – refers to the use of XBRL internally within an organization or within closely co-operating industry peer groups, to get better control over the reliability and comparability of data by using XBRL as the basis for a collaborative data standard. Few, if any organizations, are even dabbling with this now. Stage 2 essentially  says ‘If you are spending the time and money to tag your data for regulatory reporting why not get some benefit from this effort within your organization?’.

Stage 3 – Communicate – refers to the pervasive use of multiple XBRL taxonomies to communicate a wide range of financial and non-financial data to produce the kind of holistic reports that communicate organization performance and behaviour to the widest range of stakeholders. It depends on a wide range of XBRL taxomonies being available, for all kinds of data, and global organizations making use of many of them at once. Yikes!

Let’s face it. The value add at stage 1 is minimal. Currently regulators benefit more than the organizations doing the reporting. But as long as regulators make the data available to the cloud-crowd, as the U.S. S.E.C. does for example, we are bound to see the value add rise as innovation delivers new kinds of analytic apps that can the leverage the growing online availability of XBRL data.

Stage 2 is going to be hard. Most organizations are wedded to spreadsheet anarchy and heavily invested in non-taxonomy-aware reporting software, neither of which are suitable for reporting based on a data standard like XBRL. Turning that tanker around is going to be hard and it may hit an iceberg first if ERP vendors don’t adopt XBRL tagging at the transaction level. Take up of XBRL-GL for example has proved a hard sell.

Stage 3 is some way off. The majority of XBRL taxonomies are financially-focused and there’s a lot more to report about an organization than just financial data. There are a few fledgling non-financial XBRL taxonomies (like the GRI’s for example) but not enough to make this stage even viable let alone value-adding.

So we have a long way to go.

But if you believe in the destination, maximum communication of organizational information to the widest range of stakeholders, then the journey has to be worth the effort.

Impact reporting is something that does not get enough attention in the whole sustainability reporting debate with its current focus on ‘integrated’ reporting that merely strives to combine financial and non-financial data in the same reporting context. Impact reporting is about transparency of corporate ‘entity’ impacts so that actual and potential impacts can be better understood. Impact reporting would have made as big a difference in the recent Goldman Sachs debacle as in the current BP situation. An impact entity could just as well be an investment in sub-prime mortgages as an oil rig.

So what is an impact report? Well it’s not a row and column balance sheet or income statement that’s for sure. It’s something that helps you to understand both impact context and impact scenarios by visualizing them. It’s actually about compliance, control and communication but in the service of risk management and mitigation. Let’s work through an example using BP.

BP’s (exploration or upstream) impact report would look like a Google map of the world with pointers for each rig or mining/drilling site. When you click on the pointer, an information panel would popup to surface salient facts such as inputs, outputs, the partners involved and their role. Data to help make the impact context obvious. Drilling down would lead you to deeper information about the data or perhaps to a webcam of the site itself to put it in its real-life environmental context.

At every impact entity (e.g. rig) there would be an option to view risk information that drives specific specific scenarios. Here’s just two example scenarios: disaster and shutdown. In the BP rig example, the disaster scenario could have simply simulated what would happen to the coastline if the rig’s output parameter worth of oil spewed into the ocean. And crucially, links to what plans are in place if the disaster scenario occurs.  The shutdown scenario is equally interesting. This is concerned with what happens if the rig shuts down: less oil in circulation, X number of employees laid off, X less state and federal tax income etc. etc.

What’s also interesting about this kind of transparency is that it actually spreads the responsibility for the risk since the open availability of the data means that presumably others have accepted their part in that risk. Or have ignored it. Transparency also opens up the debate to the cloud crowd who just might come up with some sensible suggestions of their own to help mitigate impact risk.

Clearly impact reporting demands a whole new way to approach reporting that recognizes that reporting transparently is not just about financial data, financial statement formats and accounting and auditing.  It’s about inputs and outputs, it’s about contexts and scenarios, it demands visual and interactive communication that leverages the visual and interactive capabilities of the Internet – not paper or PDFs –  as a delivery platform.

I sincerely hope that when Congress inquires into the whole BP affair and what can be done to avoid or mitigate these situations in future, it remembers to think about how impact reporting could have helped to:

• reduce the ’shock and awe’ from the initial lack of data and risk transparency
• reassure people that some plans/any plans were in place to mitigate risk
• ensure the executives who are ultimately responsible for corporate behavior, better appreciate their responsibilities

If BP had signed off their annual global impact report in much the same way as a SOX report then perhaps this ‘accident’ would have been less likely to happen, BP would not have been faced with a $20 billion cleanup bill and UK pensioners would not face the prospect of a dip in their dividend payments. But first it has to have a global impact report. Maybe there is one. I stand to be corrected.

If any of these 49 percenter companies are reading this – and they probably aren’t – then they should know that Rivet offer an excellent ‘Planning to File in XBRL‘ service. My obviously impartial advice: Get it now – before the stampede in 2011.

There is an impression in the market that once a source document is handed off to a printer, for instance, any changes to that document will be made in one source, both the HTML and the XBRL, alleviating the need to review two separate sets.  While you only need to make one phone call to communicate a change, these changes are typically made by two separate departments, using separate software in a different file. Your thorough review must include both, every time, in order to avoid the possibility of inconsistencies.

The bigger issue here, though, is the archaic method in which finance professionals are asked to produce documents during the financial close and reporting phase. 10-Qs and 10-Ks are created in non-integrated Microsoft Office documents, changes are always manual, and there really is no version control for edits and comments across departments. The truth is that this hasn’t been the best option- it’s been the only option. The times are changing and exciting developments have been made in order to streamline the process. We can now look to partner with a provider who can offer:

• Document creation and management- automate the roll forward quarter to quarter by updating data from the ERP/GL system directly into your final document; ability to change one specific tagged item and automatically update the same item everywhere it is referenced in the document; ability to review and analyze both our public and non public data against peers prior to filing.
• Document content management- maintain a single source with customized workflow rules and security levels; version control and complete audit trail of changes; centralized reviewer notes and comments.
• Export to XBRL and Edgarized HTML from one source- a one stop shop is no longer a myth, it’s a reality.

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.

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?

It is a question of human behaviour. The continual urge to add more and more refinements and additions to the financial reporting process has to be curtailed. There has to be an active effort to remove elements which are now either unneccesary or have been found wanting.

Financial reports have become Maslovian examples of ’self-actualization’ carried to extremes (are you lost yet?)

The GAA aims to ‘nudge’ all the players in the financial reporting debate to make the necessary changes. Now I don’t know about you, but when people nudge me I tend to elbow them back and the next thing you know, the whole bar is on its way to A&E.

The report, based on a series of international round-table events, makes interesting reading with a cup of steaming Bovril in hand. Warren Buffett is presented as the Val Doonican of financial reporting. You can almost hear him singing the Jim Reeves hit ‘Welcome to my world’ from his cosy armchair as he spins another year of stellar performance in the ‘narrative’ of his annual report.

But XBRL gets short shrift.

“We just dump things in”, said one panellist, “and standard-setters don’t think about it as a communication”.

Evidently some view XBRL as a kind of financial landfill that doesn’t smell quite right and seems to be getting bigger all the time. According to the ‘inventor’ of the IFRS XBRL taxonomy, “More and more numbers by themselves are not terribly useful”. A Brit way of saying ‘XBRL sucks’. And another example of mixing up content (numbers) with context (tags). Numbers on their own aren’t that useful whereas tagged numbers can be. But let’s not go there again.

For me, a couple of the panellists hit the nail on the head, with their ‘reporting as communication’ observations:

“Don’t look at financial reports as a compliance document”, he suggested, “look at them as an informational document”.

and

For Bob Herz, the starting point was reiterating that financial reporting was a means of communication between companies and the providers of their capital.

And today, capital means more than just money. We have ‘brand’ and ‘intellectual’ capital for example. Drawing in many more stakeholders (i.e. more than just financial investors) who expect to be communicated to.

For me, the way to simplicity in financial reporting is to apply the Hyman Roth communication test: If it communicates something of interest to a report stakeholder it’s in. If it doesn’t it’s not. Now I’m going to take a nap. Coppola was such a great movie maker wasn’t he?

Educate management that ownership of XBRL submissions belongs to the company, not the outsourcer.

Educate management that this is an accounting and reporting process, not an IT process.

The HMRC requirement does not include a requirement for the auditor to provide assurance on the XBRL tagging of the information submitted. Indeed many of the companies that will be required to submit iXBRL financial statements will be below the audit exemption threshold and will not be subject to an audit.

But as the APB point out:

It is also possible that regulators may require auditors to provide assurance on XBRL-tagged data at some stage in the future.

and…

In the longer term, if XBRL becomes integrated into accounting systems it may be difficult to separate XBRL tagging from accounting services.

What this means for Audit 2.0 firms is that XBRL taxonomy experts will be required as part of audit teams and that a new layer of functionality will be needed in accounting/auditing software. The foundation ‘XBRL layer’ currently required in most accounting software is to integrate tagging and taxonomy lookup capabilities. The second layer to extract and analyze the tags that have been used for audit and compliance purposes.

The Carbon Reduction Commitment (CRC) is a mandatory emissions trading scheme administered by the Environment Agency. In its current form, the scheme is expected to impact between 5,000 – 20,000 businesses in the U.K. CRC also introduces a new reporting term: Along with ‘calendar’ year and ‘fiscal’ year, we now have a ‘footprint’ year. In each footprint year, businesses must monitor their emissions footprint and disclose it in the form of a footprint report.

A league table will be be created to publicise the relative footprints of participating organizations and their progress up or down the table. I don’t expect it to be as popular as the U.K. football Premier League or even the U.S. Major League Soccer for that matter but the CRC League table is clearly another pane in the window of organizational transparency.

As a rough guide, a footprint report is a kind of balance sheet, defined (in outline) as something like:

Emissions Footprint = Total Energy Use – (Exclusions + Exempt Subsidiaries + Electricity Credits)

Participants will have to purchase allowances, sold by the Government, for each tonne of CO2 they emit. At the end of a compliance year, participants must surrender allowances equivalent to their emissions during the year.  If they haven’t bought enough allowances, they must top-up their allowances by buying them from the Government or other participants who are ‘in credit’ with the scheme.

It’s a self-regulating scheme but each participant must create an ‘evidence pack’ to backup their footprint results so their results can be audited by the regulator. The whole thing reminds me somewhat of the trigger for the Reformation in Europe – the sale of indulgences by the Catholic church – but I’m not expecting to see footprint reports being nailed to any church doors anytime soon.

Naturally footprint reports are not truly ‘non-financials’. They do have their their own financial implications. It costs money to register and participate in this mandatory scheme; it will cost money to compile and publish these reports and there are fines for lying about the size of your feet (i.e. non-compliance). Rather like Sarbanes-Oxley, if you don’t practice compliance with good energy governance you risk penalties or at worst imprisonment.

Surprisingly there is no XBRL taxonomy for footprints – probably due to the fact that XBRL advocates are mostly accountants rather than cobblers – but there may well be if the AICPA sustainability initiative gets its way. And when there is we will no doubt see the emergence of a new financial reporting software category: Treadware.