Visualising government benchmarking data

The New Zealand government has released their most recent Benchmarking Administrative and Support Services (BAAS) data. What is interesting about this data is the ability to analyse spend, not at a highly detailed level, but certainly in more detail than previously possible. The information is provided in Excel. What is interesting is what you can do with the Excel data for analysis and, better, display of information graphically, to derive meaning.

I highly recommend taking a look at how this, relatively high-level, information can be presented.

http://zyanbass.appspot.com/

 

 "The New Zealand Treasury runs an annual benchmarking survey across 26 Government agencies in order to gather information on the cost, efficiency, and effectiveness of administrative services delivered by a sample of the state sector. The most interesting portion of the BASS data is about BASS agencies's spend on ICT and that's the data this website (mostly) explores."

 

Before discussing they need for a more detailed taxonomy, I'll make the following observation: The information is available in Excel, against a single set of line-item names, and columns for periods and spend. It is simple, it is easy to use and import, and absolutely ZERO specialist XBRL knowledge is required to import, analyze and gain meaning from that data. There is much to learn from such initiatives.

 

The need for a more detailed taxonomy

 

The need for a more detailed taxonomy of ICT and other government expenditure

Financial reporting and analysis provides value only when used to compare performance against either targets, benchmarks or competitors. Fundamental to the ability to perform effective analysis is the presumption that all reported line items are equivalent across reporting entities. Equivalence of meaning is the critical point, and without adequate definitions, there will be no clarity. Therefore, there needs to be an agreed taxonomy of reporting terms, at sufficient levels of deconstruction to allow the reporting of exactly the information that the entity wants to report, at the level of detail they want to report, linked to a definition that is accepted as the only definition for the reported level of information. 

 

Granularity is also required to ensure that there is minimal overlap between reported items, and little opportunity to report items in one of multiple categories or line items. When considering a Balance Sheet (for example) the first and most obvious question may be "is the reported item an Asset or a Liability?" It cannot be both, or either. Cash is not a liability (unless you are a bank), as is Property Plant and Equipment. Likewise, Accounts Payable and Long Term Debt are liabilities. There is no overlap, and therefore the information, unless you are Worldcom, should only be reported on one side of the ledger of the other. 

 

How does this relate to BASS? While there are over 800 line items in the BASS spreadsheet (many are either summation or calculated lines and not actual reportable line items) there can be overlap or alternative interpretation of how and where information will be reported. This reduced inter-agency or entity performance and expenditure comparisons. 

 

Too often interpretive differences in the meaning of scope of potential meaning of a reported line item can lead to multiple entities reporting the same line item, while defining the detailed content differently. For example one agency could include a software charge as 'Software' while another records it as 'Outsourced' because, while the agency licences it, it is only used to enable an outsourced service. Neither are necessarily wrong. Such use of a common element with slightly different interpretation increases the complexity of comparatives, and increases the amount of manual intervention required to gain meaningful insights from what is theoretically the same information. 

 

Any taxonomy does not need to be complex in and of itself, but it does need to represent an agreed set of line items and associated detailed descriptions. The ICT section of the BASS reporting framework have approximately 125 line items, many of which are summation items. 

 

What is required for effective reporting is not an ever expanding list of potential line items against which to report, but a set of line items elements with very clear definitions. For example, the US-GAAP "Generally Accepted Accounting Principles" taxonomy (in XBRL, which I do NOT recommend) has over 18,000 possible reporting elements, growing every year. In addition, companies can add additional custom items, only increasing the complexity and reducing comparability. Imagine if each BASS reporting entity could choose to add line items. 

 

Instead, keep the list as tight as meaningful, and clearly define the boundaries of each item. In this way is it is possible to reduce the ability to select from any of a number of items depending on your individual interpretation. The benefits? Simplified reporting, greater clarity, and easier comparability between entities, and greater value in the information reported and analysed.

Implications of XBRL on Audit firms

The growing requirement for companies to produce financial statements in the XBRL format is now beginning to impact auditing firms. Audit firms need to plan for the coming wave of additional effort required to provide assurance over XBRL documents, and need to be building the cadres of skilled individuals who will provide such support to audit teams. The phase-in periods are quite different by jurisdiction, as is the expected total additional effort.

