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.

INCOME STATEMENT
Sustainability Revenue
Sustainability Costs

BALANCE SHEET
Sustainability Assets
Sustainability Liabilities

So let’s drilldown on what those 4 lines could actually report…

SUSTAINABILITY REVENUE

Instead of starting with hard stuff like trying figure out how to allocate a proportion of revenues to sustainability, start with the easy stuff: revenue directly attributable to sustainability initiatives in your organization, namely:

- Feed In tariff credits
- Sustainability-related tax credits
- Sustainability bonuses (e.g. for carbon reduction)
- Sustainability grants (e.g. for renewable energy/recycling initiatives)

If these sustainability revenues are zero in your business then you have work to do.

SUSTAINABILITY EXPENSES

Again focus on the stuff that is directly attributable to your sustainability agenda:

- Supply chain auditing costs
- Product lifecycle assessment costs
- CSR report production costs
- Purchase of energy saving equipment etc.
- Purchase of EMS/ESG software
- Cost of sustainability-related certifications (e.g. ISO 14000)

Again if you don’t have any sustainability costs then your investors should be asking the simple question: why not?

Since the savings from sustainability initiatives are not reflected in either the revenue or costs line, they could be posted as a fifth line ‘Sustainability Savings’ that functions like a reverse cost of goods sold reporting line. Naturally these savings would have to be quantifiable and evidenced to qualify.

SUSTAINABILITY ASSETS

Sustainability assets are simply those assets that were specifically purchased to support a sustainability agenda e.g.

- Wind turbines
- Biomass burners
- Solar panels
…etc.

This line clearly reflects your investment in creating a sustainable future for your business as many of these kinds of sustainability assets have lifespans of 10+ years.

SUSTAINABILITY LIABILITIES

This one is a bit trickier. For example you could know that you will be subject to penalties for poor energy performance and disclose that here. Or you could be accruing for the future anticipated costs of a planned supply chain audit or product lifecycle assessment and disclose that here. Or you could be aware that you will be required to replace certain plant to comply with incoming legislation and therefore disclose that future liability here. Imagine what this line could look like on say, BP’s sustainability balance sheet?

Clearly, this is easily the line with the most opacity and the one that regulators must focus their attention on to make as transparent as possible.

One of the steepest parts of the XBRL learning curve is getting your head around taxonomies. Taxonomies are the real drivers of XBRL. Sure you have to tag all the data but without a taxonomy to refer to, those tags add no value whatsoever. The problem with taxonomies is that when you first come up against them your initial reaction is Whoa! Big, gnarly documents with thousands of bits called elements and linkbases and dimensions and tuples – among others.

These are what I call ‘strategic’ taxonomies. They are gnarly because they tackle complex global or country-wide initiatives like IFRS and US-GAAP. The taxonomy is managed by some sort of massive committee and rolling out changes is subject to widespread stakeholder engagement and change management controls. Strategic taxonomies are generally what regulators are focused on to manage sophisticated corporate reporting tasks like the quarterly 10-K in the USA or filing your corporation taxes in the UK.

But there is another type of taxonomy, I’ll it a ‘tactical taxonomy’, that is nothing whatever like this. It is more analogous to the Excel spreadsheets or Access databases that individuals or workgroups create every day in corporate life. A taxonomy that is relatively tiny in scope that helps to solve a specific organizational data management or reporting problem.

Consider this little data set: account, period, currency, amount. That’s a tactical taxonomy.

Or this: project, task, owner, status. That’s a tactical taxonomy.

Or this: employee, business unit, travel miles, carbon emissions. That’s a tactical taxonomy.

Of course I know that the actual taxonomy document is more substantial that the one line in this blog post but the point is that tactical taxonomies are much more limited in scope and impact. They might only be used within a business unit, within your organization as a whole or maybe across your business partner network. Tactical taxonomies are not intended to be used by the world or overseen by external regulators. The data managed by a tactical taxonomy is likely to be for internal consumption only.

We need to make defining, executing and sharing a taxonomy as easy as defining, populating and sharing a spreadsheet. Only the difference between data used by different people in an organization subject to a taxonomy and data used in the same way in a spreadsheet is that the taxonomy ensures one-definition-of-the-truth. This is something spreadsheets alone, and even databases, can’t do. Define once – apply many is the tactical taxonomy mantra.

