Written by David vun Kannon     Posted on June 30, 2009

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director with the Technology and Knowledge Management team of Deloitte & Touche LLP.

Recently Kurt Cagle wrote a post on this blog on alternative representations for XBRL. He freely admitted that his perspective was an interest in the XML language design, not based in domain expertise. In one of his follow-ups to a Comment on his post, he says:

Many of the big headache issues that have faced the XBRL.org committee could be readily solved if they simply admitted the obvious — that XBRL IS XML, not some weird variant, and that the tools exist, are freely available, are powerful, and are preferable to the cumbersome solutions put in place to try to turn XBRL into its own meta-language.

I’m actually somewhat surprised by Kurt’s stance from the outset, namely, that significant and insightful criticism of a design can be accomplished without knowing very much about what business problem the design was trying to solve. In fact, this business problem was stated during the beginnings of XBRL to be very broad – namely, a single language for business reporting that would be applicable to every link in the information supply chain.

XBRL makes an important distinction. Business reporting data has a bimodal distribution. Some data is fact data, produced by many reporters, changing every period. Some data is metadata about the facts, changes slowly, and is primarily produced by sources other than the fact producers. Fact producers must, however, be able to produce and integrate their own metadata, and multiple metadata systems must be able to be interrelated. In a nutshell, this is the business problem that XBRL has historically aimed to solve.

Facts do carry contextual metadata, and XBRL’s design for handling this has changed over time. With the rise of dimensional XBRL, I could easily be convinced that we have not done a great job with context metadata, just OK. Contexts were designed to be shared between many facts, and dimensional XBRL instances can lead to one context per fact.

But Kurt makes this assertion:

…XBRL has the notion of a context, in which all data items from a given report each have a context attribute which points to a corresponding data structure that gives details about the context: the reporting period, reporting agency, any specifics about the preparer, and so forth. Any XML designer would likely fold up all of the key information about that context into a contained element, with an appropriate identifier, and any elements that span contexts could then reference the primary context as an IDREF.

Frankly, I don’t fully understand this. Contexts today are referenced with an IDREF attribute, so exactly what his suggestion would do better rather than different is not clear.

On the metadata side of the XBRL design, taxonomy design is based on XML Schema and XLink. I still wouldn’t trade the immediate value of schema validation for the forward looking (still, after 10 years) value that may, in the future, accrue to using the semantic technologies of RDF/OWL, etc. There are warts on both XML Schema and XLink that I would love to see fixed. On XML Namespaces, too! Fixing any of them would provide more value to XBRL users that adopting RDF/OWL.

So what does it mean to admit the obvious? Here’s what obvious:  XBRL is a database transfer format in XML syntax. Human readability is not a priority. In applications where that is recognized (such as many banking systems), XBRL has been a quiet success. Several large security regulators are hybrids of data transfer and human presentation, and XBRL has been a tough sell and slow going for these applications.

It still is not clear that the Web, defined as the experience of non-expert consumers, has — or should — drive design and technology choices for XBRL. This is a point I made in response to Tim Bray comparing XBRL to RSS in terms of trajectories of technology acceptance. I do not think they are comparable, certainly not just because they are both XML. XBRL both in design and concern (and adoption path) is closer to RDBMS than the Web.

This is NOT because database vendors had any large contribution to the design of XBRL. It is because of the choice of business problem to be solved. It is still true that it is more important for XBRL to displace CSV files and Excel spreadsheets as the data transfer format of choice in corporate culture than it is for XBRL to shift focus to another syntax choice.

On the subject of alternative syntaxes, it is important to make a distinction between a replacement syntax and multiple syntaxes. A replacement syntax faces a powerful hurdle of overcoming the strength of incumbency. You can’t just be as good, you have to be a lot better, to replace an incumbent. Multiple syntaxes face the issue of confusing users. A general rule of language design is to not give multiple ways to “skin the cat.”

It is a truism of XML that you’re only a style sheet away from some other format. But multiple exchange formats seriously detracts from the value of an exchange format in the first place. There is also the problem of exchanging executable code (the style sheet) as well as data.

If XBRL was XML in the "admit the obvious" sense that I think Kurt meant, then there would be no XLink in XBRL. The XML schema would instantiate a particular containment structure that matched the containment hierarchy chosen by … who? And that would make loading thousands of reporting companies filings into a regulatory database easier … how?

I forgot, it’s obvious.

Written by Ashu Bhatnagar     Posted on June 25, 2009

Ashu Bhatnagar is CEO of Good Morning Research, a Softpark company that specializes in building Semantic XBRL technology. The GoodMorningResearch.com machine automates XBRL tagging of Excel data in RDF format with one-click Save As XBRL functionality. Mr. Bhatnagar moderates the Semantic XBRL group on LinkedIn.

Widespread and almost uniform consensus exists on the overarching high-level vision of XBRL and the benefits associated with the concept of XBRL-tagged financial data. However, when it comes to this vision’s implementation, the execution processes, methods, and available software tools are as diverse as the players involved… and there are no clear favorite front-runners.

For example, let’s look at the choice of methods for one of the key steps of the XBRLization process that involves tagging of financial data from a source document with appropriate XBRL tags as predefined in an accepted taxonomy document.

Broadly categorized, the XBRL data tagging processes fall under the following four generic methods:

1. One-Click Automated Data Tagging Method
In an ideal situation, the filers would continue to use their in-house and existing financial reporting tools, including Microsoft Office Excel, and simply click on a button for Save as XBRL. This method of XBRL data tagging would resemble the method when we save a Word document with Save As HTML function for publishing in Web-ready format, or Save As PDF for publishing in a printer-ready format. Clicking on such a button or menu option in an existing software tool would be a nirvana from the usability point of view, because it hides all the complex mark-up details from the user and shifts the arduous and error-prone burden of data tagging from humans to the machine.

Unfortunately, such automated tagging of financial data with taxonomy-defined XBRL tags requires semantic interpretation of data. In other words, it requires computers to recognize financial data almost as well as an accountant trained to interpret matching taxonomy-defined financial metrics. This would be a feat that borders on artificial intelligence and expert systems.

Almost all current knowledge management tools lack the sophistication required to deliver on such a capability. Promising work is being done by researchers in the Semantic Web domain who are actively pursuing knowledge automation tools and technologies. A handful of new patents have also emerged that are pushing the boundaries in this area, but we’re still some time away from converting these "bleeding edge" technologies into fully ready-to-use expert systems.

2. Template/Form Based Data Tagging Method
This method involves creating a small set of pre-approved templates which look like online forms. These forms have XBRL tags pre-attached to the data fields which start out as blank spaces that are filled-in by the filers manually entering appropriate data by rekeying or cutting-and-pasting from other in-house reporting tools.

This form-based method has been adapted by a few regulators around the world. The Securities and Exchange Board of India together with Bombay Stock Exchange are among them, having mandated one hundred listed companies to file in XBRL using its CorpFiling system, which uses pre-tagged blank template forms.

The advantage of this form-based system is that the learning curve associated with XBRL taxonomy, selection of appropriate tags, and validation rules is restricted to a select few professionals who design the templates and forms. In theory, this method should be easier for end-user adoption, because it almost entirely hides the complexity and learning curve of XBRL from the filers who actually fill the forms with their data.

In practice, the disadvantages of this one-size-fits-many method are several, including:

• These generic template-based forms rarely map neatly to any individual company’s filing. In order to keep the complexity of the form low, a minimalist approach is taken whereby fewer than one hundred financial metrics are embedded from an available list of over several thousand metrics as defined by US GAAP or IFRS GAAP. Taxonomy extension, by design, is strongly discouraged and company data forced to fit a generic form.
• With growing use, necessity forces the need to increase the number of templates or forms. When these templates’ count grow beyond a few dozen, the true fragile nature of these templates takes over, and significant IT resources and costs need to be expanded for managing this environment as a document management system with version controls, access privileges, maintenance, and support.
• The transparency of data with detailed drill-down is negatively affected to such an extent owing to limited metrics being tagged that the data has very limited use for a more sophisticated institutional investor or a sell-side/buy-side analyst.

3. Drag-And-Tag Data Tagging Method
This is a more practical approach, a wizard tool-based method where the filers bite the bullet and commit to educate themselves on the subject of XBRL with reasonable level of understanding. Software tools from several vendors now exist that enable a step-by-step wizard-like process that allows appropriate metrics to be selected from a pre-selected taxonomy list, generally organized in a collapsible tree structure for easy navigation. These selected metrics are dragged and dropped, one at a time, by hand, on the appropriate data in a source document (such as Excel or Word),  thereby creating the XBRL mapping or tagging the data.

While the manual process does sound onerous, it gets better with time when the subsequent tagging exercises are able to reuse the mappings from the previous exercise; this greatly simplifies and speeds up the process. The most important criticism of this process remains the time-consuming, error-prone, manual tagging effort, which can only be outsourced to resources that have skills in both accounting and IT. Ensuring high degree of QA and validation checking becomes a significant part of the effort in this tagging method.

4. Automated Semantic Extraction and Man-Machine Expert System Methods
This method involves machine-automated tagging and is based on semantic extraction of meaningful and relevant tags based on prior training of the system with expert knowledge.

One of the many new and emerging examples of this method includes OpenCalais from Thomson Reuters, which automatically creates rich semantic metadata for the submitted content in less than a second. Using natural language processing, machine learning, and other methods, Calais analyzes the document and finds the entities within it. Calais goes well beyond classic entity identification and returns the facts and events hidden within the text as well. However, it is not clear if Calais will remain focused on tagging unstructured text, such as business news, or will it also be used for XBRL tags for company filings as well.

Similarly, the World Wide Web Consortium (W3C) defines the Semantic Web as a vision for the future of the Web, in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available. The Semantic Web will build on XML’s ability to define customized tagging schemes and RDF’s flexible approach to representing data. The first level above RDF required for the Semantic Web is an ontology language, named OWL, to formally describe the meaning of terminology used in Web documents. While machine-automated ontology development tools are an area of advanced research activity and not yet ready for commercial production, early results show sufficient promise that manual tagging of XBRL tags is likely to be a short-lived practice.

In summary, in answering which tagging method is best of all, it seems that over the next few years all of the above methods will be in use at the same time and serve different needs of different users. In the long run, however, machine-automated tagging technology should mature enough to become the primary XBRL tagging method.   

Written by Kurt Cagle     Posted on June 23, 2009

Kurt Cagle is the managing editor of XML Today and is a contributing editor to O’Reilly Media, DevX, and TechNewsWorld.  He is working with Diane Mueller on a general XBRL book for O’Reilly Media to be published in early 2010. Mr. Cagle runs a consulting firm, Metaphorical Web, dealing with future technology issues, XML, distributed computing, and the like. He can be reached by email.  

The Semantic Technologies 2009 Conference in San Jose ended recently, a fascinating event in what I’m coming to consider the most bleeding edge arena of development on the Web today. It was perhaps more notable this year for the surprising number of "suits" in comparison to the crowd in recent years of PhD students shepherded by their respective professors. The Semantic Web is changing, maturing, and reaching a point where development is beginning to move beyond the laboratory and toward real world solutions.
 
Semantic Web and XBRL issues have previously been ably explored on this blog by Andy Greener and Ashu Bhatnagar. I wish to build on their work by comparing semantic technologies.  