Audit and assurance firms should be exploring the potential impact and planning exactly when and how they will build the skills and acquire the tools that they will need to provide assurance over XBRL documents produced by clients.

The potential cost of audit could have a negative impact on market acceptance of XBRL. We must be looking beyond the depth of the pockets of Megaconglomacorp, and understand the impact of XBRL audit on smaller filers and smaller (non Big-4) audit firms.

Go to Non-Sequitur to learn more about Megaconglomacorp: http://www.gocomics.com/nonsequitur/2010/07/21

XBRL is not a "new" standard and is being used around the world, primarily by regulators, to improve the quality of data collected, and to improve the quality and efficiency of analysis of that data. In some cases the information is converted to XBRL by the regulator, and in other cases the reporting companies produce the XBRL. It is company produced XBRL that will be audited.

Challenges

As with any "new" technology or process, audit firms will face challenges as they come to terms with new audit requirements. Certainly an initial challenge will be deciding if and when to develop a cadre of skilled individuals with the knowledge to be able to audit XBRL. Too early and these skills will not be required, too late and the rush will impact operational efficiency. Yet moving beyond the simple “do we / don’t we” question into a time when audit of XBRL is performed, there are three challenges that audit firms and the audit profession needs to consider.

Resources

As we know, the resource requirements of the audit process are not "smooth" through the year - there are clearly definable peaks of resource requirements, falling at quarter-ends and annual reporting events. These peaks vary from country to country depending on the distribution of financial year-ends and the amount of audit activity that gets squeezed into short periods of time.

I use the image of a wave moving toward the beach - the total resource required at any time represents the sea, and the increased time sensitive resource represent the wave. Consider how that wave approaches the shore (the mandatory reporting event) and the way the resource wave grows as it approaches the shore. At that last moment before breaking on the shore, the wave reaches its highest point - the most resources are being applied in that final short moment to ensure a final report.

XBRL reports are, in most cases today and for the coming three to six years, produced "after" the primary report is finalized, as an additional output format. This means that the audit of the XBRL (at least the "final" XBRL) report represents an additional set of highly specialized skill sets added to the top of that resource wave.

Software

Of course auditors mitigate the total resource required through the use of sophisticated software tools. Certainly in the XBRL space, tools are now available that help reduce the total incremental effort, and these tools are evolving quickly. Today however, most software is an extension to validation software and requires the user of the software to be an XBRL "expert".

Standards

Finally there is the problem of auditing standards. As yet there are no standards for the auditing of XBRL. There is guidance (from the American Institute of CPAs - AICPA) for the performance of "Agreed Upon Procedures" (AUP) examinations and reviews of XBRL documents. This assurance however remains "negative" assurance and for internal use only. The XBRL International Assurance Working Group continues to discuss issues around provision of assurance, but does not have the remit to produce an auditing standard.  It is probable that the AICPA's AUP guidance will form the base of any future standard for providing assurance over XBRL.

The lack of an international auditing standard for XBRL will not remove the need for auditors to provide some level of assurance over the XBRL being produced. Audit firms will need to consider their own thresholds of tolerance when providing assurance, and should be lobbying the IAASB and IFAC to fast-track the development of an auditing standard for XBRL documents.

Costs

While my purpose is not to suggest how Audit firms perform assurance, or to indicate the effort involved, it is worth noting that in the United States, AUP engagements for provision of assurance over XBRL documents have resulted in total auditor time of between 50 and 100 hours for the first basic "block tagged" XBRL (tagging of financial statements), and significantly higher for "detail tagged" XBRL (tagging of all financial information throughout the financial statements and notes to the financial statements). Subsequent quarterly "reviews" will take take, but should not require the full 50+ hours. Expect the total hours to quadruple for "detail tagged" XBRL.

The primary cost drivers are the time required to perform the engagements, and the software used in the engagement.  Subsequent engagements should see the total time commitment reduce, and enhancements in XBRL audit software over the coming few years should also reduce the total time required.

The Market and tolerances

