Saving the SEC’s XBRL Program

Some years ago I promised myself that I would not write about XBRL again. I’m breaking that promise. eXtensible Business Reporting Language was a major conceptual breakthrough when it was first developed in 1998. But that was over 20 years ago, and XBRL has progressed little beyond a regulator-demanded user-unfriendly standard with little (voluntary) uptake by report producers, and less evidence that anyone actually consumer and uses native XBRL. There are financial analysts in university (and possibly beyond) who were not born when XBRL was developed. 

At the heart of displeasure with the SEC’s XBRL program at the core of XBRL, the “eXtensible” concept, or as the XBRL community liked to sell the concept, “tell your story, your way”. Thankfully there is a “simple” fix that will save the SEC’s XBRL program, save filers time and money, enable to (almost) pain-free expansion of the program, and increase the likelihood of uptake by consumers of financial information.

Unfortunately, the complexity of XBRL has been a problem from day one. My all-time favourite condemnation of XBRL goes all the way back to 2008 when someone said that XBRL was “using a dinosaur to crack a walnut”.

But first some background:

There are uses for XBRL and XBRL-type reporting technology, but if you are considering going down that route, beware.

The idea was simple; each piece of information in a financial statement/report could be tagged in such a way as to enable the machine to machine communication of financial and business information. The use of a common taxonomy of elements ensured that a piece of data (a “fact”) tagged would mean the same thing to any consumer of that piece of data. Anyone producing financial or business data that was to be shared would be able to ensure that the consumers of that data would know exactly what they were consuming.

Soon, the FDIC (Federal Deposit Insurance Corporation), the US banking regulator, had incorporated XBRL into the Call Report process, ensuring as early as 2004 that all reporting banks in the United States were reporting using a common taxonomy.

All “successful” XBRL implementations share one key factor; they use “closed” taxonomies and do not allow filers or providers to add extension elements.

Today, around the world, XBRL is required by various regulators are the standard for data tagging of financial statements. And in virtually all of those implementations, from the UK to Singapore to Japan and the Netherlands (to name a few), financial statements are provided to the accountant or service provider who then converts Excel into XBRL and then submits that file to the regulator. The regulator then gets to convert the XBRL back into Excel for analysis. Why? Because XBRL is complex and resource-hungry, where the equivalent benefit can be achieved from a spreadsheet.

In the US, the SEC (Securities and Exchange Commission) requires that financial statements in the 10Q, 10K and a range of other filings, be filed in HTML and in an XBRL version. The SEC is also moving to require “Inline-XBRL” filings. Unfortunately, the SEC’s XBRL program remains a burden for which there has simply not been adequate, or even partial, buy-in from the producers or the consumers of companies SEC filings.

Fundamentally the SEC’s XBRL program has been a failure.

Producers of filings to not like it, and consider the production of XBRL to be costly and time-consuming. Don’t take my word for it, read the recent article following the SEC’s roundtable on short-termism from July 2019.

In listing the bullet points from the discussion of how to improve the 10Q process, the final bullet point stated: “And then, what about XBRL? (It was noted here that many issuers find XBRL expensive and very time-consuming and highly doubt its usefulness, not to mention that the SEC has just increased the XBRL burden for companies. Another panellist quoted an issuer as describing it as the “worst part” of the process.)” (emphasis mine).

The SEC itself is a lukewarm user, and if they have ever announced that it was the XBRL that allowed them to spot a case of fraud or financial misstatement then I missed that announcement. 

Data providers such as Yahoo Finance do not bother to provide a “download XBRL” button, and if you want the data, download it in Excel. If you want to XBRL, you’ll need to go to individual filing companies’ websites and download the files from their Invest Relations page, or you will need to go into the SEC’s EDGAR system and search on the company and download the XBRL from the SEC’s site.

While iXBRL (inline-XBRL) will be a boon to consumers of XBRL, at least those reading documents through their eyes, and wondering if the XBRL-tagged facts actually match the information on the printed form, this does little or nothing to solve the main problem; the difficulty of producing the XBRL in the first place.

The “FIX”

The US GAAP Taxonomy, the “dictionary” of allowable tags for financial statements contains over 18,000 elements. Or, as the AICPA said, “The US GAAP Taxonomies contain over 15,000 elements representing commonly reported financial concepts for US GAAP financial statements”. That was a number of years ago. But really? 15,000 “commonly reported”. And this number does not include the plethora of company-specific extension elements that are created every year. 

Fundamentally, every significant implementation of XBRL for the past 15 years (as long as there really have been any implementations of XBRL) has been based on a “closed” taxonomy in which filers are not able to create company-specific extensions.

To fix the SEC’s XBRL program, they should consider the following:

1. Create a limited-set US GAAP Taxonomy. The original estimate was that at fully functioning IS GAAP taxonomy could be created with 4500 elements. While that number clearly is low, it should be possible to create a taxonomy that allows companies to report all “common” concepts in under 10,000 elements.
2. Where companies cannot find the “perfect” fit element, they should use the closest element, and/or revise their reporting to ensure that they are reporting information that is common to their industry of to US GAAP principles.
3. Encourage the development of “templates” for reporting. This will enable companies and service providers to produce XBRL as standard output, saving time and cost, especially for smaller filing companies.

Yes, this sounds simplistic, and it probably will not happen. 

Why not? Unfortunately, there are drivers for the retention of the complex system of company-specific extensions. Simply put, too many jobs are on the line. 

The FASB maintains a team whose job is the “maintain” the US GAAP taxonomy. This includes the annual release of an updated taxonomy in which new elements are added to cater for “common” company-specific extensions. Companies providing software will see their market disappear if the reporting process can be simplified. And of course, if XBRL is actually simplified, then it will become clear that almost anything that can be done with XBRL should be possible with learning engines and (gasp) Excel.  

After all, XBRL has been around for 20 years. That is 20 years of Moore’s Law improving the speed of processes, 20 years of improvements in systems and analytic capabilities, and 20 years in which IA and learning engines have, if not matured, then at least become mainstream.

It is time to fix the SEC's filing program. Fix it, or abandon XBRL.

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.