The focus of XBRL would seem to be tailor made for the Semantic Web, specifically for technologies such as RDF, RDFa, and OWL. For those of you unfamiliar with the terms, RDF is short for the Resource Description Framework, a rather glorified term that, at the most basic level, provides a way to describe both resources (anything that can be cleanly represented as a data model, such as a quarterly filing, a set of documentation, or an invoice) and the relationships (or links) between those resources. To put things into historical perspective, XLink (which linkbases are built on) was effectively abandoned by the Semantic Web community fairly early on because of the difficulties inherent in dereferencing given content, and RDF became the logical successor.

RDF syntax originally was based in XML, and there is still an XML representation. However, other notations that were less verbose and dense also emerged, including the N3 notation and Turtle notation, which is a superset of N3. XML and Turtle notations are essentially synonymous, and translators for moving between RDF/XML and RDF/Turtle are freely available. Another notation — and one that holds considerably more potential for XBRL — is the RDFa format being supported in the W3C by Mark Birbeck. RDFa provides the same relational structures — such as the fact that a given text block is a date or taxable account total — that can be encoded within normal RDF, but does so using attributes within HTML or other related XML content. This means that an XBRL "report" could be written in a normal HTML markup, but with critical properties encoded via attributes of elements to provide the detailed information for some external processor.

The OWL moniker is a little less obvious. It derives from the Web Ontology Language, the letters inverted in order to create a somewhat easier to remember acronym. OWL is a language for describing classes, class properties, and individual instances of such classes, which sounds somewhat similar to the XML Schema Definition Language (or XSD, as it’s usually now) in that it can be used to describe entities. The difference is that OWL can describe a considerably broader array of relationships, and those relationships can include more sophisticated "graphs" than XML (where a graph can be seen as the foundation of a data structure) because what’s being modeled is knowledge, rather than simply objects. This distinction means that it becomes possible to make inferences by following the relational assertions with the classes. OWL includes support for a query language called SPARQL (a recursive acronym meaning SPARQL Protocol and RDF Query Language), which makes it possible to explore such assertions, with the results being passed back as XML documents.

A second, perhaps more critical, distinction is that unlike XML Schema languages, RDF and OWL assumes an open assertion model. That is to say, the model can change dynamically as new conditions emerge or as alternative needs arise. This differs from an XML model where in general the various properties are arranged in a comparatively limited hierarchical structure (more flexible than a relational database model, but nowhere near as flexible as RDF/OWL). This flexibility can come at some cost, of course. RDF/OWL queries are usually slower than the equivalent XQuery or relational database query operations, but given the use cases involved, this may not in fact be that big of a limitation.

If this sounds similar to how XBRL schemas are created, that’s because it is. An XBRL schema typically is a bundle of assertions, either property assertions such as the fact that a company’s total asset value is a specific value or that the asset value property is associated with the context of 3Q09 earnings. Similarly, that asset’s English long label can similarly be bound to the total-asset-value property. These are all triples, and the RDF/OWL ontology could very easily encompass this information and then produce the output in one of any number of formats as necessary.

Moreover, such assertion chains can produce fairly sophisticated automated analysis. For example, through sets of OWL assertions you could get a listing of companies and their earnings derived from capital  investments in the 3Q09 where the reports are for companies involved in the airline industry, that have P/E ratios exceeding 25, and that are located in the Pacific Northwest. Such a query would be hideously complex in SQL, doable but still complex for an XML database, and relatively easy within an RDF/OWL database.

What’s more, an RDF triple store (which is what such an assertion database is called) can also work with information outside the scope of the XBRL in a principle called Linked Data. For instance, a second triple store might contain a list of biographies of C-level managers for Fortune 1000 companies, including previous companies that they worked for. Because such Semantic databases employ a common underlying transport language (RDF), this means that such SPARQL queries could incorporate both sets of data in order to "pivot" on a given individual in order to see his track record of earnings by company he worked for to correlate whether he’s generally proved an asset or liability to the company.

The advantages inherent in an RDF representation of XBRL should make a compelling case for being able to express XBRL documents in this manner, especially if such information could be extracted from annual reports or other reporting documents via RDFa. Indeed, Diane Mueller, a member of the XBRL.org Board of Directors, and Dave Raggett, a W3C Fellow, a developer of the HTML specification, and one of the key people in the Semantic Web space, are currently working on such a proposal for XBRL.org (full disclosure: I am currently working on a book with Diane on XBRL for O’Reilly Media). Additionally, an XBRL/Semantic Activity Group has been established within the W3C in order to explore these very options, and will meet face-to-face for the first time in conjunction with the XBRL.org annual conference in Paris in July 2009.

The Semantic Web has been moving out of the research space for a few years now, to a certain extent due to a growing understanding of the concepts, maturity of the tools, and opportunities to apply them. XBRL is likely to be one of the more significant use cases for the technology as we move into the distributed cloud of data and all that this implies.

Written by Dr. A.S. Ramasastri     Posted on June 22, 2009

Dr. A.S. Ramasastri is an Adviser to the Reserve Bank of India (RBI). He has been coordinating the implementation of XBRL-based data submission by banks to the RBI. The views expressed in this blog are that of the author’s and not necessarily those of the Reserve Bank of India.

Looking back now, I think that the idea of XBRL at the RBI originated sometime in 2001 as a way of disentangling a very complex system of data collection from commercial banks.

The process we went through reminds me of an Indian mythological story. In order to destroy an enemy, the Lord Vishnu comes in the form of Vamana, a very short boy, but grows Himself to cover the universe – in exactly three steps

We conquered our data collection demon in a similar three steps.

Step 1 (2001)
About 20 departments of the RBI located in 20 locations receive 250 “returns” from around 200 commercial banks.  These returns  — which are received on  a daily, fortnightly, monthly, quarterly, or in some cases, annual basis — represent data for about 70,000 bank branches.

India has a widely varied economic picture, with different degrees of technology adoption by banks. Modes of communication between the RBI and the commercial banks have been to a great extent dictated by the individual levels of technology adoption.

In 2001, we took a survey of the commercial banks about the mode in use and their preferred mode for submitting returns to the Reserve Bank. The results of the survey revealed that the banks were prepared to adopt a Web-based solution. From this, we developed the concept of a single electronic submission window.

Step 2 (2004)
We successfully implemented a Web-based submission system for a fortnightly return. The commercial banks enter the data or upload an XML file on the Web which, in turn, is pushed to all users within the RBI. Called the On-line Returns Filing System (ORFS), this system reduced time-lag and considerably increased data quality.

Owing to its popularity with both the RBI and commercial banks, the scope of ORFS steadily expanded. As ORFS started to grow, we also began to realize two major limitations:

(1)   Data discrepancies across the returns occurred because many of the returns have common elements.  While they are supposed to match, or at least close enough, there was still enough variability to make the information inconsistent.
(2)   ORFS was visualized only as a data-pushing channel, with no back-end processing, query, and analytical tools. This created a longer-term limitation on the effectiveness of the system.

We had to find solutions to these problems.

Step 3 (2007)
When we looked around, we found that eXtensible Business Reporting Language (XBRL) had been developed to provide solutions to such problems. XBRL taxonomies can serve as standards in data submission, and reporting tools of XBRL can help in providing reasonably good query and analysis facilities. We also found that regulators in a few other countries, including central banks, have started adopting XBRL-based solutions. With the objective of adopting XBRL for return submission by commercial banks, the RBI formed a High Level Steering Committee (under the chairmanship of a deputy governor) that chartered a pilot survey for studying the feasibility of adopting an XBRL-based data submission system.

After considering the views of the commercial banks, the Committee decided to adopt an XBRL-based data submission system in a phased manner. Five returns were considered for the first phase, the important ones being Basel II data reporting system (officially called RCA-II) and financial statements; of these, the first one is already live and others are in the final stages of implementation.

As in the legend, our dwarf effort in 2001 has grown substantially and is influencing India’s adoption of XBRL in all the spheres of financial reporting. The initiative by the RBI probably invigorated efforts surrounding XBRL implementation by other stake holders. Specifically, India’s securities market regulator SEBI is in the process of mandating XBRL data submission of quarterly results by major listed companies. On initiative from the accounting standard body ICAI, India now has its provisional XBRL-India jurisdiction. 

While the data collection demon has not been fully destroyed, he has certainly been humbled…and we anticipate a full victory in the near future.

Written by Scott Gaul     Posted on June 18, 2009

Scott Gaul is the Product Development Manager for MIX, the world’s leading information provider for the microfinance industry and the developer of industry benchmarks and performance analysis of microfinance institutions. He will be making the presentation MIX: A Microfinance Use Case for XBRL at the 19th XBRL International Conference in Paris. 

Imagine this scenario: an entire sector of financial institutions lending solely to low-income individuals without requiring the conventional safeguards of collateral and proper documentation. A superheated investment climate pushes institutions to package these loans into a set of increasingly sophisticated financial instruments and sell them to investors. Many of the institutions are unregulated.

Sound like a recipe for disaster? It’s not the subprime lending market. It’s microfinance.

The parallels have not gone unnoticed. Microfinance institutions (MFIs) have made a business of working with the unbanked for decades, developing new lending and saving strategies tailored to the needs of the poor. As the sector has garnered increasing commercial interest, microfinance practitioners have been working on initiatives designed to address and prevent the types of excess seen in the subprime sector. These initiatives focus on customer protection,ethical principles for microfinance institutions, transparency on interest rates, and improved measurement of social variables.

In large part, the microfinance sector has been able to weather the current crisis. Investment has slowed in some sectors, but global catastrophe has yet to strike.

One factor that we like to think will help microfinance institutions weather this crisis is a long-term focus on transparency. When your core business has a tendency to engender surprise or confusion (“You lend only to poor people? Poor people can open savings accounts?”), transparency has its benefits. Open, voluntary exchange of information enables MFIs to win the trust of investors, regulators, researchers, and other MFIs.

XBRL can be a valuable tool for increasing the transparency of MFIs. Since 2002, the Microfinance Information Exchange (MIX) has operated as a global public platform for exchange of information on microfinance institutions and a central repository for this information. Our organization collects data from 1,400 MFIs for presentation on our website, Mixmarket.org, and incorporates the resulting information into periodic analysis and benchmarks. To better organize, collect, and present this data, over the past few years, we have looked to XBRL as a solution. While our business processes have had to evolve along with XBRL, our small size has also enabled us to adjust quickly.

We have adopted a data-driven model for data collection. Our MFI partners operate in over 100 countries under many different accounting standards and regulatory regimes. The institutions vary wildly in size, capacity, and willingness to share information. Participation is also completely free and voluntary.

For all of these reasons, we cannot easily create or enforce a one-size-fits-all form. Instead, our focus is on providing a framework in which our analysts can extract and model information relevant to the microfinance sector from MFI financial statements such as audits, ratings, and due diligence reports. We have developed a taxonomy based on IFRS combined with disclosure guidelines and expertise from the microfinance sector to capture this information. By the end of the year, we hope to have captured data from over 1,000 MFIs through this taxonomy, and early results show that we can capture a much wider range of data points using this approach.

We expect that one of the main benefits of this approach will be increased financial transparency within the MFI community. As the complexity and detail within MFI financial statements increases, we will be able to capture and share information. In the long run, we hope the taxonomy can also support local regulators and international networks seeking to use standardized reporting as a basis for decision-making. While there are certainly challenges ahead – XBRL has little name recognition or support within the microfinance sector, and we still have not mastered presenting or analyzing XBRL content in a way that would make the benefits easier to communicate – these are a more interesting set of problems now that we have a handle on the data.
 