This may seem simplistic, but I think it is fair to say that the average auditee will not lightly accept an additional 50 - 100 hours of audit time added simply to audit the XBRL. Those in the XBRL space that are focused only on the Fortune 1000 or FTSE 100/250 do not see this as an issue - these hours will simply be folded into the already thousands of hours and many millions of Dollars or GPB that makes up the total audit cost.

But we must look beyond the depth of the pockets of Megaconglomacorp, and try to understand the cost to the vast majority of other businesses. These are the companies, public and private, that will be paying first to create XBRL and then paying to have the XBRL audited. Therefore we must be looking for ways to reduce the incremental cost the cost of production and audit of XBRL. While process improvements and reductions in reporting time will reduce the cost of producing XBRL, the additional cost of auditing XBRL must also be reduced.

I fully expect software to audit XBRL to improve significantly over the coming couple of years, to the point where the total complexity and cost can be brought down to 'reasonable' levels. Of course, "my" reasonable and an auditee's reasonable may or may not be the same thing.

What will not change will be the need for auditors to gain a working understanding of XBRL, and the need for audit firms to have this additional expertise available.

What to audit in XBRL

Some (but only some) of the XBRL audit issues include:

• Use of extensions – if allowed, why were they created, and is there already an existing element?
• Confirmation that the information is the "same" – This covers more than simply “are the numbers the same”.
• Parentheticals – is all the information appropriately tagged, including information include within labels.
• Calculations – are all calculations appropriately constructed
• Dimensions/Tuples applied
• Label over-rides – have the taxonomy standard labels been used, or company specific labels, and do all labels match the non-XBRL documents
• Taxonomy selection – obviously the correct taxonomy must be used

The list goes on...

What is XBRL

XBRL (eXtensible Business Reporting Language) is an open standard for the interchange of business information between computer systems, by mapping information to entries in logical dictionaries (taxonomies) of business terms, thereby ensuring that the provider and recipient of the information share the commonly accepted meaning of each piece of information. XBRL also allows the creation of custom dictionary entries (extension elements and taxonomies) to allow the reporting or provision of company specific information.

In effect, XBRL allows a “wrapper” of information to be placed around any business "fact", be it a number, a date, or text. In XBRL terminology, this is called "Tagging", or to "Tag" a piece of information. That “wrapper” then ensures that the provider and recipient are referencing the same definition of the information, significantly improving the usability of information by reducing potential errors and confusion over the meaning of any individual piece of information.

Lasagna, or where are all the XBRL Experts (II)?

There's nothing like a really good lasagna - well, I think so. So much so that I also like to have it the next day. A nice, thick lasagna with lots of meat, cheese, and tomato sauce. I also like to add onion, and lots of garlic, which goes with just about everything (except creme caramel of course). I've even been known to enjoy my lasagna the next day cold, cut into thin strips. But that was probably too much information.

Sometimes a message can be the same. If it's an important message (with lots of garlic etc) then it may need to be said again.  And again.

Which brings me to the message. Over a year ago I wrote "Where are the XBRL experts? I pointed out that one of the first things I said when I became Chair of the XBRL US Steering Committee was that if thousands of companies were going to produce XBRL, then we would need thousands of XBRL Experts, not the 10s or 100s that existed at the time. Well, it is more than five years later, and we still need the 1000s, not the 100s that there are today.

So what is happening? Simply put, not enough.

This year 8000+ companies in the US will provide XBRL versions of their financial statements and notes to the SEC. Over the past two years approximately 1500 - 1700 companies have provided XBRL to the SEC. Last year the first 500 or so provided additional data in the form of Detail Tagged XBRL. This year, all 1500 - 1700 companies will be providing detailed tagged financial statement and notes.

Anecdotally, the vendors are getting stretched for resources.

What does this mean?

Bluntly it means that filers who wait will pay. And they will pay top-dollar for resources that will be learning on the job, just like in those wonderful SOX days.

Does that mean the XBRL Mandate should be renamed the "full employment in the Accounting Profession Act II"? No. But it does mean that filers need to get active in their selection process.