Once business ‘gets’ tactical taxonomies then they will come to be seen as no different to the document templates used to format your corporate communications. Every spreadsheet application will simply have access to a library of tactical taxonomies so users can pick one to define the data to an agreed organizational standard. Every spreadsheet will have File>New Taxonomy, File>Load Taxonomy and File>Import/Export Taxonomy right there in the menu. So you will know that when you, and anyone else in your organization, plugs numbers into this taxonomy-driven spreadsheet those numbers are subject to the same taxonomy-based definition and mean the same thing.

Tactical taxonomies will become so pervasive, you’ll probably need a taxonomy manager just to look after them all. Another job created by XBRL. Thanks Charlie.

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.

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 .

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?

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.

Drilldown is a commonplace feature of all accounting/ERP/financial reporting software. The aim is to enable you to get from summary to source i.e. to navigate from information to data or from report summary line to transaction posting line. The problem is that every transaction management software package is different so it’s not easy for any reporting package that sits above these to easily understand how to navigate down to the transaction data source without maintaining multiple ‘mapping layers’ into various ERP systems.

XBRL does a great job of standardizing ‘top-level’ report formats to provide an ideal start-point for a drilldown. But without similar taxonomy based tagging at ledger account and perhaps even transaction level line level, it’s hard to create a ‘universal’ drilldown capability that can facilitate a seamless audit trail. And it’s even harder when the source data systems are not part of an integrated ERP suite but spread all over the place as stand alone modules on an organization’s LAN or WAN.

That’s why it’s a shame that ERP vendors have not embraced XML-based web services as well as they might have. Every module in an ERP system essentially functions as both a data receiver and provider  - that’s why traditional data import and export functions are important core functionality in any ERP system. And enabling data consumption and provision programmatically across the Internet is basically the point of web services.

So one way of providing a seamless audit trail, top-down from an XBRL formatted report, is to be able to call a standardized GL/AR/AP etc. web service (or data interface) and pass XBRL tags as a means of navigating the drilldown hierarchy . Of course this also requires XBRL tagging to move down and become embedded at least at sub-ledger account level. Which is one reason why the first stage of XBRL-enabling ERP systems for seamless drilldown, XBRL-GL, is an important step towards this goal.

ERP vendors seem to be genetically pre-disposed to avoiding any kind of standardization that may reduce their competitive differentiation. But here we are just talking about a very simple, but standardized, ‘GET’ interface available for each ledger that would also facilitate ERP-to-ERP interoperability generally. Unfortunately without this kind of joined-up thinking it’s not just the seamless audit trail that remains pie-in-the-sky, it’s also the promise that XBRL holds for improving the control of internal accounting data and re-architecting the way consolidation reporting software functions.

We understand that the main driver for preparedness today is compliance. But here at Rivet we regard compliance as only the start point of a journey towards the kind of financial transformation that has the potential to change the way businesses are managed. We think that once a significant bulk of corporate financial and operational information is available in XBRL format in the cloud and accessible via web services, new ways of business management will emerge – especially in the areas of corporate performance benchmarking, activity alerting and visualization of first national and then global business trends.

So the other kind of preparedness that businesses might be thinking of includes:

1. How are we going to take advantage of all this peer group/competitive data?
2. How are we  going to make the feeds into our XBRL regulatory reporting process slicker and easier?
3. How we are we going to take advantage of XBRL to control our business more effectively?
4. How are we going to leverage our regulatory XBRL output to communicate better with our stakeholders?
5. What new staffing roles and skillsets need to be in place to execute 1-4 above?

Sure. Short-term preparedness is all about compliance and that ‘s probably burden enough for many businesses right now. But it’s worth keeping in mind that there’s more to preparing for the future potential of XBRL than enabling today’s regulatory reporting. As XBRL edges ever closer to the magical ‘tipping point’ of a relatively homogenous corporate financial data ecosystem in various national jurisdictions, it becomes even more important to balance current ‘compliance’ thinking with future ‘control’ and ‘communication’ thinking.