Written by Geoffroy de Urtasun and Guillaume Fénelon     Posted on June 16, 2009

Geoffroy de Urtasun is Consultant at THEIA Partners, a consulting company based in Paris, helping banks, investment firms, and financial departments to set up and maintain their business and regulatory information supply chains. Guillaume Fénelon is Business Development Director at Infogreffe, the computer platform for French registers.

The first XBRL project in France has been COFINREP, launched by the Bank of France as a national implementation of the European reporting frameworks COREP and FINREP.

XBRL’s implementation in France continues with the development of a new global banking regulatory reporting regime called SURFI, complemented by the business register platform Infogreffe, which uses XBRL for companies’ financial statements.

SURFI Regulatory Reporting to the Bank of France
Within the French territory, the Banking Commission, hosted by the Bank of France, is in charge of supervising banks and investment companies. The Commission expects from financial institutions that they periodically transmit various risk and accounting statements on their activity.

These institutions are required to produce reporting in three frameworks: COREP, FINREP, and BAFI. COREP and FINREP are based on European inspiration, while BAFI reporting includes information necessary for local risk and accounting supervision per French rules as well as monetary indicators for European Central Bank statistics.

Begun in 1993, BAFI has undergone an important overhaul: the SURFI Project. SURFI — Système Unifié de Reporting Financier / Unified System of Financial Reporting — aims to ensure continuity in supervision while simplifying institutions’ reporting burden by rationalizing the circuits of collection and using the XBRL reporting standard.

By using streamlined taxonomies to reduce the required volume of reports, SURFI aims to encourage institutions to concentrate more on the reports’ contents, and enable them to devote more time to analyzing their regulatory indicators. The quality of the reports will be reinforced and the supervisory system may become more accurate.

Currently, French financial institutions have started their own projects to prepare to send their first SURFI reports in July 2010. This again raises the importance of XBRL for the banking sector, already used to produce quarterly COREP and FINREP reports.

XBRL Filing to Infogreffe
Infogreffe is the electronic platform for the 135 French registrars. It leads various dematerialization projects to facilitate access to official data and juridical services: Infogreffe proposes a notification service concerning the establishment of companies, and changes or deletions have been filed electronically since 2007.

As well, Infogreffe recently has developed a filing service for companies’ annual accounts (financial statements) using XBRL.

The project started in late 2007 using the XBRL France (local jurisdiction) taxonomy for French Annual Accounts (“taxonomie comptes annuels”) based on the General Accounting Plan. This taxonomy has been enhanced with company identification data and information added by the registrars to obtain TCA-G and TCA-GI taxonomies — respectively used for the deposit and the publication of French Annual Accounts by Infogreffe.

Since this project was based on XBRL, it went well and fast. After only one year, the French companies’ 2007 financial statements can be downloaded as XBRL instances from the Infogreffe website. Work is now in progress on further developments of taxonomies for other types of annual accounts like banks and insurance companies, and to include consolidated statements and additional fiscal information.

Infogreffe has prepared an Internet portal for electronically filing annual statements. Moreover, Infogreffe is making offline software available to produce annual accounts in the XBRL format.

Guillaume Fénelon comments:

On the Infogreffe website, visitors can find companies’ legal information. Additionally, moving forward, Infogreffe also proposes dematerialized electronic deposit for formalities like registrations and annual statements on an additional portal. Through both of these portals, XBRL becomes the standard of reference for displaying elementary financial information.

Until now, the annual statements were digitized with copies or an extract of some key figures. Now,

With XBRL, the digital statements become more and more detailed. New elementary data items can gradually be compared with each other, and some other legal information will be included, like the identity of the company, or preferential rights and pledges.

The initiative gives rise to the first interactive database of French companies’ legal and financial information.

In June 2009, XBRL projects for accounting software companies are about to start. And each company now can send its annual account reports using XBRL and analyze financial statements from its clients and partners with this technology. XBRL, which had appeared in France through two large regulatory projects (and driven through international initiatives like SEC reporting) now is spreading to every French company.

Please note these useful links:
The SURFI Taxonomy (project in French)
The TCA-G taxonomy  
The TCA-GI taxonomy  

Written by Sean Gilbert     Posted on June 11, 2009

Sean Gilbert is Technical Development Director at the Global Reporting Initiative, the Amsterdam-based provider of the world’s most widely used sustainability reporting framework. He is responsible for overseeing the process that relates to the development of the GRI Reporting Framework (Guidelines, Supplements, and Protocols) and the accompanying resource material. Sean leads the GRI project to develop an XBRL taxonomy for the disclosure of companies’ and other organizations’ sustainability performance.

Integrating Nonfinancial Data into the Decision-Making Process
It’s clear that by providing preparers and users of data with the means to integrate financial and so-called nonfinancial data  (i.e., that which discloses a company’s environmental and social performance), XBRL offers exciting possibilities. The potential for XBRL to provide the users of corporate sustainability performance data with the leverage to push and pull information that meets their requirements is certainly there. That was the thinking behind the first version of an XBRL taxonomy for GRI’s sustainability reporting guidelines, released in 2006.
 
Of course, the users of sustainability data are no longer just those on the fringes of the investment community. Environmental, social, and governance (ESG) information is increasingly sought after by investors wanting to know how well positioned a company is to meet the challenges posed by critical sustainability issues, such as climate change and energy security. Getting this information to investors in an efficient way is key to its integration into the investment analysis process. It should be a top priority for the thousands of companies globally who now spend time and effort disseminating their sustainability performance, with investors as one of the key audiences they seek to engage.

And Not Just for Investors…
But beyond this, it’s not just investors who can benefit from a taxonomy that can be manipulated to provide tailored information on a range of ESG issues. We’re all aware of the rising importance consumers around the world are placing on the provenance and impact of their products and services. Rising in line with this interest, however, is a growing skepticism about the claims companies make for “green,” “environmentally friendly,” or “ethical” products. Providing consumers with data on what, for them, are their most important ESG criteria – whether that be greenhouse gas emissions, labor policies and practices, pollution and effluents, human rights, or a host of other standards — goes some way to counter claims that a company is merely “greenwashing” its publics.

An XBRL taxonomy manipulated by intermediaries to provide Web and other electronic- based information direct to consumers can facilitate this information flow. And providing this data to consumers in such user-friendly forms saves wading through pages of print or PDF information and thus has clear benefits for company, intermediary, and consumer.

A Fine Idea, But a Slow Start
So, how many companies are tagging their sustainability disclosures in this way?  The answer is: surprisingly few. Why is this? Perhaps companies are unaware of the ease with which it can be done. As previous contributors to this blog have noted, XBRL is not that hard an idea to get your head round, and implementing the technology involves very little in terms of investments in time or cash.

But from a slow start, interest is certainly building. GRI is now convening a group of investors and companies to identify how to further improve the taxonomy, such that it can become a routine tool to support company-investor exchange of information. And the first companies are now making their sustainability performance data accessible via XBRL.

The output of GRI’s project will be a second version of the taxonomy that can potentially reduce the time needed to respond to many of the basic information needs of investors and other key stakeholders.

I’d urge companies to get involved now and lead the pack in meeting the needs of the diverse groups of stakeholders who want access to sustainability performance of the companies they invest in, buy from, work for, and supply to. The information is required. The appetite is there. Which companies will benefit from the rewards to be gained through satisfying that appetite?

If you believe in the need for getting this information across, then learning how to use the technology now, while it’s still formative, can only be to your advantage.

Written by Kurt Cagle     Posted on June 9, 2009

Kurt Cagle is the managing editor of XML Today and is a contributing editor to O’Reilly Media, DevX, and TechNewsWorld.  He is working with Diane Mueller on a general XBRL book for O’Reilly Media to be published in early 2010. Mr. Cagle runs a consulting firm, Metaphorical Web, dealing with future technology issues, XML, distributed computing, and the like. He can be reached by email.  

I’ve been working with a fair amount of raw XBRL files recently, both as research for a book and because my interest in the technology comes — not from its use as an accounting format — but because it is an XML format. I suspect, given everything else, that this is a somewhat unusual perspective. An accountant sees an XBRL "document" as a set of "facts" about a given company, and is largely unconcerned about the internal representation of the format because, all other things being equal, this representation is simply "code."

An XML programmer, on the other hand, sees the world a little bit differently. Most XML programmers are not domain experts (save in their own domain of working with code). For them, XML is something that can be queried, transformed, refactored, and bound to all kinds of external representations…something that can be served up on the Web and stored within specialized kinds of databases. The specific element names are pretty much unimportant (for the most part); it’s the broader structural characteristics of the XML that they tend to work with most heavily.

Given that perspective, the XML developer’s view of XBRL is, to put it bluntly, rather grim. XBRL was designed deliberately to have as little structure as possible, with most of this structure added in via linked lists. Structure does exist, of course, but it’s all referential. For instance, XBRL has the notion of a context, in which all data items from a given report each have a context attribute which points to a corresponding data structure that gives details about the context: the reporting period, reporting agency, any specifics about the preparer, and so forth.  Any XML designer would likely fold up all of the key information about that context into a contained element, with an appropriate identifier, and any elements that span contexts could then reference the primary context as an IDREF.

Similarly, linkbases, one of the central characteristics of XBRL, intermix a huge amount of information that needs to be processed and stored in memory in a far more efficient form, typically one that involves resolving three to four orders of links. Yet for some areas such as labels, the most likely putative cases for having more than one label per schema, localization, is generally better solved by having multiple localization files, each of a different language, with the mappings contained in a direct one-to-one manner between schema name and label all the terms in that language. When multiple instances do arise, the XML can be modified accordingly with secondary attributes to discern this information.

The idea in both of these cases is the same. If XBRL.org was to sanction multiple potential acceptable alternate representations of XBRL, each of which could, with acceptable XSLT transformations, be rectified into the canonical format with no loss of representation, such alternate representations would dramatically reduce both the size and the complexity of XBRL documents from the standpoint of the Web developer. In some cases, especially those involving interbank transfer of information in Europe, the multidimensional nature of linkbases satisfy a very real need for hypercube-oriented processing.  In situations like this, the alternative formats may not be tenable. But in most cases (such as the case of the SEC filing data), the hyperdimensional linkages used by canonical XBRL are overkill, and don’t in fact work terribly well on the Web.

This would have additional implications. Functions, which are currently hideously complex, would end up being made much simpler in alternative formats, especially if you can bind them to specific representations that would be appropriate to the format at hand. An XQuery representation, for instance, would work especially well for XBRL stored within XML databases. In a similar manner, such an approach could be used to build JSON representations of data with JavaScript functional layers, something that would go a long way to making XBRL appealing to the Web 2.0 crowd.

The language certainly has most of the mechanisms in place to handle the most complex use cases, but it needs to be able to scale down in those cases where it has less need for the complex processing. Without it, others potential standards (such as the US National Information Exchange Model, or NIEM) may render it obsolete quickly. (I plan a discussion of an NIEM-based XBRL for a future post.)

Like many standards, XBRL needs to be cognizant of changing technologies and requirements, or it runs the risk of becoming ossified, something which benefits no one in the long run.

Written by Thomas Verdin     Posted on June 4, 2009

Thomas Verdin is Chair of the XBRL Europe Business Registers Working Group and CEO at THEIA Partners. He can be reached by email.

Business registrars in Europe have published millions of XBRL files and the number continues to grow. This trend started with companies’ annual accounts and is now spreading to companies’ various legal filings, affording new opportunities to increase transparency, share information among national registers, and facilitate benchmark analysis by end users.

