Help Shape the Future of XBRL by Giving Feedback on Long-Term Goals

On February 15, the XBRL International Standards Board (XSB) released “XBRL: Towards a Diverse Ecosystem.” This Discussion Document seeks feedback from all XBRL stakeholders – developers, filers, analysts, investors, etc. -- on the future business requirements and technical roadmap for the data standard. The feedback form beginning on page 17 of the Document can be completed online; a comment letter can also be sent by email. The deadline for all submissions is March 19.

The following Q&A provides details about the XSB’s proposals and the input it seeks. It is based on written and oral interviews with John Turner, chair of the XSB for the past three years, and Chair Designate Chethan Gorur, who will take the reins in April.

1. Let’s start with just a few basics on the XSB. When was it created, who sits on the Board, and what is its mission?

Established in 2006, XSB is a dedicated group within XBRL International tasked with overseeing the production of all technical work products (like XBRL technical specifications) and ensuring all such materials are of uniformly high quality. Its nine members represent a wide cross-section of the XBRL community, representing technical architecture, product management, program management, and business reporting domains. Their biographies and additional information about the XSB can be found on the XBRL website.

2. The Discussion Document “XBRL: Towards a Diverse Ecosystem” that the XSB released last week seeks input from software developers, filers, end users (eg, investors), and others to ensure the standard’s technical evolution over the next decade and the continued pace of XBRL adoption. What circumstances led the XSB to initiate such a dialogue at this time, and what does it hope to accomplish?

There are two things we need to emphasize. First, XBRL has been a very successful and stable standard over the last decade or so. Dozens of countries have adopted XBRL, not only for financial reporting but for a broad range of business and regulatory information.

So we're not talking about changing things. We're not suggesting that people should stop using XBRL the way it is. What we’re doing is long-term planning -- our time horizon is five to ten years. And that’s why we’re reaching out to all XBRL constituencies. We're in an information-gathering mode, seeking to find the best ways of building on a very sound base to get more value out of XBRL for everyone.

Second, we are just at the discovery phase of this process. We’ve come up with specific goals and proposals for each, as described in the Discussion Document. But they’re not set in stone; there’s no fait accompli. It might be that the various XBRL communities want us to focus on these areas, or it might be that they have different ideas.

So what we're looking for is confirmation about whether the goals we’ve come up with make sense. And the best way to do that at this stage is to try and expose those goals as much as possible, then get as many people as we can to tell us what they think of them: let us know whether we’re on the right track or not. We've talked to a lot of people, but not nearly enough.  

To put a point on it: We’re not just going through the motions of asking for feedback as a PR exercise; we’re really interested to hear what people think.

3. OK, let’s talk then about specific goals. As the Discussion Document details, the XSB seeks feedback for its proposals in three main areas:

• Ease of use for developers
• Enabling information comparability around the world
• Simplifying the use of XBRL data for analysis
  

Could you briefly describe the main challenge in each area and the proposals the XSB is contemplating to meet it?

Ease of Use for Developers
The Challenge:  For those of us who deal with XBRL every day, working with it comes naturally. But the XSB is very aware there are plenty of technologists – whether they’re inside accounting and business systems vendors, or working at enterprises, governments, and regulators -- who are much more comfortable using technologies like SQL, Java, and .NET, rather than the XML-based standards that underpin XBRL.

Developers that use XML do so in a variety of ways, ranging from the very simple to the highly sophisticated. XBRL takes advantage of many of the most sophisticated mechanisms contained in the XML standards, which can be challenging. We want to work on ways to make it easier for a broader group of developers to access the standard, and to benefit from the power of XBRL-based reporting – a way to easily move performance reports, which are often inherently complex, across systems and across organizations. We need to introduce these improvements in a way that protects (indeed enhances, via the network effect that more users provides) existing investments.

Proposals: There are a number of ideas that the XSB has set out in the Document. But to choose one, perhaps the area to focus on is the idea of producing a new abstract model (a UML model in all likelihood) of XBRL that provides a way to interact with the standard using a range of alternative methods, including via SQL, via API signatures that would allow interoperable .NET and Java APIs to be constructed, and probably via enhanced interoperability with the W3C’s Semantic Web technologies. This is, obviously, a long- term project, and XBRL as a syntax would continue to be an important component in the mix. Please read the Document (p.12) for some of the other ideas that the XSB is putting forward in this area.