Also, filers need to be asking the basic questions - how much of our time will this take? do we need to learn XBRL (and if so, where is the "real" training)? How much will this really cost?

In the UK there is such a shortage of resources, and some of the software is just coming on stream, that there has been an almost Cairo-like rebellion against the HMRC (Her Majesty's Revenue and Customs - their IRS equivalent). HMRC has stood firm, and has pointed out that they fully expect the iXBRL provided to be a minimum set of data, and that errors are expected this year.

The SEC has made no such statement, although from the very beginning they have said that companies get a two years window of litigation relief.

Still, the message is clear - there simply are not enough experts. There weren't enough last year when I said this (and was chastised for saying it).

Now the Blame Game

So who is to blame? Well, no one actually. With no demand, there has been no groundswell of training available, few people learning (because there are been few jobs asking for XBRL skills) and confusing messages. XBRL International has been too busy trying to keep itself afloat through under-subscribed conferences and flat jurisdiction revenue, to be running real training or adequately supporting real training. XBRL US Inc has been too focused on the taxonomy and other projects, but finally is beginning to push the importance of training.

So back to the message - where are all the XBRL experts? The unfortunate answer is - they don't exist, yet. Searches for XBRL-savy resources will become more difficult. Software and services that limit the amount of XBRL a filer actually needs to learn will be important. Also important will be the amount of time required to actually create the XBRL - because more time will almost invariably mean more knowledge required, and more work.

Companies will face the choice of building expertise internally, or outsourcing to those firms with world class processes and software - and hopefully finding companies that will do so at a fair price. After all, the trade-off will be in the cost (in dollars and time) of training someone to use what can be complex tools and processes, vs outsourcing where the prices/time/quality/effort equation delivers a more cost effective result than building the skills internally.

A secret - in my lasagna there are only two things I use "pre-made"; the lasagna pasta and sometimes I use a jar of sauce as my base. I know my limitations, and creating a great tomato based sauce is beyond my expertise, so I "outsource" that. It's still a very good lasagna, if I do say so...

iXBRL: UK companies have a Great Opportunity

Very soon all companies in the United Kingdom are going to be producing iXBRL versions of their financial statements and providing those to HMRC (Her Majesty's Revenue and Customs - the tax department). This provides UK companies, especially all listed companies, with a fantastic opportunity to increase the quality of reporting they provide to investors.

As the iXBRL will be required, it seems to me that there would be little additional effort required to make those iXBRL versions of financial statements available on company websites.

One of the benefits of XBRL is the ability to directly consume the information into computer systems to avoid manual re-keying. This is particularly important if a company wants the analyst community to either cover the company, or at a minimum to include the company as a comparator to a covered company. Any need to re-key information would impose time and error costs on analysts, and will 'de-select' that company from the list of comparators, if it is possible to simply import the information provided by another company in the same industry segment.

Therefore, while there is no requirement for companies to post their iXBRL financials on their website (the SEC requires companies providing XBRL to the SEC to also post the XBRL files on their website), to do so is both simple and provides the investor community with additional information, quickly and at almost no additional cost to the company.

What a great opportunity for UK (LSE and AIM) listed companies to get their message out. Don't put the iXBRL in the logical desk drawer, post the iXBRL financial statements on the company website.

The Logic of the Logical Cave Wall (iXBRL)

Summary

XBRL (eXtensible Business Reporting Language) started life as a dream of freeing information from the tyranny of the logical cave wall, also known as the printed page or computer screen. Now we discover that the information is going to be read by humans after all, so lets make a logical cave wall version of XBRL.

Um, isn't this where we started from, and if so, why not just stick with something simple like, oh, XML, CSV, PDF, Word, or even a web-based form? Because iXBRL will merge the benefits of the logical cave wall while also freeing the information.
 

A dash through history
 

Once upon a time there was a cave wall. Someone drew a picture on that wall. The picture said “There are deer here, cows there, other people (competitors) over there”. So business reporting began.
 

Then humans discovered mud (well, at least for "writing"), and suddenly we could make business reports on mud tablets, dry them in the sun or fire them, and store them in our library. Much of what we have learned about Ur, Ebla and other ancient cities has come from their mud libraries, which were preserved when the libraries were burned, either accidentally or as the result of conflict and invasion. In the case of Ebla, more than 15,000 cuneiform tablets were preserved when the library was burned. These tablets include some of the earliest references to biblical figures and places, provides us with names of cities yet to be discovered, and histories and relationships long lost. Just read this, it’s fascinating.

Okay, I admit I cannot read it either, but if you look very closely, you can probably see the "angle brackets".

But lets move quickly forward in time - past papyrus, velum, then paper, and finally, to the computer screen and the high volume printer. Suddenly we have the opportunity to decouple each word, each concept, from the cave wall, or the mud tablet, or even the printed page.
 

Fantastic, if words and concepts are no longer tied to the page (or logical cave wall) then we can have the computer create the words - we'll start calling it 'data' here - and pass that data to other computers to read and use on our behalf.

But XBRL is just data
 

Enter XBRL, and the crowd goes wild!
 

For too long have we manually entered or computationally created data, printed that data, and then re-keyed or recreated that data in another system, putting human error right in the middle of our carefully conceived plans.
 

With XBRL, we can truly make the human interface redundant. We can create the data in any system we want to, provide that data to "the world" or any subset of “the world” we want to, and have the receiver automatically consume that data into their computer, producing content for decision making - wait for it - printed reports for humans to read. Printed in this context of course meaning anything from a cave wall to a computer screen to an actual printed piece of paper.
 

And here is the most important point, XBRL is data. It is data decoupled from the tyranny of the cave wall, freed from human error, and severed from the need for the human eye to provide the final quality control or audit check of the data.
 

But no one can read data
 

Okay, so we've made the great move. We are now data-centric. The cave wall is done, history, finished - efficiency is in front of us all the way.
 

So, just to remind you, you are sitting in front of your logical cave wall right now, reading what I've painted on that wall.

So now read this:

Okay, I admit it, I can’t really read this either.

Good isn't it. All that data. All that meaning, from computer to computer. We've cut out the person. No errors, fast, but with one small problem; people cannot read data. 

And in the end, if it does not pass the eyeballs test (actually, the brain behind the eyeballs, but lets not be picky), how can we give assurance that all that data is really what we thought it should be. Because assurance, whether by the creator of the data or by an external party, is based on human eyeballs looking at the information and interpreting that information through analysis and comparison with what the reading eyeballs think the information should be.

Lets make "readable" data

The answer - "readable" data, also known as "Inline XBRL" or iXBRL.

The idea is to create a standard that allows XBRL data to be imbedded into an HTML stream such that the HTML page can be displayed with the XBRL data. The XBRL data can then be extracted by the receiving computer(s) and the HTML stripped, leaving the XBRL ready to be stripped of the XBRL and imported into the receiving system. 

Well, I guess it makes sense

Being able to actually see (understandably) what is in an XBRL instance document is important. We use to assume that the software vendors would fill the gap with tools for easy viewing, and in particular that Microsoft would actually build XBRL into its product suite. Maybe they have and will.

But the software vendors simply have not stepped up to the plate adequately to enable ubiquitous and simple viewing of XBRL.

So consumers of XBRL, in particular HMRC (HM Revenue and Customs) in the UK have decided that Human Readable XBRL (iXBRL) is what must be provided, not XBRL. In order to enable this, the "Inline XBRL" specification has recently been approved.

The Cave Wall "wins"

Which brings us right back to the cave call, or the cuneiform tablet. Humans needs to see, with their eyes, the information that is being provided. XBRL is the answer for computer created for computer consumed information, provided there remains the ability to paint a picture on the cave wall.
iXBRL provides XBRL's logical cave wall.

But does that then undermine vendors efforts to actually create XBRL viewer software. I don't think so. Vendors will build applications to meet business needs, and the ability create a logical cave wall version of the information contained in XBRL instance document will not go away.

In addition, iXBRL does at least provide a recognition that the logical cave wall remains a critical part of the business reporting environment. Will iXBRL help expand the range of use-cases for XBRL? Quite possibly, by providing the logical cave wall integrating separable, non-human consumption of the data.