The first XBRL projects in Europe were related mainly to the banking sector, initiated by the Committee of European Banking Supervisors (CEBS) using the Common Solvency Ratio Reporting framework (COREP) and the Consolidated Financial Reporting framework (FINREP) regulatory templates and taxonomies.

Now, however, another use of financial information’s universal language has appeared in Europe, concerning business registers. As business registers operate independently in each country, the push to embrace XBRL has been less coordinated. In fact, at the 2007 XBRL International Conference in Eindhoven and in the months following the conference, it came as something of a surprise to each national business registrar to learn that their neighbor countries also had started XBRL filing. The movement has quickly taken form, however: registers of major countries deal with more than one million national accounts each year, so projects focused on companies’ annual accounts quickly generated hundreds of thousands, then millions, of XBRL files.

On this front, the National Bank of Belgium’s Central Balance Sheet Office is considered among the pioneers. In April 2007 the NBB introduced free online software for drawing up annual accounts in the form of an XBRL file. The NBB now collects more than 92% of Belgian annual accounts in the XBRL format. A recent study estimates the net savings in 2008 of the introduction of online filing of annual accounts in the form of an XBRL file to be  €17.3 million (23% of all filing charges) for Belgian enterprises and €0.5 million (45% of all filing charges) for nonprofit organizations.

Other European business registrars providing XBRL services include the following:

• In the Netherlands, the Kamer van Koophandel has adapted its system to accept XBRL filings for financial statements from the year 2005 and further. Accounting software editors have been associated so that it is possible to send instances directly from their tools.
• The German BunderAnzeiger offers choice among different filing formats including XBRL with the local GAAP taxonomy.
• Infogreffe now publishes the XBRL financial statements of French companies.
• In Italy, it is mandatory to deposit an XBRL instance as a signed annex to the annual account folder for companies closing their fiscal year after February 16, 2009.
• Swedish, Danish, Serbian, and British registrars, among many others, have displayed a strong interest in the XBRL language or already benefit from its advantages.

As it is adopted by an increasing number of business registrars and annual accounts publishers across Europe, XBRL appears as their common language. This represents the first time that the same standard is used by so many registers, and opens opportunities for more efficiency and transparency. Even if local GAAPs remain local, and local regulations differ, it now becomes possible to produce consolidated data of cross-border companies, define transnational sector analysis, and offer new benchmarking capabilities by sharing the same technology.

With these opportunities in mind, some registrars are starting to exchange XBRL information with their neighbors, sharing annual accounts figures but also other economic or legal information like companies’ name and address updates. Making these first cross-border contacts develops new synergies, which may yet lead to defining widespread taxonomies and joining forces on IFRS consolidated accounts, whose quantity is reduced at each national level and therefore are worth a collaborative treatment.

To encourage such interactions, a Working Group has been created within the XBRL Europe association. XBRL Europe connects European jurisdictions and continent-wide organizations like the European Federation of Financial Analysts Societies (EFFAS) and the Global Trust Center (GTC). Its XEU Business Registers Working Group, created in late 2008, offers a place for business registrars and company information publishers to combine efforts and share ideas about XBRL projects and taxonomies.

During its first meetings, the Group prepared an overview of existing initiatives, based on an initial survey with answers from nine project leaders and completed with data from various studies undertaken by the Group’s members. For the next XBRL International Conference in Paris, the EU BR WG wants to transform this overview into a concrete “mapping diagram” showing the similarities and differences that exist across Europe for annual accounts filing with XBRL. This diagram should help identify and establish common and best practices, and consequently increase interoperability.

XBRL affords financial registrars common language and an opportunity for collaboration. Now we must seize the opportunity to speak this language, so that XBRL’s advantages widely enjoyed at national levels become a working reality at the level of all of Europe.
 

Written by Matt Kelly     Posted on June 1, 2009

Matt Kelly is editor-in-chief of Compliance Week, a magazine and online newsletter on corporate governance, risk, and compliance. Prior to his role at Compliance Week, Kelly was a reporter and contributor on corporate compliance and technology issues for magazines such as Time, Boston Business Journal, eWeek, and numerous other publications.

To the best of my knowledge, XBRL has no tag for “disinterest.” That’s unfortunate, since it seems to be the adjective that best fits the U.S. Securities and Exchange Commission these days.

Yes, large U.S. companies must begin filing financial statements tagged in XBRL technology starting June 15. Yes, that’s because the SEC approved an XBRL mandate months ago after years of telegraphing its intention to do so. And yes, the plain truth is that most large filers will muddle through their first XBRL submissions without collapsing into chaos or bankruptcy.

Still, at what should be a proud hour for XBRL, enthusiasm has faded. We’re filing. Oh. Yippee.

The culprit here is new SEC Chairman Mary Schapiro. Given America’s current economic plight, she has astutely identified XBRL for what it is: the financial reporting equivalent of tidying up the front lobby for visitors, while the back of the company crumbles to the ground. Schapiro believes the SEC has much, much bigger problems to worry about than XBRL and the promise of easier comparison of financial data — and she’s right. The agency’s enforcement arm is a mess; the Obama Administration has proposed parceling out most SEC functions to the Federal Reserve or other agencies-to-be-named later as part of Washington’s wholesale regulatory reform. Now is not the time for the SEC to be worrying about tags.

William Lutz, director of the SEC’s 21st Century Disclosure Initiative, admitted as much at a May 28 conference discussing the future of XBRL. “A lot of the commission’s resources are turned internally” right now, he said, leaving “limited resources” for XBRL. Lutz added that two XBRL projects planned for this year — one to tag the Compensation Disclosure and Analysis and another to tag asset-backed securities — have been put off until next year, at least as far as SEC participation goes.

You can’t fault the SEC for putting its resources where they are needed. But it does underscore a fundamental problem with XBRL: adoption not only requires some specific vow of action; it requires maintenance, day in and day out, and that can be hard to deliver. Already, the XBRL taxonomy on the SEC’s website uses U.S. GAAP as of 2008 — not the updated taxonomy for 2009, which was released in April. And neither taxonomy incorporates Financial Accounting Standard No. 165, Accounting for Subsequent Events, approved by the Financial Accounting Standards Board only last week.

Will either of those glitches last very long? Probably not. Still, they probably will last until someone at the SEC decides to fix them — and with the new SEC leadership responding to new problems that will endure for quite a while, expect fewer people at the SEC to be thinking about XBRL. 
 

Written by Michal Piechocki     Posted on May 22, 2009

Michal Piechocki is CEO of the Business Reporting Advisory Group (BR-AG), an international XBRL advisory company. He is an XBRL International Steering Committee At Large Member and also serves as a Member to the XBRL Quality Review Team of the IASC Foundation. He will be conducting Taxonomy Development Training at the 19th XBRL International Conference in Paris. He can be reached by email.

Suppose learning XBRL was like baking a cake. What would be the recipe?

Start with taxonomies, extensions, instance documents, FRTA, FRIS, business reporting supply chain, dimensions, formulas, versioning, rendering, arcs, extended links, layers, references, contexts, units, and footnotes. Mix in modularization strategies, design approaches, and architecture variations. Spice it up with the XBRL specifications technical jargon, and top it off with the inherent complexity of the accompanying accounting standards.

The result: a ten-foot-high gastronomic wonder that XBRL experts have learned to consume.

But… for most users, must XBRL really be so complex?

All students of XBRL, either enthusiastically interested to learn about the standard or obligated to prepare electronic financial reports, must contend with the labyrinth of baffling concepts used by XBRL experts. The complexity multiplies if you are not proficient in English and need both to acknowledge the technical terms and digest and apply the underlying knowledge at the same time.

Fortunately, there exist several levels of understanding of XBRL, and, depending on your needs, you may not be required to tackle many of the its thornier problems at all.

Let’s try to organize the XBRL Knowledge Domain.

First, we have several sources of information:

1.    Official XBRL specifications: recommendations, candidate and proposed recommendations, public working drafts, and requirements documents;
2.    Official XBRL best practices announcements;
3.    Publicly available white papers and educational materials;
4.    Official XBRL taxonomy websites (e.g. IFRS, US-GAAP, Basel II);
5.    Official XBRL projects websites;
6.    Presentations and course materials from XBRL conferences;
7.    Commercial resources and training material.

Key Point: There is an abundance of XBRL explanatory and guidance materials. The majority of them are publicly available. Search and familiarize yourself with available resources.

Second, analyze knowledge requirements from the perspective of the user. The software vendor willing to build XBRL into its products will have demands distinct from those of an SEC filer obligated to prepare a financial report.

Here are the most common user groups from the business reporting supply chain (BRSC):

•    Preparers of reports (e.g., corporate entities);
•    Regulatory bodies (e.g., Securities and Exchange Commission);
•    Software providers (e.g., ERP system providers);
•    Financial services providers (e.g., auditors);
•    Data vendors (e.g., data agencies);
•    Investors and financial analysts (e.g., CFAs).

Each requires different levels of XBRL awareness, and the existing knowledge base provides public and commercial resources for all levels.

For example, preparers do not necessarily need to dive into the deep waters of XBRL specifications. On the contrary, they should be more focused on the scope of the data to be provided within the XBRL report. The complexity of the XBRL standard might therefore be hidden in appropriately constructed software.

The opposite approach should be taken by software vendors, who are encouraged to explore not only the specifications but also the reasoning behind them (to decipher this, historical mailing list discussions can be helpful). This approach should help developers prepare more accurate, valid, and more efficient solutions.

Key Point: Place yourself on the BRSC and approach learning about XBRL from that perspective.

Third, get involved in international discussions and directly contact XBRL experts. The XBRL standard has been here for the past 10 years, and public mailing lists have thousands of individuals who are able to provide answers to your questions. XBRL International, together with regional jurisdictions and over 600 member entities, provide multiple opportunities to understand comprehensively the standard and apply practical solutions to streamline your daily financial routine.

Key Point: Don’t be afraid to reach out to the community or the organization itself. You may encounter individuals who will politely guide you simply to read the manual in case of extremely basic questions, but there is a much higher probability that you will find supportive members pointing you in helpful directions.

The XBRL knowledge domain is admittedly broad. However, step by step, you will find that the initially indigestible cake consists of hot raspberries at the bottom, vanilla ice cream in the middle, and chocolate at the top. It may actually be very tasty.

Welcome to the XBRL emporium!

Written by Ashu Bhatnagar     Posted on May 19, 2009

Ashu Bhatnagar is CEO of Good Morning Research, a Softpark company that specializes in building Semantic XBRL technology. The GoodMorningResearch.com machine automates XBRL tagging of Excel data in RDF format with one-click Save As XBRL functionality. Mr. Bhatnagar also moderates the Semantic XBRL group on LinkedIn. His earlier posts on the Semantic Web and XBRL are Introducing Semantic XBRL and Semantic XBRL Transparency, Verification, and ‘Raw Data Now’.

We all use Google for Web searches on a daily basis and admire the simplicity of its front-end user interface. It’s nice, clean, fast, and simple.

Behind this simplicity lie sophisticated index databases and advanced search technologies, but we as users don’t need to know or understand these. All we need to know are smart keywords that help direct our searches from hundreds of billions of marked-up HTML pages scattered across the global Internet.

When we try to search using regular SQL database search technologies, though, we run into difficulties. Why? Because most of this web content is in distributed HTML flat files and isn’t organized in any centralized database with well defined data structures and schema. It’s like a world full of roads with no roadmaps. Go discover!