Enabling Information Comparability Around the World
The Challenge:  Since the early days of XBRL, there has been a mantra within the Consortium that XBRL models existing reporting processes, it doesn’t change them. XBRL doesn’t alter GAAP, or impose a standard chart of accounts on companies. The language merely allows, for example, US and Japanese GAAP to be encapsulated inside a taxonomy that can be used to enable electronic reporting of financial statements that conform to those local reporting standards. XBRL doesn’t provide a way to compare information that conforms to different taxonomies, as these are based on different reporting norms.

In effect, while XBRL allows you to move information around at the speed of light, avoiding rekeying and complex transformation processes at every step of a business reporting supply chain, it doesn’t currently allow you to move data between information supply chains. The challenge is to see if XBRL can do more, and provide common standards for the comparison of data for specific purposes.

Proposals: Again, there are a number of ideas in this area, but perhaps the one that we are most interested in gaining feedback on is the potential to use registries to allow the creation of specific comparators between taxonomies. These registries could be used to drive the automated comparison of information across different countries and accounting systems. An example: Petrochemical companies obviously exist across the world, but comparing their financial statements is complicated by the various accounting standards in use. An XBRL registry could be used to declare that, for the purposes of credit analysis, a concept like “cash on hand” under IFRS is the same as “cash on hand” under US GAAP as well as Japanese GAAP. Notice that this would be for a specific purpose and users would need to be aware of the way that purpose is defined. It would not allow an oil company that has to report under US GAAP to suddenly use a Japanese accounting concept. However, users of that information might be prepared to use the registry to line up the performance of many different companies around the world.

Taxonomy profiles, another of our proposals in this area, are a rather different idea. XBRL is a language, a powerful and flexible language that can help you express any kind of performance information imaginable. Its very flexibility can be a problem for some environments, so the profile mechanism is all about narrowing the way that you want XBRL to work in certain circumstances. For example, we could devise a profile that is designed to optimize data collection for prudential regulators. Another is that for internal reporting. The idea is to limit the design choices that are available for certain kinds of reporting models, making it easier for users to embrace XBRL and for software professionals to ensure that their information will be interoperable across systems. It’s not a new idea, but its one that has proven itself in multiple standards environments. Why not XBRL too?

Simplifying the Use of XBRL Data for Analysis
The Challenge: Quite simply, importing XBRL into modern analytical systems can be a chore. The key problem is that wherever extension taxonomies are used, you end up with, in effect, a set of overlapping Venn diagrams, which make managing your analytical models tricky, to say the least.

Proposals: Once again, this challenge is a product of the complexity of financial and performance reporting, rather than XBRL per se – you have this exact same problem if you have companies reporting using CSV files that refer to different definitions in say Word documents (something we’d strongly recommend against, by the way!). We believe it should be possible to develop a number of techniques that make the consumption of XBRL information a simpler exercise. Fundamentally, we want to make it easier to access information in XBRL documents using techniques such as SQL, Sparql, and XQuery. The tricky bit will be to define how consuming applications should deal with the semantics of overlapping taxonomies that define data from multiple source documents.

It should be obvious that much of what we are talking about in this and other areas are not exactly overnight tasks. The XSB is thinking along the lines of a 5-10 year timetable. Agreeing, as a community, exactly what we want to tackle and in what order is the first step.

4. What kind of feedback would be useful from nontechnical and general business users, who may feel hesitant to make recommendations on a complex technology like XBRL?

One thing business people can do is to describe how they would they like to use this technology. There may well be ways they would use the technology that we on the XSB don’t know about, maybe several we had not envisioned. That kind of information is very useful and will help form our long-term strategy, which builds on the existing success of XBRL and is done with a view to compatibility and the existing investments that entities around the world have made in this technology. We want to enhance the return on those investments by making the right decisions now about XBRL’s future direction.

5.  What should XBRL stakeholders do now to inform themselves of the XSB’s proposals and provide the feedback it needs to evaluate them?
 
Start by reading the Discussion Document! Also, be on the lookout for the webinars we are organizing to educate the community about it. Speak to your colleagues in the community, or speak to a member of the Standards Board, but most important, respond to the questions we set out in the paper, either by responding in the form of an email, or via the electronic survey. To get your viewpoint noticed, responding to the survey is by far the most effective mechanism. We want to know what your priorities are, what you think of the ideas that we’ve described in the Document, and we want to hear about your own ideas.

6. And once again, the deadline?

March 19.

Many thanks to John and Chethan for the interview. While they strongly recommend that feedback about the Discussion Document be provided through the channels described above, both are happy to answer any questions about the survey itself that readers post in the Comments section of this blog.