Search engines like Google, Ask, and others find the content that matches with our queries by building and employing centralized databases that contain metadata, where every keyword acts as a tag and has fast and efficient links to corresponding websites. In other words, a search engine acts like a very knowledgeable guide for us, responding to our queries with found/not found answers based on the Internet roads it has access to and has crawled before.

Why not use such a powerful search front-end to query financial research data? During my experience working with both sell-side and buy-side research analysts, there has been a long standing request to build such a tool, but until recently, the short answer to this request has been “No!”

No, because it’s technically too difficult or it’s too expensive.

No, because Google deals with text and not data, which has both context and meaning. Data is far more challenging to search, because even when it’s on the Web, it is marked up with HTML as text, not as data, thereby losing its context for meaningful search.

No, because there are no generally accepted standard financial dictionaries, or taxonomies, that define terms such as revenue, sales, or net income as synonyms.

Until recently this list of No’s has been long. The good news is that the list is now shrinking quickly with the increasing adoption of XBRL and EDGAR standard taxonomies and the release of several XBRL tools.

All that is needed to accomplish powerful search of financial research data is to subscribe to the SEC’s XBRL filings as free RSS feeds, extract XBRL data into our own relational or Google-like index databases, and use SQL to find answers to our queries. As an alternative, we could subscribe to third-party data services firms like Bloomberg, Thomson Reuters, Factset and others that would add XBRL data to their current aggregate data and continue to offer this as a service.

The news gets even better when we add SPARQL, a W3C specified query language for RDF, to XBRL and Linked Data.

Jim Rapoza, Chief Technology Analyst of eWeek, explains:

Called SPARQL (pronounced "sparkle"), this standard brings about a standardized SQL-like query language for the Semantic Web. And, like most Semantic Web standards, it is heavily based on RDF (Resource Description Framework), although it also makes use of many Web services standards, such as WSDL (Web Services Description Language).

SPARQL essentially consists of a standard query language, a data access protocol and a data model (which is basically RDF).

Some people out there are probably thinking, So what? Sounds like just another search tool—big whoop. But there’s a big difference between blindly searching the entire Web and querying actual data models.

The ability of database queries to pull data from giant databases is pretty much the basis of a large number of enterprise applications. No one argues about the value of being able to write a query in an application that can pull relevant customer and product data.

Now, imagine writing a similarly small application that does the same thing—only with data stored across the entire World Wide Web.

That would include all the companies who not only file in XBRL but also, in conformance to SEC requirements, will be posting XBRL data on their own company websites.

In essence, with SPARQL, we can choose to build centralized databases to query XBRL data, but we don’t have to. We simply can point our queries to so-called SPARQL endpoints that — unlike traditional database requests that must be under one administrative control — can span the Web over thousands of company websites with XBRL data and obtain results as if they came from one centralized database. Imagine the cost savings in not having to build and maintain a huge and growing centralized database.

Applications for publishing XBRL as Linked Open Data are limited at this time, but they are emerging. As one example, Roberto García and Rosa Gil describe their work undertaken at a Research Group at Universitat de Lleida, Spain, which extracted 1.34 million triples from 612 XBRL filings. (Triples are semantic data elements in RDF format.) The process of extraction is machine automated and results in transforming XBRL data into Semantic Web formatted RDF data.

In addition, sufficient examples in the current Web exist to give us insight into how the user experience might look when Semantic XBRL applications go into production use. Next time you search for the best flight for your air travel on sites such as Orbitz, Kayak, or FareCompare, take a pause and observe that the flight schedules, prices and airline details are being pulled not from any one centralized database but from a variety of airline databases, in real time, to match your exact itinerary requirements, thanks to some very specialized and complex technologies.

In summary, SPARQL makes Semantic XBRL searches possible on-demand across a distributed web space while simplifying front-end design, and keeping the complexity of technology hidden and out of sight from end users.

A Google-like experience of searchable financial research data is coming. The future looks bright.

Written by Yoshiaki Wada     Posted on May 11, 2009

Yoshiaki Wada is currently Director and the head of the financial data center section of the Bank of Japan’s Financial Systems and Bank Examination Department. In this capacity, he is responsible for the operation of the bank’s financial database system and leading the development of the XBRL-based data collection system.

Almost six years have passed since I found XBRL: I joined the XBRL world at the 8th International XBRL Conference in Seattle in November 2003. Since then, I’ve discovered — as I am sure many of the readers of this blog have — that it hasn’t been easy to get a broad appreciation of XBRL in the general business society. I hope our experience in Japan may give you some ideas on ways to overcome the difficulties you may encounter in your individual projects.

Outline of the Project
The Bank of Japan (BOJ) is the central bank of Japan. Our prime mission is maintaining price stability and the sound development of the Japanese economy. To achieve these missions, we closely monitor the soundness of financial service institutions (FSIs) in Japan. For timely monitoring, efficient data gathering from FSIs is essential, and XBRL has good potential for that purpose.

Although we decided to adopt XBRL, it was not clear to us what kind of business flow XBRL is most suitable for, nor the workload of implementing XBRL. In addition, there were the following three major issues to be solved before actual implementation:

• How to check whether XBRL is suitable for the BOJ’s data-gathering framework
• How to make people aware of the merits of implementing XBRL
• How to encourage people to use XBRL

The XBRL Pilot: A Step-by-Step Approach
In the first stage, only a few persons on our team were available for the XBRL project. Because of limited budget and human resources, there were few options open to us, so we chose to execute in a step-by-step approach.

First, we started the pilot project with FSIs on a voluntary basis. In July 2004, an announcement soliciting voluntary pilot test participants was made on the BOJ’s website. We were lucky that 31 cooperative and courageous FSIs applied for this test of unfamiliar technology, because XBRL was almost unknown in the finance industry in Japan at that time.

To help them understand XBRL and the purpose of the test, members of our XBRL team visited candidate FSIs one by one, which were located all over Japan, and gave hours of instruction on XBRL. The summer of 2004 was unforgettably hot for us, not only because of the elevated temperatures but also the psychological pressure to complete the first step of the project.

The contents of the test were rather simple. FSIs were requested to read the manual, install the necessary tools on their PC, and then convert their monthly balance sheet data from Excel format into XBRL. Although assistance was given by telephone because of limited manpower, all the FSIs could achieve the test program as planned.

As a consequence, we felt that any FSI could produce XBRL data provided they were given a user-friendly manual and easy-to-use tools. In addition, the IP-VPN system which was under construction for different purposes seemed to be suitable for sending metadata to FSIs and gathering XBRL data from them.

The most important result of the pilot test was that we found we could design the basic reporting scheme based on XBRL with complete confidence that XBRL was suitable for us.

How the BOJ’s XBRL Scheme Works
BOJ’s XBRL reporting scheme is based upon an interactive network system, which is called BOJ-Info system. BOJ-Info system connects BOJ and FSIs via IP-VPN, enabling both sides to send and receive any electronic data set smoothly and securely.

The resulting business flow works as follows.

(1) The BOJ prepares metadata such as the taxonomies required for reporting work. This metadata is uploaded to the BOJ-Info system.

(2) The FSI downloads the metadata via BOJ-Info and stores it on a PC which contains the BOJ’s tools for producing XBRL data.

(3) The FSI then imports report data previously created with Excel into the PC and creates data in XBRL format.

(4) Having checked and corrected any errors using formula linkbase, the FSI sends the XBRL data to the BOJ via the BOJ-Info system.

(5) The BOJ stores the XBRL data sent by the FSIs in a database. After again checking for errors in the database, the data is used for monitoring and producing statistics.

This reporting scheme has the following unique features.

(1) All necessary tools, taxonomy, and BOJ-Info system are supplied by the BOJ for free. Tools are designed to be easily added on the FSIs current system and do not cause any unexpected implementation cost for FSIs.

(2) The XBRL data generating tool is very easy to use, so FSIs can generate the XBRL instance file without any outside help. Consequently, data security can be maintained.

(3) By using formula linkbase, data accuracy is improved. The cost of data handling is minimized for both FSIs and the BOJ.

One of the most important features of our scheme is formula linkbase. When we decided to adopt formula linkbase, its specifications had not been finalized and only FDIC was implementing it. Why did we decide to use formula linkbase?

XBRL is a powerful tool for efficient data exchange. However, it is not useful enough for FSIs, because it is not necessarily worth the workload of generating XBRL data. To enhance the acceptance of XBRL in society, FSIs needed some benefit to offset the cost of generating the data. We searched for a solution and found the answer in formula linkbase.

Formula linkbase enables FSIs to validate data before submitting it to the BOJ, thus reducing the workload of correcting errors both for FSIs and the BOJ. Formula linkbase thus became core to the BOJ’s scheme in order to enhance and ensure the efficiency of XBRL.

What We Have Learned
Since February 2006, our XBRL scheme has been working without any major troubles. In addition, revision and re-distribution of the current taxonomy and the release of the new range of the taxonomy have been successfully done.

Simple revision and distribution of taxonomies is a key factor for using XBRL. Please remember that once you start using XBRL, you must maintain the taxonomy until you decide to shift to a better technology than XBRL. It is therefore crucial to build a workable and efficient overall reporting scheme which includes developing taxonomies in a timely fashion, notifying FSIs of  revisions and new releases of taxonomies, delivering taxonomies, and receiving reported XBRL data.

One of the most important successes in the past three years has been that, although XBRL was not mandatory in our reporting scheme, all FSIs submitted in XBRL format voluntarily. In other words, once XBRL reporting was ready, 100% of FSIs used it. A colleague said he could not believe it, because some banks in his country would never submit XBRL data even if required to do so by law.

What made it possible to achieve 100% XBRL based submission? One of the key factors is undoubtedly formula linkbase. Looking at the results of a questionnaire survey on the usability of BOJ’s XBRL tools and reporting scheme, which was conducted in August 2008, more than 70% of the FSIs recognized the merit of formula linkbase. In addition, many banks wanted formula linkbase to be extended to other reports.

This reveals an important aspect of technology implementation. We must always pay attention to benefits for users and try to build a popular scheme.

Looking back on our project, the following factors seem to be critical for the smooth implementation of XBRL:
-    Taxonomy with high maintainability
-    User-friendly tool
-    Well-designed reporting scheme
-    Well-organized project team

If any of these factors had been missing, our project could not have succeeded. However, to me, the last factor seems to be the most important.

BOJ’s XBRL team consists of five persons, three of whom have built all the taxonomies. They are always studying the latest technologies and trying to update their taxonomy library. In addition to the XBRL team, more than 20 people work together and cooperate to operate the database system, maintain the IT infrastructure such as BOJ-Info, and produce statistics. Without good teamwork, our breakthroughs could never have been achieved.

Future Plans
Once achieving a goal, one becomes greedy for new challenges. In our case, the XBRL-based data gathering scheme has been built. Although there is some room for improvement, basic functionality has been stable and the XBRL-based “bridge for data exchange” between BOJ and FSIs has been realized. What, then, is the next target? We have two major objectives in mind:

First is an XBRL-based database. We have stored XBRL instance data in flat files, but have not yet stored it into a native XBRL database. Currently, received XBRL instances are shredded into simple CSV that a conventional relational database can read; lots of metadata is not used. Our new database is a hybrid that is capable of supporting both XBRL and conventional data. The project started in this spring and live use is expected in September 2011.

Second is a handy and capable XBRL data analyzing tool. Using raw XBRL instances, various types of data analysis such as cross section analysis and panel approach can be easier realized. We anticipate experts both in Japan and around the world to be working on such an innovative tool.

In my humble opinion, it is just this kind of global cooperation that will continue to move XBRL forward, making it a vital and necessary tool not only in Japan, but throughout the world. I look forward to our working together and sharing the knowledge we gain. 

Written by Ashu Bhatnagar     Posted on May 7, 2009

Ashu Bhatnagar is CEO of Good Morning Research, a Softpark company that specializes in building Semantic XBRL technology. The GoodMorningResearch.com machine automates XBRL tagging of Excel data in RDF format with one-click Save As XBRL functionality. Mr. Bhatnagar moderates the Semantic XBRL group on LinkedIn.

Is anyone interested in the transparency of financial data?

That’s obviously a silly question: institutional investors, market regulators, analysts, financial advisors, and even some sophisticated individual investors are very interested in greater transparency of financial data than what is currently available. This interest in transparency is driven not only by the need for keener insight but also by an interest in managing risks — particularly when such data is used to drive significant investment and trading decisions that affect trillions of dollars in wealth on global capital markets.

However, trust often ends up used as a proxy for transparency, replacing it either by choice (e.g., to protect company secrets) or because of practical considerations (like limited resources of time, money, or reporting skills). In addition, compared to transparency, trust is simple, convenient, and less work!

Trust can be broken, however, in cases of fraud like Bernie Madoff or inadequate financial models like those used to value and rate complex instruments, such as credit default swaps and mortgage-backed securities before the real estate bubble burst. That’s when we are reminded of Ronald Reagan’s old maxim: trust but verify.

While Semantic Web and XBRL technology cannot provide a cure-all solution, they go a long way to integrating verifiable data into every step of financial reporting and organizing it for analysis and insight. Verifying financial data requires exposing transparency at every stage of the information supply chain as the data moves through it. The requirements are twofold:

(a) Make source data transparent in its raw format; and

(b) Make every step of any value-add process that normalizes and modifies this data transparent as well.

Examples of such value-add processes include normalizing and tagging raw data with metadata and taxonomy labels for comparability, applying relevant accounting adjustments, normalizing currencies and reporting periods, and adding other business rules and assumptions.

The first part, achieving transparency in publicly available raw financial data, is comparatively easy to attain. The second part, however — achieving transparency across value-add processes — may not be so. This is because value-add processes may be highly prized, and business rules and calculation models may be proprietary and closely guarded by data providers. In such cases, trust generally substitutes for transparency, but this requires an architecture that affords appropriate verifiability. The Semantic Web is designed to meet this challenge.

In my post last week, I discussed how Tim Berners-Lee coined the term Semantic Web in a roadmap for future Web design. A quick look at his Semantic Web architecture diagram, popularly known as “layer cake,” clearly demonstrates that the issue of trust — and, by extension, transparency — is addressed at a fairly high level in the Semantic Web’s stack. This architecture diagram has undergone several refinements; the most recent version (shown below) is on the W3C website.

To crystallize for our purposes: while building trusted systems, it’s necessary to go back not only to the source, i.e., raw data, but also to metadata about the source. The single most important point to derive is that the Semantic Web architecture explicitly addresses the issue of trust (and therefore transparency) at a much higher level than XBRL alone.

In the Semantic XBRL worldview, transparency extends not only to data and its associated taxonomy, but also to its logic, business rules, portability, and security, as well. This affords greater opportunity for verifying data when stakes are high and trust matters.

Raw data is in big demand though for reasons beyond transparency. Let’s examine two users of financial data who demand a data structure that includes raw data: buy-side institutional investors, and market regulators who represent taxpayers.

Buy-Side Institutional Investors
At O’Reilly’s Money:Tech 2008 conference in New York, a session asked, What Do Hedge Fund Managers Really Want? Here, some hedge fund managers explained that they wanted “Raw Data Now” with fully transparent source data before it was modified by sell-side analysts’ proprietary secret sauces or data aggregators’ value-add processes.

Why? Some simply disagreed with the value-added adjustments and forecast assumptions. Others wanted to be able to apply their own adjustments to raw data before building their own valuation, forecast, and risk models. I found this to be the case in my own personal experience at a major sell-side firm, where buy-side research analyst clients wanted to co-mingle data from multiple sources and needed to apply their own taxonomy tags and adjustments to the raw data.

Market Regulators
In testimony to the Domestic Policy Subcommittee of the Oversight and Government Reform Committee, Mark Bolgiano, President and CEO of XBRL US, observed:

Taxpayers want to know how their money is being used to fund the financial bailout. XBRL is a standard that promotes transparency and accountability and can be used by regulators to perform oversight functions more effectively and efficiently.

On the subject of XBRL’s impact on the transparency of financial transactions, specifically Mortgage Backed Securities (MBS), Bolgiano noted that:

The lack of reporting standards has made it difficult to understand the simple fundamental value of the mortgages in these loan pools. Information collected about borrowers, loans, ongoing surveillance, settlement and clearance information is reported in differing data and reporting formats. The identity of individual loans is lost when the pool is securitized and value becomes based on a rating and essentially what the market will bear.

With an agreed-upon data standard and XBRL, issuers, investors, rating agencies and regulators could forecast actual discounted cash flows of the individual loans, making it significantly easier to value each security – effectively “normalizing” the data so that the security can be valued using a recognized valuation method.

In the parallel universe of Semantic Web, Tim Berners-Lee is championing a grassroots movement to call for “Raw Data Now!” where raw data is stored in the RDF-based Linked Data Format to greatly increase data transparency. Speaking at this year’s TED Conference, he said:

Often you find that the people are used to database hugging. You don’t let it go before you have made a beautiful website…. Before making a beautiful website, first give us the unadulterated data. We want the data. We want the unadulterated data.

Berners-Lee went so far as to encourage the audience to join him in a chant for “Raw Data Now” and noted:

Practice that. It’s important because you have no idea the number of excuses people come up with to hang on to their data even though you paid for it as a tax payer. And its not just America but it’s all over the world, and that’s not only the governments but the enterprises as well.

Over the next several weeks I intend to explore more in the areas of Semantic wiki-tagging and Semantic XBRL data quality.

Written by Ashu Bhatnagar     Posted on April 29, 2009

Ashu Bhatnagar is CEO of Good Morning Research, a Softpark company that specializes in building Semantic XBRL technology. The GoodMorningResearch.com machine  automates XBRL tagging of Excel data in RDF format with one-click Save As XBRL functionality. Mr. Bhatnagar moderates the Semantic XBRL group on LinkedIn.

The history of XBRL is already known to most of this blog’s readers — a good concise refresher is available at the Bryant University site — but the history of the Semantic Web is less likely to be well known.

Because both XBRL and the Semantic Web rely upon XML and embedded tags for assigning meaning (i.e., semantics) to elements (data), and use extensible taxonomies for definitions in a standardized manner, their futures are likely intertwined. It’s useful to have some understanding of the Semantic Web’s origins and design in order to better understand its influence on XBRL moving forward.

On the East Coast in September 1998, Tim Berners-Lee, the father of the World Wide Web, coined the term “Semantic Web” in a roadmap for future Web design.

In Tim’s words, the architecture was intended for “achieving a set of connected applications for data on the Web in such a way as to form a consistent logical web of data (semantic web).”

The roadmap noted:

The Web was designed as an information space, with the goal that it should be useful not only for human-human communication, but also that machines would be able to participate and help.

One of the major obstacles to this has been the fact that most information on the Web is designed for human consumption, and even if it was derived from a database with well defined meanings (in at least some terms) for its columns, that the structure of the data is not evident to a robot browsing the web. Leaving aside the artificial intelligence problem of training machines to behave like people, the Semantic Web approach instead develops languages for expressing information in a machine processable form.

RDF, OWL, and Sparql are examples of such languages.

Fast forward ten years. In large part because of the support of former SEC chairman Christopher Cox, XBRL today has gained global support and strong momentum from financial regulators in many countries, who increasingly mandate its adoption for company filings from publicly listed companies.

Similarly, the Semantic Web has gained a strong following from global academic researchers and the World Wide Web Consortium, the de facto body that defines standards for the web. Fruits of this advanced academic research now are beginning to show in areas like machine-automated ontology.  

XBRL leads the space when it comes to development of standardized financial taxonomies with support from market regulators, IFRS, and accounting professionals in many countries. But its continued improvements likely will benefit from Semantic Web’s advances.

Today’s XBRL is built on today’s Web, but today’s Web is not standing still! It’s growing beyond a web of hypertext-linked documents to a Semantic Web. This web is being enhanced not only by changes to XML but also by next-generation standardized languages like Resource Descriptor Format (RDF), Web Ontology Language (OWL), and Semantic Query Language (Sparql) — enhancements that complement XBRL’s framework.

In parallel, efforts are underway to impart semantics for machine automation to more of the current non-semantic web:

• RDFa is a variant of RDF-with-attributes from the Semantic Web viewpoint
• Similarly, Andy Greener describes Inline XBRL as undertaking the work to embed XBRL-tagged meaning within data while rendering an XBRL document within a current-standard non-semantic web page. XBRL International’s specification for Inline XBRL as a markup to embed XBRL metadata inside HTML documents is available online.
• A January 2009 article from Scientific American entitled The Semantic Web in Action — Corporate applications are well underway, and consumer uses are emerging reports some real-life applications emerging from the Semantic Web community.
• In the domain of finance, Thomson Reuters offers a free service, OpenCalais, to automate tagging unstructured text in the RDF format, used for machine-tagging financial news.

Many more tools and applications currently under development are focused on integrating RDF with XBRL. In short, this will amount to Semantic XBRL.

In the coming weeks, I hope to explore some of these developments more specifically, including wiki-tagging, data quality, and transparency. In the meantime, check out Tim Berners-Lee’s talk on linked data.

Written by Bob Schneider     Posted on April 24, 2009

A few weeks ago Paul Wilkinson published a terrific post on Hernando de Soto’s WSJ op-ed Toxic Assets Were Hidden Assets. To oversimplify his multifaceted blog, Paul argues that XBRL is part of the solution to the current inadequacies in recording, tracking, and analyzing toxic asset data that de Soto describes in his piece.

The Peruvian economist’s thinking had also figured prominently in a post I wrote a year ago on XBRL and microfinance institutions, which provide microloans to the poor in developing nations. In his masterwork The Mystery of Capital, de Soto described how, contrary to received opinion, the poor entrepreneurs in these countries possess real assets (in the form of land), business acumen, and the same "animal spirits" as small business people in advanced economies; what they lack is a system for legal ownership of their property, making it impossible for them to borrow. Microfinance institutions provide the capital they need, and their repayment rates have been excellent. The XBRL data standard has been adopted by the Microfinance Information Exchange (MIX) for the detailed financial and social performance information generated by leading microfinance institutions.

Paul’s post made me wonder what it is about de Soto’s arguments that they simultaneously speak so powerfully about two asset classes that couldn’t be further apart on the economic hierarchy, namely, (1) the unregistered land holdings of the poor in countries like Peru, Haiti, and Indonesia, and (2) the quant-driven derivatives traded by the 21st century Masters of the Universe (well, until recently) in New York and London.  Why do de Soto’s writings, which so far as I know never mention interactive data, inspire calls for XBRL-based solutions?

The question demanded I read The Mystery of Capital. Reviewing the front and back matter first, I noted in the acknowledgments that the book’s title was suggested by Bob Litan of the left-of-center Brookings Institution, while the text was worked by David Frum, a noted right-leaning pundit. Moreover, the book had received kind words from both liberal organs like the New York Review of Books and conservative journals like Commentary. Clearly we weren’t in the balkanized states of Olbermann and Hannity anymore.

Read against the context of TARP bailouts and a bankrupt financial sector, de Soto provides a startling reminder of how parts of our economy have descended into Third World status. Here’s the introduction to the chapter entitled The Mystery of Missing Information:

Imagine a country where nobody can identify who owns what, addresses cannot be easily verified, people cannot be made to pay their debts, resources cannot be conveniently turned into money, ownership cannot be divided into shares, descriptions of assets are not standardized and cannot be easily compared….You have just put yourself into the life of a developing country.

How distressingly similar that is to the toxic-asset sector described in de Soto’s WSJ article:

These derivatives are the root of the credit crunch. Why? Unlike all other property paper, derivatives are not required by law to be recorded, continually tracked and tied to the assets they represent. Nobody knows precisely how many there are, where they are, and who is finally accountable for them. Thus, there is widespread fear that potential borrowers and recipients of capital with too many nonperforming derivatives will be unable to repay their loans.

Whether it’s land in the poor neighborhoods of Port-au-Prince or securities cooked up by the Best and the Brightest on Wall Street, assets’ value is crucially tied to the efficiency and efficacy of their recordkeeping systems. From de Soto’s WSJ article:

Property is much more than a body of norms. It is also a huge information system that processes raw data until it is transformed into facts that can be tested for truth, and thereby destroys the main catalysts of recessions and panics — ambiguity and opacity.

De Soto spends a good part of his book describing how the legal system for real property we take for granted today developed over many decades in the United States. In the beginning:

Every farm or settlement recorded its assets and the rules governing them in rudimentary ledgers, symbols, or oral testimony. But the information was atomized, dispersed, and not available to any one agent at any given moment. As we know too well today, an abundance of facts is not necessarily an abundance of knowledge. For knowledge to be functional, advanced nations have to integrate into one comprehensive system all their loose and isolated data about property.

Unlike the recording of securities based on real property, recordkeeping for U.S. real property itself is excellent. But it is the end result of a complex historical process extending 200 years. In his book, de Soto pays particular attention to the abundance of squatters who attempted to establish ownership through extralegal bodies like claim associations and miners organizations. Only after decades-long battles about title in the 18th and 19th centuries were extralegal and legal systems of property combined and these conflicts ultimately resolved. The economic success the U.S. subsequently enjoyed depended vitally on that resolution. 

In contrast, recordkeeping for mortgage-backed securities (MBS) is a throwback to the chaos of earlier times. In a sense, it is a betrayal of our economic heritage. Here’s how Philip Moyer of EDGAR Online describes MBS reporting in his January 2009 whitepaper Bringing Transparency to the Mortgage-backed Securities Market:

As a loan moves through the many participants in the MBS supply chain, each member of the supply chain — originators, retail banks, wholesale banks, issuers, servicers and ratings agencies — decides what to report publicly and when to report it. Additionally, all players use different report formats, different data labels, different ways of tracking the status of the collateral and even different models for tracking the identity of the individual loans. As a result, a loan can receive as many as five unique IDs between its origination and when it is bundled into an MBS. There is no centralized regulator that validates or collects all of this data. There is no central repository that can be queried… Therefore, it is difficult to track the status of a single loan in an MBS — even if it is in default — because every participant has completely different reporting models. The industry is awash in a sea of disconnected and incomparable data.

How can XBRL help? On pages 17-18 of his paper, Moyer describes eight benefits of using XBRL in a centralized MBS reporting system instead of current document/spreadsheet formats:

• Data Quality   Consistent labels and content, a structure for organizing data, and, most important, "a model to validate that the structure and the content of a report adheres to appropriate standards."
• Security and Privacy   Traceability and detailed control of the information reported.
• Historical Comparability   Versioning and an enduring structure allow comparisons regardless of changes in reporting requirements over time.
• Platform Compatibility   XBRL is platform agnostic.
• Multicurrency and Multilingual   Investors can view data in their own language and multiple currencies.
• Reduced Reporting Costs   Sunk costs for existing regulatory and banking XBRL reporting can be leveraged.
• Reduced Data Processing Costs   Receiving better data from upstream business partners offsets the costs incurred by each member of the supply chain.
• International Industry Standard   Leveraging the existing body of knowledge for XBRL saves resources that would otherwise go to resolving technical and financial reporting problems.

XBRL is not a cure-all, of course. To the extent that the data continues to be plagued by incompleteness and both intentional and unintentional error, MBS reporting still will have significant problems.

Nevertheless, introducing XBRL into the process will go a long way to providing the consistent, comparable, and accessible information that de Soto recognizes as an essential element in asset value, no matter what the asset class.
 

Written by Bob Laux     Posted on April 15, 2009 

Bob Laux is the Senior Director of Financial Accounting and Reporting at Microsoft Corporation. He is responsible for Microsoft’s technical accounting, including interacting with and responding to accounting standard setters on numerous issues. Prior to joining Microsoft in 2000, Mr. Laux was an Industry Fellow at the Financial Accounting Standards Board (FASB) where he was responsible for coordinating the activities of the Emerging Issues Task Force.

As indicated in previous posts on this blog, the SEC’s rule for interactive data is a major milestone in XBRL implementation.  However, it is important that there are continued improvements in XBRL taxonomies, especially with respect to disclosures outside the financial statements and footnotes.

The SEC rule made specific reference to disclosures outside the financial statements and footnotes:

We did not propose, and are not adopting, a requirement that filers provide interactive data for their Management’s Discussion and Analysis (MD&A), executive compensation, or other financial, statistical or narrative disclosure . . . In deciding not to require the tagging of this information at this time, we agree with the commenters who believed that more experience with interactive data and a greater understanding of the costs and time associated with compliance with the requirements as proposed is needed before expanding the requirement to other information. We will continue to consider, however, the advisability of permissible optional or required interactive data for disclosures made outside a set of financial statements prepared in accordance with U.S. GAAP or IFRS as issued by the IASB or related financial statement schedules required under Commission rules (33-9002, pages 40-41).

The Enhanced Business Reporting Consortium (EBRC) is currently in the process of improving the taxonomy for Management’s Discussion and Analysis (MD&A).  As a follow on to the American Institute of Certified Public Accountants (AICPA) Special Committee on Enhanced Business Reporting, the EBRC was formed by four founding members: PricewaterhouseCoopers, Microsoft, Grant Thornton, and the AICPA. The mission of the EBRC is to establish a consortium of investors, creditors, regulators, management, and other stakeholders to improve the quality, integrity, and transparency of information used for decision-making.  In particular, the EBRC is working on enhancing the reporting model to focus not only on financial information, but also on a range of contextual and nonfinancial information that provides an enriched understanding of company performance, value drivers, strategies, and potential.

The current MD&A taxonomy consists of approximately 70 tags with most of the elements at the same hierarchical level. This required the creation of numerous company-specific extensions to make the taxonomy useful for those companies that tagged their MD&A under the SEC’s Voluntary Filing Program. While the new taxonomy being proposed by the EBRC currently only consists of approximately 140 tags, it has a structure that should significantly simplify the tagging of the information as well as facilitate access for users of this information.

It is hoped that the financial reporting supply chain will openly collaborate on the proposed taxonomy in order to create more detailed tags so that narrative information can be provided in an interactive data format. Although the SEC is not requiring the tagging of narrative information at this time, the ability to tag and consume nonfinancial information (i.e., the narrative type of disclosures that are made via MD&A and other channels of corporate communication) is increasingly useful to both companies and consumers of business information, and is vital to providing enhanced transparency in the markets.

The EBRC invites interested parties to review the proposed MD&A taxonomy at this website. Follow the instructions for logging in and the MD&A taxonomy will be midway down the navigation tree once you are logged in.
 

Chie Mitsui is a Data Analyst at Nomura Research Institute, where she is helping design NRI’s new XBRL-enhanced services. She previously worked as system designer for information service products at Jiji Press, a Japanese financial news and data distribution company. Ms. Mitsui holds a masters in physics from the Tokyo University of Science and is pursuing her MBA.

1. In February you conducted a well attended workshop at the Tokyo Stock Exchange that was sponsored by  XBRL Japan. Could you tell us its purpose and who signed up for it?

XBRL has been implemented at both the Tokyo Stock Exchange’s TDnet and the Financial Services Agency’s EDINET. Naturally, interest in using XBRL for investment analysis has increased; analysts and investors want to know “What can XBRL do for me?” These end-users represent the final and key link in the financial reporting supply chain, yet their views on XBRLized disclosures haven’t been given great weight in the implementation process.

Given that TDnet’s mission is to deliver timely financial information to the investment community, there was a strong sense that such workshops are essential for helping end-users utilize the system’s XBRLized data.  The attendees were (primarily) analysts, data intermediaries, and representatives of securities firms.

2. Were they receptive to the need for XBRLized data?

I think many end-users are not satisfied with their current choices for retrieving financial data, namely, using the services of a data vendor or inputting the data themselves from a PDF into, say, Excel.  But that doesn’t necessarily mean they are completely convinced of the need for XBRLized data.

Let me give you an example from our workshop. The XBRL tool we used has dialogs to choose elements on the calculation sheets and provides easy viewing for beginners. Once you construct an initial sheet with an opened XBRL file, you can use the same sheet for other files. When attendees made the calculations for the target company we selected, some users felt it would indeed be easier to simply stick with copying data from a PDF.

But what I emphasized to these users was that, while that might be true for a single company’s data, it’s not the case when you want to compare all companies in the same industry. That’s when XBRL really shows its colors.

We used XBRLized data for 3Q 2008 to calculate the ratio of accounts receivable to sales for both the target and a broad group of companies; this would help identify the risk in reported profits and potential cash flow problems. When we compared the results, the target company’s ratio was a little higher than average. The attendees did realize the usefulness of XBRL in this situation. Nevertheless, we did have some hurdles to overcome.

3. Which were?       

For the first company we selected, the actual element was notes and accounts receivable-trade, and for most of the companies we selected this was the right choice. But for one company the element was just accounts receivable-trade, which didn’t treat notes receivable, and its inclusion generated an error message. The experience highlighted for attendees the special nature of using XBRL data.

When analysts and analysts use data from data intermediaries, the data is normalized so that items are combined for better comparability. Having the original data allows for more specificity and better analysis, but it also raises issues like the one I just cited. If you want to compare a financial ratio for dozens of companies, you do not have time to check each instance for errors. You need to choose the right element to verify your hypothesis.

4. So in your view using TDnet’s XBRL data for comparing financial ratios of many Japanese companies simultaneously can prove difficult?

Well, it’s not a problem of the XBRL – it’s the nature of Japanese financial reporting. The taxonomies used in the US reflect US GAAP accounting and have much more structure. The software enables users to identify the parent element, and they can use tree-like navigation to select the elements they need. Japanese taxonomies, in contrast, are relatively flat, and it is more difficult to know the relationships between elements. That is the real issue: how to make taxonomies.

There are other significant differences in US and Japanese taxonomies. For example, attendees were surprised that US GAAP taxonomies had contexts that identify the specific time period. In contrast, Japanese taxonomies have contexts like CurrentYearConsolidatedDuration. That doesn’t mean you’re likely to confuse 2007 and 2008 data for Japanese companies — the taxonomy provides for that distinction. But it does require that you adjust your software settings accordingly.

5. So you see consequences for international comparisons as well?

I do. Of course, institutional investors, as well as some individual investors, trade equities on an international basis. Differing accounting standards among nations  naturally result in differing taxonomies. But beyond the dissimilarities that result from accounting standards, the nature of XBRL taxonomies, the naming of elements, and so forth can vary among countries in important ways. So for now, sector analysts who want to analyze their industries on a worldwide basis will encounter comparability issues directly related to the XBRL.

At the same time, I see opportunities for improved financial reporting through XBRL. Items that have been traditionally combined for paper-based reporting – such as notes and accounts receivable –  can be disaggregated and reported separately with XBRL. More granularity will mean more accurate reporting.   

6. What was the main conclusion you drew from the workshop?

The most important thing I came away with is the need for end-users to be part of the XBRL conversation.  After all, all of the work of XBRL implementation is ultimately aimed at them. This meeting was a good opportunity for their voices to be heard, and I hope there will be more of them in the future.

Written by Gianluca Garbellotto     Posted on March 30, 2009

Gianluca Garbellotto is current Chair of the XBRL Global Ledger Working Group and is a past member of the XBRL International Standards Board. He  is deeply involved both in XBRL standards development and in their practical implementation, with a specific focus on internal reporting requirements. His current professional engagements include some of the major global XBRL projects. His GLG Repository site features his newly inaugurated blog.

Earlier this month, the Institute of Internal Auditors (IIA) Research Foundation published my white paper XBRL: What’s In It for Internal Auditors, which I had the privilege to write with the invaluable review and advice of a number of individuals quoted in the paper.

This paper was initially conceived to address the results of an XBRL awareness survey among chief internal audit executives worldwide conducted by The IIA at the end of 2008. The survey showed only a partial awareness of XBRL by internal audit professionals. In addition, auditors were minimally involved in the actual process of generating XBRL filings even in those companies that are already using XBRL, either in voluntary or mandatory projects.

One of the objectives of the white paper is to fill this awareness gap by providing a comprehensive overview of what XBRL is, how it is being used in various programs across the world, and how it will have to be used to meet the SEC’s interactive data mandate, which starts in the second half of this year.

However, this is only one part of the story. Obviously, internal auditors need to be able to contribute to, and provide professional assurance on, the process of generating XBRL filings as they do with any other corporate reporting process. Still, XBRL’s value proposition in internal auditing processes goes far beyond being an additional format to which to convert financial reports. The white paper highlights the uses of XBRL that go beyond regulatory compliance, demonstrating how it enables the enhancement of critical processes in the internal space:  data integration, reporting assembly, application of validation rules, controls, and visualization templates in a consistent way across the whole corporate information system.

Simply put, internal auditors should consider XBRL — and I am not referring here just to the US GAAP XBRL taxonomy used to report to the SEC, but to the standard as a whole in its various flavors as described in the paper — as a key tool to perform their functions more efficiently, rather than simply an additional reporting burden that requires their professional attention. XBRL enables moving from widespread manual, error-prone processes to automated and standardized ones in key data-related activities. It is something that businesses can leverage internally as a key technology and not just see as an additional compliance burden.

This concept is relevant not only for internal auditing, but for internal corporate processes in general. It can help executives making crucial decisions today on how to comply with the SEC’s interactive data mandate over the course of the next several years.

The white paper also examines different approaches to XBRL adoption, where XBRL can be either bolt-on at the highest financial report generation level, built-in deeper into the reporting layer of the corporate information system, or deeply embedded at ledgers level.

If a company sees XBRL as just another format in which financial statements have to be submitted for compliance, its management is likely to consider only the easiest options to create its filings: either create them under the existing process and convert to the new format at the end, or outsource as much of the process as possible. These choices not only represent a missed opportunity on the "internal" benefits that XBRL enables, but will actually be put to test by evolving reporting requirements. Additional reporting concerns like IFRS convergence and the “Year 2" requirements already set in the SEC mandate, which extend the depth at which information will have to be tagged in notes and schedules, are reason enough to consider all of the options available and their implications very carefully.

In short, even if you are not an internal auditor,  I think it may be worthwhile for you to get the white paper from The IIA website.

Olivier Servais is Director of the XBRL Activities at the IASC Foundation, which is responsible for the development of the IFRS taxonomy. He has been European Director of XBRL International and has served as a member of the XBRL International Steering Committee, the Consultative Working Group of CESR Transparency, and the Eurostat XBRL Pilot Task Force. He is the author of various publications about XBRL.

This is the second part of a two-part interview. The first part contains questions 1 to 7.

(8) Do you perceive any differences in business cultures around the world that make it harder or easier to implement XBRL in individual countries? Or put another way, are there certain conditions that make it easier to adopt XBRL in some countries than others?

I believe that most of the requisite conditions for the efficient implementation of XBRL are now in place: political decisions have been made, taxonomies are available and software solutions, including ERPs, are affordable. The financial crisis is playing an ambiguous role. Few people doubt XBRL’s potential to improve information exchange and therefore restore market confidence by providing transparency. Yet at the same time few, if not forced, are willing to dedicate the time and money to implement it.

This applies to all countries and regions as all are affected, though some have been quicker on the uptake than others. I recently spent a week in Japan and was highly impressed that XBRL as a concept or idea is no longer discussed because it is already implemented. It is a similar situation in Belgium, where all non-listed/non-financial companies (approximately 280,000 of them) have been filing in XBRL for almost two years.

In this sense, XBRL is becoming a nonissue. Why? Dedication and endorsement from high level decision-makers, who want to see XBRL embraced in their markets. As well as Japan and Belgium, there are interesting examples of XBRL adoption in Australia, China, India, Spain, and the US.

(9) The IFRS taxonomy recently released a simplified Chinese translation of the complete label linkbase for the IFRS Taxonomy 2008. As the IFRS strives to provide taxonomies in so many languages, what kinds of problems or issues arise? Are language and translation issues a significant problem for IFRS taxonomy development?    

I am not sure if there is a “problem.” Providing IFRSs in English only would delay their adoption around the world. Therefore translation of the IFRSs is considered vital by the IASC Foundation and its Trustees and a dedicated team is now devoted to this effort. Since January this year, the translation effort of the IFRS Taxonomy has been integrated with the translation effort of the IFRSs, and IFRS translators/reviewers are also reviewing the taxonomy. This change in the translation process will significantly reduce the term, hopefully to no longer than six months and also make translations of the IFRS taxonomy more quickly available. Currently we are preparing translations in Chinese, Dutch, French, German, Italian, Japanese, and Spanish. Other languages will be made available, depending on resources and market demand.

(10) The SEC issued its Roadmap for IFRS adoption in November. One of the milestones the Roadmap provides is that:

In order to realize the improvements in the usefulness and comparability of financial information anticipated upon the widespread use of interactive data, U.S. issuers would have to be capable of providing IFRS financial statements to the Commission in interactive data format at a greater level of detail than is currently available. Therefore, the state of development of an IFRS list of tags for interactive data reporting will be a consideration in the Commission’s determination of whether to require the use of IFRS for all U.S. issuers….The Commission staff is actively involved in the improvement and monitoring of the IFRS list of tags via participation in the IASC Foundation’s XBRL Advisory Council.

How do you view this requirement, and could you tell us how that work is proceeding?

There is another important element of the SEC Roadmap: the use of two sets of accounting requirements, US GAAP and IFRSs as published by IASB. If you consider the very first standard, IAS 1, you will see that the IFRS taxonomy can be used to file with the US SEC. However, there are concerns over the differing number of elements in the US GAAP taxonomy and the IFRS taxonomy and the need for more detail in the IFRS Taxonomy. Indeed, during my recent trip to Tokyo the Japan FSA expressed concerns about the level of detail in the IFRS Taxonomy in comparison with the EDINET taxonomy.

The XBRL Advisory Council and Interoperable Taxonomy Architecture (ITA), a joint initiative by the European Commission, the Japan FSA, and the US SEC, are forums where such improvements are being discussed. However, despite such demands from stakeholders, our role remains focused on producing a high quality product that reflects the IFRSs, and does not currently extend beyond that. It’s fair to say that things could change.

(11) In a recent KPMG survey, some 65 percent of investment executives and analysts surveyed expect that U.S. adoption of IFRS will make U.S. capital markets more attractive to foreign investors. Fifty-seven percent of the investors and analysts surveyed believe the timeline proposal announced by the SEC in November to be “about right,” while 18 percent said it wasn’t aggressive enough. Why do you think IFRS apparently enjoys such strong support in the US financial community?

Transparency and comparability are definitely the main reasons. Some years ago, it was commonly believed throughout the XBRL community that XBRL adoption was a matter of “when” rather than “if." I believe that the same statement applies now for the adoption of IFRSs in the US, and that the 18 per cent would like to see IFRS adoption now.

(12) Have you seen an impact from the global recession on the pace of adoption of IFRS standards? Do you think IFRS implementation will slow because policymakers (a) put their energies elsewhere (b) fear IFRS will only complicate recovery, or (c) cynically use the downturn as an excuse not to adopt IFRS? Or alternatively, do you think policymakers will see adopting IFRS as part of the long-term solution to stable economies, financial transparency, and a step toward averting future financial crises?

From my perspective, I haven’t seen a slowing down in the pace of IFRS implementation by the US. Without wanting to congratulate my colleagues too much, the IASB has been globally recognised as having made appropriate decisions and providing effective resources when needed. Even with growing staff numbers, we remain a relatively small organisation with a limited budget. Also it should be noted that developing accounting standards is a necessarily lengthy process. Furthermore the IASC Foundation is governed by a Board of Trustees that represents international business sensibilities. Therefore without wanting to sound complacent, I truly believe that IFRSs are ready to be applied as part of the solutions being drafted by governments to protect financial markets in the future, and I am confident that XBRL will be part of those solutions as well.

(13) The IASB is located in Europe, it has much interaction with European institutions, and a quick review of the staff roster would indicate most or all are European. Do you have any concerns that the final IFRS and XBRL products will be too Eurocentric? Even if that’s not the case, do you fear they may be perceived as such?

Do you ask the question because I’m Belgian and come from the heart of Europe? More seriously, the Trustees and staff of the IASC Foundation and the members of the IASB are drawn from almost 30 countries across the world. Our Director of Technical Activities (aka accounting matters) is from New Zealand, the Chief Operating Officer and the Director of International Affairs are both American, and the membership of the IASB and the Board of Trustees is managed to ensure that there is geographical diversity and representation. Of course there is much interaction with European institutions, mainly because the European Union was the first region to adopt our standards. However recent adoption decisions in Canada, China, India, Japan, and Korea have directly affected the diversity of our staff, and citizens of each of those countries are to be found in the IASB and IASC Foundation.

(14) Are you concerned that global implementation of IFRS will undermine traditions in business culture that are reflected in the accounting standards of individual nations? Do you think that national accounting and business communities may come to resent IFRS because it has superseded national accounting standards? Or do you think that ultimately local bodies will see that the advantages of international standardization more than offset this negative?  

The heterogeneity of the IASC Foundation staff, the IASB and also the Trustees is the best warranty that local “flavours” are considered when developing IFRSs. Even if some communities attempt to use the crisis as a pretext for protectionism, capital markets are interconnected and therefore solutions need to be global, and all of us at the IASB, and the IASC Foundation are working together to ensure that we perform our duties and meet our responsibilities.